5 ms·

I feel it's probably been said before, but why are people investing time in a Javascript server side framework? It just seems ridiculous. Edit: I can understan

I feel it's probably been said before, but why are people investing time in a Javascript server side framework? It just seems ridiculous. Edit: I can understand shipping logic from the server to client, for validation perhaps. But... meh.

jacquesm 10y ago
Because they believe that a single language should be enough for developing web applications.
- medeas_crypt 10y ago
  Probably a fair enough perspective. I guess I just hate it. With a passion.
- BjoernKW 10y ago
  What became of "the best tool for the job"? I doubt the benefits of having a single language outweigh the effort put in just to replicate solid server-side environments existing today.
  - MatekCopatek 10y ago
    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.
    - BjoernKW 10y ago
      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?
      - algesten 10y ago
        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)
- naranha 10y ago
  The consequence is that you can share code between client and server which is a large benefit.
  - electrotype 10y ago
    But Javascript fans often also say the server should only be a REST API, consumed by the client side, and not bound to it. What that means is : 1) It makes no difference at all if is the server is implemented using a different language than the client. 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.
    - egeozcan 10y ago
      > 1) It makes no difference at all if is the server is implemented using a different language than the client. Makes a difference: Same people can maintain it without too much friction. > 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language. Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.
      - electrotype 10y ago
        > Makes a difference: Same people can maintain it without too much friction. For a very small team, I guess it makes sense. I would still prefere to be able to use Java/Kotlin/C# on the server and on the client then. Or even Dart. Not Javascript... > Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides. Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved. But if one day you have to consum the same service from another application, a native iOS application for instance, then you may start to realized that your API is too bound to your first consumer. But I guess it's not that important if your backend will only be consumed by this particular application, ever.
        10y ago
- JSDave 10y ago
  Also, JS is built to handle concurrency. Other languages have event loop libraries, but in JS it comes with the language and every web dev uses it.
  - echelon 10y ago
    "Async all the things" concurrency doesn't matter. Javascript is not going to be faster than Go or Rust, which are increasingly taking over as web backends. (I'm writing stuff in Rust's Iron framework lately.) Or Java, for that matter. I can serve more requests from these languages than "concurrent" Javascript.
    - JSDave 10y ago
      I don't doubt that you can. But in a lot of situations, as long as the slow stuff like db queries and api calls don't block, it's good enough. And that's easier to accomplish in JS.
  - alexchamberlain 10y ago
    This has only been the case for a few years, since the ECMAScript Xs, which is why I think you're being downvoted. To be fair, it's a relatively new feature in Python too.
    - JSDave 10y ago
      To me, it's the event-driven problems JS tries to solve that seems to overlap with typical server functionality. That has been true since the beginning.
      - goatlover 10y ago
        What, that you clicked a button and JS did something back in 95 when Netscape introduced it? The same could be said for Visual Basic for any language that had callback code attached to a button click. You do realize that Python, Perl, etc could be written to handle GUI code back then as well.
unculture 10y ago
If your success relies on search engine listings, it is still better to render the contents on the server to that the crawlers can index it (some still penalise JS only sites). You can then "hydrate" the SPA on the client for a better user experience.
algesten 10y ago
From personal experience developing at all levels of the stack, I think my job breaks down into something like * 40% UI (visualising states, handling user input, feedback, etc), * 55% moving data around (read an XML file, translate it, push it into db over there) * 5% algorithmic work (given input of x million records, figure y out) The UI stuff I already did in Javascript, however it turns out that one single threaded process can shuffle a lot of data around (resource efficiently), if I adopt an async programming style. I know NodeJS is not the only language that does async stuff nicely, but it's rather convenient to have the same language everywhere (though I recognise Javascript is not the most elegant).

jacquesm 10y ago

Because they believe that a single language should be enough for developing web applications.

medeas_crypt 10y ago
Probably a fair enough perspective. I guess I just hate it. With a passion.
BjoernKW 10y ago
What became of "the best tool for the job"? I doubt the benefits of having a single language outweigh the effort put in just to replicate solid server-side environments existing today.
- MatekCopatek 10y ago
  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.
  - BjoernKW 10y ago
    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?
    - algesten 10y ago
      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)
naranha 10y ago
The consequence is that you can share code between client and server which is a large benefit.
- electrotype 10y ago
  But Javascript fans often also say the server should only be a REST API, consumed by the client side, and not bound to it. What that means is : 1) It makes no difference at all if is the server is implemented using a different language than the client. 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.
  - egeozcan 10y ago
    > 1) It makes no difference at all if is the server is implemented using a different language than the client. Makes a difference: Same people can maintain it without too much friction. > 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language. Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.
    - electrotype 10y ago
      > Makes a difference: Same people can maintain it without too much friction. For a very small team, I guess it makes sense. I would still prefere to be able to use Java/Kotlin/C# on the server and on the client then. Or even Dart. Not Javascript... > Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides. Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved. But if one day you have to consum the same service from another application, a native iOS application for instance, then you may start to realized that your API is too bound to your first consumer. But I guess it's not that important if your backend will only be consumed by this particular application, ever.
      - 10y ago
JSDave 10y ago
Also, JS is built to handle concurrency. Other languages have event loop libraries, but in JS it comes with the language and every web dev uses it.
- echelon 10y ago
  "Async all the things" concurrency doesn't matter. Javascript is not going to be faster than Go or Rust, which are increasingly taking over as web backends. (I'm writing stuff in Rust's Iron framework lately.) Or Java, for that matter. I can serve more requests from these languages than "concurrent" Javascript.
  - JSDave 10y ago
    I don't doubt that you can. But in a lot of situations, as long as the slow stuff like db queries and api calls don't block, it's good enough. And that's easier to accomplish in JS.
- alexchamberlain 10y ago
  This has only been the case for a few years, since the ECMAScript Xs, which is why I think you're being downvoted. To be fair, it's a relatively new feature in Python too.
  - JSDave 10y ago
    To me, it's the event-driven problems JS tries to solve that seems to overlap with typical server functionality. That has been true since the beginning.
    - goatlover 10y ago
      What, that you clicked a button and JS did something back in 95 when Netscape introduced it? The same could be said for Visual Basic for any language that had callback code attached to a button click. You do realize that Python, Perl, etc could be written to handle GUI code back then as well.

unculture 10y ago

If your success relies on search engine listings, it is still better to render the contents on the server to that the crawlers can index it (some still penalise JS only sites). You can then "hydrate" the SPA on the client for a better user experience.

algesten 10y ago

From personal experience developing at all levels of the stack, I think my job breaks down into something like * 40% UI (visualising states, handling user input, feedback, etc), * 55% moving data around (read an XML file, translate it, push it into db over there) * 5% algorithmic work (given input of x million records, figure y out) The UI stuff I already did in Javascript, however it turns out that one single threaded process can shuffle a lot of data around (resource efficiently), if I adopt an async programming style. I know NodeJS is not the only language that does async stuff nicely, but it's rather convenient to have the same language everywhere (though I recognise Javascript is not the most elegant).