5 ms·

Your distaste for JavaScript aside, writing your app in a language that can run the same exact code on the server and client is a giant win for companies that h

by Touche 12y ago

Your distaste for JavaScript aside, writing your app in a language that can run the same exact code on the server and client is a giant win for companies that have been doing redundant work for years.

stephenr 12y ago
I always hear this but I don't buy it. The client and the server have different jobs to do, how much code re-use is really happening in real world apps?
- CSDude 12y ago
  My guess is that they probably share the models at most, but even so they have different funcionalities on client side and sserver side.
- secoif 12y ago
  The real benefit of one language everywhere is reduced penalty for context switching and flexibility with your architecture. The promise of "code reuse" is very alluring but reusing application code rarely happens in reality. However, reuse of patterns and libraries is very common – solve a generic problem once and you don't have to research how to achieve the equivalent in another ecosystem. Just grab the exact same library, browserify the thing and you're done (ideally). "One language everywhere" grants you lots of flexibility – where your code executes is no longer locked in stone – you can shift responsibilities from the server to client & vice-versa without significant overhead. No need to port to a different language which perhaps lacks similar paradigms or tooling. Doors are opened to optimisations and architectural changes that would not have even been a consideration otherwise. To get the benefits of "one language everywhere" doesn't necessarily mean "use JavaScript" but it's a safe decision to choose the lowest common denominator; JavaScript is not going out of fashion any time soon, it runs on nearly every platform and has an ecosystem that's competitive in a wide gamut of problems. An investment in vanilla JS will pay out in long term, while any investment in Framework-X or compile-to-js Y or AltJS-Z is high risk and usually only pays out for the 18 months or so while said tool is in vogue. JS may not be the best choice, but it's a smart choice.
  - xamuel 12y ago
    >reuse of patterns and libraries While this sounds alluring, in practice I think it would mostly be limited to the kind of thing where you check something client-side (like whether a username meets the requirements) and then re-check it server-side because security 101. Client-side code is about displaying things, turning JSON into buttons and widgets, etc. There is no point having that on server-side. The server does not have a human user clicking buttons and scrolling bars. Server-side code is about performing calculations and facilitating communication between different clients. If these can be done client-side, then there's no reason to do them server-side in the first place. >An investment in vanilla JS will pay out in long term This is true, but a lot of JS investment is not in vanilla, it's in whatever framework is popular that week, and next week that framework will be dropped like bellbottom pants.
    - falcolas 12y ago
      > Client-side code is about displaying things Actually, JS developers are learning that this is frequently better done on the server; there are more and more articles every week about the benefits of pre-rendering the application page on the server side, then letting the client JS take over and make the server generated code responsive. I believe the term being used is "isomorphic" javascript. However, since the Node.js server is inherently single threaded, the cost of generating these templates server side impacts every connection being handled by that particular instance.
      - xamuel 12y ago
        What JS developers call "pre-rendering" is what everyone else has been calling "not a static webpage" since forever. It takes willful blindness to ride around on a bike with square wheels, ignore the round-wheel bikes around you, then eventually switch to round-wheel yourself and act like you invented it and it's the next big thing.
        username223 12y ago
        Well, some of these guys are also riding single-speed fixies over a century after the invention of the derailleur and freewheel. I'm not hip enough to know if (extraordinarily dangerous) penny-farthings are coming back yet.
