I know what you mean, but at some point in history you could say that for every programming language that wasn't the first one to dominate that specific domain.
Absolutely and I'm not against innovation at all. The exercise of making JavaScript a valid server-side alternative often seems pointless, though. What's the benefit of JavaScript on the server side other than "one language"?
Perl, Java, Spring, Ruby on Rails each offered significant benefits over what existed before. What does JavaScript on the server side do better than other solutions? There's the event loop and non-blocking behaviour but is that enough for most applications to justify using JavaScript on the server side?
For me it is not just about being comfortable in writing the same language for aerver and client. It has also a technical aspect to it:
I can directly run my application code, which is a single page application in js, also on the server. I have complex datamodels in my js application. It would be very much work if I need to use some of these datamodel functions on the server if I wouldn't use js there.
I think you may be underestimating the "language barrier" for more junior devs. What I see around me is that it takes a few years of programming before you start "seeing through" the syntax and realise it's all the same.
With Javascript everywhere, I experience we have less resistance for people to work all over the stack.
Also there's something to be said for JSON. There is a big win in having it all the way from the DB, untranslated up to the UI.
> I think you may be underestimating the "language barrier" for more junior devs.
I know people like that. Once junior devs, too back in the heyday of Enterprise Java in the late 90s they couldn't be bothered to learn this ugly upstart language known as JavaScript because "serious developers don't use a toy language like that". In part, who can blame them? CS professors at that time floated ideas like object-orientation and code generation being the be-all and end-all.
These developers sometimes went at great lengths to avoid writing the tiniest bit of JavaScript at all (when it 'finally' became obvious that this newfangled web thing wasn't a passing fad ...) and invented convoluted frameworks that generated JavaScript from Java code. These frameworks inevitably couldn't keep up with the pace of change in the web development community at large, which is why nowadays they often are a huge technical debt to the projects they're used in.
The developers themselves, now not so junior anymore, often have a hard time finding a job today because learning something besides Enterprise Java was too much of a hassle.
So, while the idea of "easing in" junior developers by having a consistent language in all layers might have some merit, in the long run it might very well be doing them a disservice and also leave behind a huge pile of technical debt in the end.
Yes. Despite writing both straight assembler (68k processors) and C back in the 90s, I also fell into the Enterprise Java-trap for a long while. GWT was my go-to front end framework, and it worked I suppose.
It's a bit hard to compare these days, since browser quirks were much more pronounced back then. I remember tackling differences in IE4/5 vs Netscape 6/7 and all those hacks and workarounds seem absurd now. When GWT entered, it at least unified these platforms and worked around many differences for me.
And don't get me started on server side enterprise stuff. I still run screaming when someone proposes "IoC containers" or "workflow engines" in NodeJS. Never again!
Wonder whether "Virtual DOM" and "Transpilers" is what I run screaming from in 10 years?
(i already decided against transpilers, ES6 syntax isn't worth the overhead imho)
They still offer benefits. And some also offer an event loop and non-blicking behaviour. However there is a huge number of libraries around Node which enable you to solve problems both in the browser and on the server. For example Highcharts rendering graphs in the browser and rendering them as a png or pdf on the server, enabling the user to save them.
Too bad it doesn't have a standard library, too bad js is an ugly language compared to Ruby or even Perl. Too bad npm duplicates dependencies and pulls tons of packages.
