3 ms·

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 star

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.

BjoernKW 10y ago
> 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.
- algesten 10y ago
  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)

BjoernKW 10y ago

> 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.

algesten 10y ago
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)