stephenr 12y ago
Also, having just looks at the article: > having the same language in client and server can simplify the data management between them That isn't called "simplified data management" it's called tightly coupled. What backend language/framework doesn't support json, xml (and even html fragments) for working with a JS frontend?
br3w5 12y ago
So if the server side stuff was written in node, that is a js framework and still requires a learning curve for developers if they don't already know node. Also you shouldn't choose your server side language/framework based on the fact it's the same as the front-end code. And you still need to have a clear and well documented API for the server side app - just using js isn't going to solve that problem. If you do solve that problem, in any language, then is implementing it in js really a necessity (apart from maybe a skill issue i.e. do you need people with a mix of skills or just js devs but again, I can't see why this is a problem)?
vinceguidry 12y ago
Except that you're only reducing the complexity of your stack by exactly one syntax. You still will have different semantics for the front and back ends. You still will have a giant wall between the server and the client with the only way of getting stuff over it is throwing it with a really strong arm, i.e. passing it in through HTML or after the fact with AJAX. You still will have to drop down to HTML and CSS, with a template language and perhaps a CSS preprocessor. If you don't think HTML and CSS are both powerful, complex languages in their own right, you haven't made anything truly complex for the web yet. You still have to manage devops, which has its own ecosystem and suite of tools. Javascript and its prototypical object system is great for client-side scripting code, but a poor fit for server domain concepts. You're going to have to learn multiple tools, languages, paradigms anyway. So just suck it up and use a proper back end framework too. Node's pretty good, but it's not Rails.
deleted 12y ago
[deleted]

by Touche 12y ago

stephenr 12y ago

I always hear this but I don't buy it. The client and the server have different jobs to do, how much code re-use is really happening in real world apps?

CSDude 12y ago
My guess is that they probably share the models at most, but even so they have different funcionalities on client side and sserver side.
secoif 12y ago
The real benefit of one language everywhere is reduced penalty for context switching and flexibility with your architecture. The promise of "code reuse" is very alluring but reusing application code rarely happens in reality. However, reuse of patterns and libraries is very common – solve a generic problem once and you don't have to research how to achieve the equivalent in another ecosystem. Just grab the exact same library, browserify the thing and you're done (ideally). "One language everywhere" grants you lots of flexibility – where your code executes is no longer locked in stone – you can shift responsibilities from the server to client & vice-versa without significant overhead. No need to port to a different language which perhaps lacks similar paradigms or tooling. Doors are opened to optimisations and architectural changes that would not have even been a consideration otherwise. To get the benefits of "one language everywhere" doesn't necessarily mean "use JavaScript" but it's a safe decision to choose the lowest common denominator; JavaScript is not going out of fashion any time soon, it runs on nearly every platform and has an ecosystem that's competitive in a wide gamut of problems. An investment in vanilla JS will pay out in long term, while any investment in Framework-X or compile-to-js Y or AltJS-Z is high risk and usually only pays out for the 18 months or so while said tool is in vogue. JS may not be the best choice, but it's a smart choice.
- xamuel 12y ago
  >reuse of patterns and libraries While this sounds alluring, in practice I think it would mostly be limited to the kind of thing where you check something client-side (like whether a username meets the requirements) and then re-check it server-side because security 101. Client-side code is about displaying things, turning JSON into buttons and widgets, etc. There is no point having that on server-side. The server does not have a human user clicking buttons and scrolling bars. Server-side code is about performing calculations and facilitating communication between different clients. If these can be done client-side, then there's no reason to do them server-side in the first place. >An investment in vanilla JS will pay out in long term This is true, but a lot of JS investment is not in vanilla, it's in whatever framework is popular that week, and next week that framework will be dropped like bellbottom pants.
  - falcolas 12y ago
    > Client-side code is about displaying things Actually, JS developers are learning that this is frequently better done on the server; there are more and more articles every week about the benefits of pre-rendering the application page on the server side, then letting the client JS take over and make the server generated code responsive. I believe the term being used is "isomorphic" javascript. However, since the Node.js server is inherently single threaded, the cost of generating these templates server side impacts every connection being handled by that particular instance.
    - xamuel 12y ago
      What JS developers call "pre-rendering" is what everyone else has been calling "not a static webpage" since forever. It takes willful blindness to ride around on a bike with square wheels, ignore the round-wheel bikes around you, then eventually switch to round-wheel yourself and act like you invented it and it's the next big thing.
      - username223 12y ago
        Well, some of these guys are also riding single-speed fixies over a century after the invention of the derailleur and freewheel. I'm not hip enough to know if (extraordinarily dangerous) penny-farthings are coming back yet.

stephenr 12y ago

Also, having just looks at the article: > having the same language in client and server can simplify the data management between them That isn't called "simplified data management" it's called tightly coupled. What backend language/framework doesn't support json, xml (and even html fragments) for working with a JS frontend?

br3w5 12y ago

So if the server side stuff was written in node, that is a js framework and still requires a learning curve for developers if they don't already know node. Also you shouldn't choose your server side language/framework based on the fact it's the same as the front-end code. And you still need to have a clear and well documented API for the server side app - just using js isn't going to solve that problem. If you do solve that problem, in any language, then is implementing it in js really a necessity (apart from maybe a skill issue i.e. do you need people with a mix of skills or just js devs but again, I can't see why this is a problem)?

vinceguidry 12y ago

Except that you're only reducing the complexity of your stack by exactly one syntax. You still will have different semantics for the front and back ends. You still will have a giant wall between the server and the client with the only way of getting stuff over it is throwing it with a really strong arm, i.e. passing it in through HTML or after the fact with AJAX. You still will have to drop down to HTML and CSS, with a template language and perhaps a CSS preprocessor. If you don't think HTML and CSS are both powerful, complex languages in their own right, you haven't made anything truly complex for the web yet. You still have to manage devops, which has its own ecosystem and suite of tools. Javascript and its prototypical object system is great for client-side scripting code, but a poor fit for server domain concepts. You're going to have to learn multiple tools, languages, paradigms anyway. So just suck it up and use a proper back end framework too. Node's pretty good, but it's not Rails.

deleted 12y ago

[deleted]