8 ms·

A little off-topic, but I figured the people reading the comments here would be the best place to ask. Why use JavaScript on the server at all? I've developed o

A little off-topic, but I figured the people reading the comments here would be the best place to ask. Why use JavaScript on the server at all? I've developed on both the front end and back end, and written non-trivial server-side code in a number of languages, and I don't see any use-case where JavaScript is "best-in-class." It seems like whether you're aiming for ease/speed of prototyping, pure performance, a good concurrency model, or... any other task I can think of, there's a better tool for the job. There seems to be a decent number of people and companies using Node, though, so let me know what I'm missing!

qaq 11y ago
Well at the very least your are missing isomorphic/universal apps. One case when it's best in class is edge servers backing mobile clients/SPAs that need to have millions of web sockets open. Tooling I can have single package manager for backend and frontend I can use same packages on backend and frontend. I can use single language to develop for Server,Web,Mobile.
tzaman 11y ago
One language to rule them all. There is no way to handle complex UIs in the browser without JavaScript. So while you absolutely need JS developers, why not make the API/backned in the same language so that you can hire additional developers that know the same language your existing employees already do. From an employer's perspective, it's easier to manage and (re-)allocate resources if need be. JavaScript is becoming the web darling (or it already is?), whether we like it or not. And with some nice syntactic improvements ES6 brings, I don't mind.
- moonchrome 11y ago
  >There is no way to handle complex UIs in the browser without JavaScript Dart, ClojureScript, TS (technically JS superset but still a considerable improvement) are just the ones I've used. And I'd rather use both of them on server (Dart/Clojure) than JS. There are other languages as well. ES6 is a pain in the ass - no browser supports it and using transpilers + polyfills and the JS build/package tools to set that up is a PITA that only grows as you add dependencies and it bloats your code size to be comparable or larger than the compile-to-JS languages without making the language significantly better.
  - enkephalin 11y ago
    do you honestly believe that ES6 is not an improvement for javascript? if so, why?
    - moonchrome 11y ago
      It's an improvement - but at this point ES6 is just another compile-to-JS language that needs to ship it's own standard library - except it's worse than all of the mentioned ones (it has no type checking, standard library is still meh, semantics are still good old JS semantics).
      - krisdol 11y ago
        What do you mean it's a compile to js language? I use ES6 with no transpilers.
        TranquilMarmot 11y ago
        Same here; I guess it really depends on who your target market is. So far, all the ES6 I've written works just fine in Chrome, Firefox, Safari, Opera, and Edge. The only browser that breaks everything is Internet Explorer, but it seems like general consensus these days is that IE is only used in enterprise applications where you're locked into it.
      - qwertyuiop924 11y ago
        Where are all the people who like dynamic languages? Do they just hide while other people duke it out over this? It just seems like everybody except me hates dynamism sometimes.
        EvanPlaice 11y ago
        I think ES6 is just in its in-between phase of adoption. The mainstream hasn't fully adopted it yet. As for the rest... The Coffeescript converts have moved on from the 'one true language' now that ES6 cherry-picked most of the good parts and people started realizing that CS source maps are buggy/inconsistent. Standards are for 'plebs' so they've moved on to the new shiney. By new shiney, I mean mimicing FP in Javascript and looking down on people who can't ELI5 monads and functors. Despite not being able to ELI5 monads and functors. Typescript, is really geared toward OOP devs who live in an IDE and compulsively twitch an invisible set of CTRL-SPACE keys when they get nervous. It's a well-known fact that Google is a OOP- heavy Java/C++ shop who have been developing algos in Java/C++ since their last CS course where they developed algos using Java/C++. It's within their best interest to get all of there desktop devs to convert to writing desktop apps on the web before all that penis pills/local singles ad money runs out. It's only a matter of time before we see the first JS AbstractFactoryFactoryServiceProvider class in the wild. Angular2 has made considerable progress on this front so far. /satire Honestly, I really enjoy ES6. The JS dev communities favorite past time is ragging on how ridiculously bad JS is. ES6 isn't bad so it's not worth talking about. The new features introduced in ES6 are pretty conservative. They consist of good concepts poached directly from popular superset languages or sensible additions that fit in nicely with the usual JS style. The really interesting additions are still in the specification phase. Additions, such as the new ES6 module and loader standard, decorators, native HTTP fetch, etc... As long as new standards are being introduced, transpiling will continue to be a requirement. I think it's cool that people can create and use new supersets of JS. It beats having to listen to them whine about how 'Javascript isn't exactly like some other language that I really like to use.' In a way it's the first democratic programming language. Instead of dictating what people should and shouldn't use, people are free to migrate around to different communities until they find one that more closely matches their worldview. Everybody follows the same baseline standard but there's a lot of legroom for differentiation. Why axegrind over our differences when we can celebrate them and start working together.
- cantagi 11y ago
  That's not really an argument for writing server code in javascript, since you could instead find a way of transpiling your favourite language to javascript and use it on the client and server. I give you typescript, clojurescript, haste, and GHCJS as examples.
  - Wintamute 11y ago
    That would depend a lot on the story for using npm modules in your favourite language and your transpiled code. If it's not possible, it's a non-starter. And why would you write ClojureScript to use on the server, when you could just use Clojure?
- bottled_poe 11y ago
  If your developers only know JavaScript, they probably shouldn't be let anywhere near your backend. Any decent developer can rapidly pick up any other language.
  - tzaman 11y ago
    I could not disagree more. Rapidly picking up any language is simply not possible (unless you're a genious). Because the language is not just the syntax; It's its history and evolution, design choices, documentation (or lack thereof), community (both kindness/aproachability and responsiveness), leadership, etc. It takes time. Which sometimes, as an employer, I'm not willing to invest in. Because money. Plus you've somehow managed to state that JS developers are not decent enough.
- wslh 11y ago
  I don't want to restart a flame war but after choosing NodeJS for some projects based on specific modules not available in other languages (e.g: bitcore*) I am moving away or leaving it for very specific tasks. The code we wrote more than one year ago making an SQL transaction in 8 statements with async is difficult to understand and have some implicit stuff that you need to take into account. The other problem is not having a multithreading environment (in the official release) because you may want to respond to new tasks instead of blocking the event loop. I have seen timeouts because of this. Even if the recommendation is to do simple tasks, you can't enforce this when using hundreds of third party modules.
  - Wintamute 11y ago
    With the up-most respect, and we've all been there, but I would submit that maybe you just didn't write your Node code very well? Written properly, async code shouldn't be hard to understand. And there are tons of ways to spin up a new process or worker to execute a task without blocking the event loop of the main app. I mean, I could go away and use my limited experience to write a small project in Python to do a specific task ... but if it turned out to have deficiencies I wouldn't blame Python, rather my limited experience. Next time you need something written in Node, why not hire a experienced Node dev? And what is this recommendation to do simple tasks? I never heard that :)
  - rco8786 11y ago
    How did you manage to block the event loop? For all of JS's warts, the language makes it basically impossible to do this.
    - wslh 11y ago
      If you use a module which uses longer cryptographic operations it is possible.
      - rco8786 11y ago
        OP said he was making a SQL transaction.
- davedx 11y ago
  What I'm missing at our current place is being able to share business logic code between the client and server. Even simple things like validations that are run in both environments would be nice to not have to rewrite and maintain in two languages. Meteor excels at this.
- johnnydoebk 11y ago
  > One language to rule them all. > JavaScript is becoming the web darling (or it already is?) I wonder, will it be still as popular if WebAssembly let us use any programming language on the client? I mean post MVP WebAssembly with support of GC, DOM, and so forth.
  - s_kilk 11y ago
    I suspect the Javascript-or-death crowd are a (vocal) minority of web developers. Most will jump at the chance to use whatever language they please in the browser.
dev360 11y ago
I cant answer for keithwhor I think websocket support is a huge + for picking nodejs. Lately rails got their socket support, and python3 has been getting better support through async, but in both those languages, I've long felt its been pretty experimental, and there simply hasnt been a performant option available that has a good opinionated framework. Nodejs has performance going for it at least if you look at the language benchmarks, and now with ES6, it feels like the language is finally starting to shape up.
- keithwhor 11y ago
  Nodal doesn't have built-in socket support right now but the benefits of non-blocking IO in node are obviously huge. (It will. I just want to make sure I do integrated socket support right. I don't want to chase realtime frameworks because that's not Nodal's value prop, but I do want it to be easy to create socket connections when they're needed.)
- irregularexp 11y ago
  Elixir + Phoenix seems like a better choice if websockets is going to be a core feature, since the BEAM's concurrency model is better and Phoenix's "Channels" abstraction is so solid. I wouldn't think of using Rails for that use case, even with ActionCable in tow, unless it was a minor feature.
  - dev360 11y ago
    YES!!! I've been looking very carefully at this, but Elixir still feels intimidating to me. A friend of me gave me an ebook which I'm working through at the moment. For me, the jury is still out on whether I will be able to model my domain well in a language like Elixir.. I love Haskell, but I sometimes wonder if its a healthy attitude to be so stubbornly against OO. That said, I understand the arguments against essentially `this` and mutability. Any pointers on how to model your domain model in FP would be really welcome!
zodiac 11y ago
> ease/speed of prototyping, pure performance, a good concurrency model out of curiosity, which language + library/framework pairs do you think is a better tool than javascript + nodejs when evaluated along each of your 3 metrics? I moved from python + flask to nodejs a while ago, I still thing nodejs is better than python + flask, but I'm trying to move away from javascript on the backend.
- irregularexp 11y ago
  I choose Rails for fast prototyping, recently Go if I want pure performance that I can't get from caching, and Elixir + Phoenix if I need a good concurrency model and/or high throughput, but don't necessarily care about the microseconds that can be shaved off with Go.
  - matthewrudy 11y ago
    That's interesting. I should do some real world benchmarks on Elixir vs Go for my own purposes. But I'd imagine if you really care about microseconds, you should use a language without GC. Rust would seem a good choice.
  - Scarbutt 11y ago
    I think the issue there for most is that you mentioned three different programming languages.
- spoiler 11y ago
  >> ease/speed of prototyping, pure performance, a good concurrency model > out of curiosity, which language + library/framework pairs do you think is a better tool than javascript + nodejs when evaluated along each of your 3 metrics? ease/speed of prototyping: Ruby (or Python, even), Go, [Crystal] pure performance: Go, Rust, C++, C, Scala, [Crystal] a good concurrency model: Erlang, Go, [Crystal (similar to Go)] A small note about why Crystal is in brackets: The language is very young compared to the rest, and it's currently very volatile in terms of syntax/API stability, or even compiler semantics, but it looks very promising and it's quite easy to get started with it or to become a contributor because the compiler is written in itself. http://crystal-lang.org/ http://crystal-lang.org/ (Sadly, /docs is a bit outdated and misses some crucial parts, but /api is very comprehensive).
gldalmaso 11y ago
I believe the main selling point is sharing business code in both client and server, recently known as Isomorphic Javascript Applications. I think that this is specially appealing for people that are building offline enabled clients, which end up having to handle more business logic than usual for client-side code.
- tomelders 11y ago
  A big chunk of UI work is typically input validation which should happen client side and server side. And you'll usually need regex for this at somepoint. Having the same validation logic and regex engine on either side is a huge win.
  - Keats 11y ago
    In practice that depends on the app quite a bit, something like http://marshmallow.readthedocs.org/en/latest/ http://marshmallow.readthedocs.org/en/latest/ makes validation a breeze on the backend for an API and you will need the database for more complex ones anyway. Again that probably depends on the app, but the only duplication in mine right now would be the password length which is a 1 character change.
- deleted 11y ago
  [deleted]
chaostheory 11y ago
> Why use JavaScript on the server at all? One major advantage I can see is if you're a full stack dev. You don't have a switch languages when you're building the backend and the front end. Some people may not see this as an advantage, but personally it takes some time for my brain to switch to javascript for the front end when I've been using either java, python, or ruby for the backend.
- enkephalin 11y ago
  i could imagine that a decent full stack dev would rather use the right tool for the right job. thinking your scenario further, you would use something like couchdb instead of a relational db, because it utilizes javascript.
  - chaostheory 11y ago
    > i could imagine that a decent full stack dev would rather use the right tool for the right job. The right tool depends on the requirements. If there's no special requirements then I don't see why javascript can't be a substitute for ruby, python, php, or perl on the backend. > you would use something like couchdb instead of a relational db I'm not sure this is a good analogy since javascript (as well as the backend languages that it seeks to substitute for) is more of a general purpose tool, and not a super specialized datastore.
  - deleted 11y ago
    [deleted]
enkephalin 11y ago
i just started my first node project for the simple reason that i need 70% of the functionality of the application on both the server and the client.
wootez 11y ago
Everyone knows how to javascript, that's why it's the best. It's really that simple, put yourself in a position where you have to hire, you'll see why.
- enkephalin 11y ago
  that's like letting surgeons operate with kitchen knives, because everybody has experience with those.
  - humbleMouse 11y ago
    Haha, that's a really good metaphor :)
  - Gigablah 11y ago
    If you hire surgeons to cook meals, then by all means let them use kitchen knives.
hellbanTHIS 11y ago
developers developers developers! For example I'm taking some front end javascript I've been working on and putting it on the server (using another new node framework based on Laravel that so far I really like: http://adonisjs.com http://adonisjs.com ) and it would definitely perform better if I rewrote it in Go or Elixir - but even if I could figure out how to do that if the thing takes off I could never find anyone to help me with it. With JS though it should perform reasonably well (node is supposedly pretty fast where it counts, nonblocking and all that) and I could hire a danged high school kid to give me a hand with it if it somehow succeeds. I imagine a company like Walmart was thinking along those same lines when it chose Node.
dustingetz 11y ago
Client/server data sync and optimizations like server side rendering are easier with code-sharing between client and server. Though as far as I can tell, this framework doesn't leverage code sharing for either purpose.
anatari 11y ago
The one language to rule them all reasoning is a red herring. We chose nodejs for our server code for an iOS app as do many others. The reason why JS + node is popular is becasue it's pretty good at each of the metrics you mentioned. Even though it's not best in class at any one of those, it is well balanced for many tasks. Many other technologies are either too slow, too low level, too hard to scale, or too cumbersome to work with.
Wintamute 11y ago
- Yes there are better tools individually for prototyping, perf, concurrency ... but Node does pretty well on all this points, so it's arguably a strong all rounder - Node's package manager npm is fantastic, and (imo) gets package management more right than 90% of other package managers - There are 1000s of high quality actively maintained modules on npm to get you started on things (and 1000s of garbage ones, so you have to be careful) - The "holy grail" web app architecture (server rendering of frontend JS components coupled with client side rendering in a SPA) is only possible by running some JS on the server - Sharing JS UI components between the backend and frontend is a huge DX and productivity win - Another huge maintenance win is using the same language across the whole stack (frontend, backend and devops/automation) - With ES6, JS is slowly turning into a pretty cute language, check it out :) - A nice level of cross-pollination between JS and those geniuses in the ClojureScript community is bringing some really nice functional programming approaches and projects to Node/JS - You can use Node and JS to compile to both native desktop apps and native mobile apps. Having a centralised UI library of JS components that you can leverage for your desktop app, mobile app, frontend SPA and backend static rendering sounds pretty good to me!
- yulaow 11y ago
  I would just like to disagree on the "high quality" of modules. Personally I worked for a year in a very long lasting project about a specific type of social network. In the team I was the first one to push for the use of nodejs, react and mongo and... my god if I regretted it. The quality of node package is very bad in general. Like the most part are totally garbage. I don't know from where you come and what you used before, I worked only with java, php and ruby for the backend and in those i found: - far higher Documentation quality... like, node modules documentation is not even REMOTELY comparable: it is often extremely outdated, with very poor examples, the most of the times these example are not even working or are using functions deprecated since 3-4 versions of the module itself. - a infinite amount of bugs and undocumented behaviors rarely already reported and, when reported, just ignored for months. I usually would find infinite workarounds instead of solutions - extreme use of "I can do it better, so here my fork". I passed the big part of the time running from bug report to bug report and reading in the comments discussions about "The main maintainer of this package does not want to solve this problem of mine... so i made this other module, totally identical to this one but I just added this little hack, which totally broke the standard way of doinf things of this module, some functionalities I needed and never implemented the last 8-9 months of commits here." and chain this. Like this happened a dozen time each months when someone suggested "Why we don't try this module that says it solve our needs?" - No standards anywhere.
dbattaglia 11y ago
At this point you can probably say choosing node/js is similar to why you would choose Ruby or Python or PHP for your backend, it's another scripting language that offers decent performance, a large ecosystem and good developer productivity. It really boils down to preference in syntax, tooling and ethos ("micro frameworks", "batteries included" or somewhere in between). At this point I'm so comfortable in JS that I can be very productive in Node compared to the ramp up time I would require for Rails, django etc.
bryanlarsen 11y ago
Another reason : you can send ops over the wire rather than data. For example, you can send "add 7 to x" when the user makes a change rather than "set x to 21". Then you use the same code on server and client side to execute the ops. If you structure your ops to be reorderable and composable you can get nice stuff like multi user editing, arbitrary undo, multi data centre synchronization, etc. See the google docs papers for more details.
- paulpepper 11y ago
  Can you offer any references to the google docs papers that you refer to?
  - bryanlarsen 11y ago
    Google for "Operational Transformation". That turns up lots of good stuff. The wikipedia article includes links to Google Wave papers, which I think is the papers I'm referring to. It's been several years since I read them, though.
impostervt 11y ago
I use it on the server because I like javascript.
- hitgeek 11y ago
  I think this is the correct answer.
rdtsc 11y ago
I wouldn't use it. 1) Bad concurrency model -- callbacks, promises and futures are in general inferior abstraction model compared to green threads, actors, regular threads. Performance-wise it might do well in some scenarios but you are forced to use a more complicated abstraction to get that performance It is not worth it. In general it is appealing because it looks simple in small demos, as applications grow it becomes a mess. 2) npm modules are easy to use and that's great. Good model (well maybe except for deep nesting which breaks based on max path in say Windows, but I hear they are fixing that). The problems I found was that a lot of modules were of low quality. Code half-finished, buggy, developer moved on to something else, etc. Somehow it seems more so than say in the Python community. 3) Javascript is not the best language. There is a reason there is a "Javascript: The Good Parts" book. Because there are lot of crazy decisions made in it originally and a lot of bad "parts". If there was a choice between FORTRAN, Cobol and Javascript. I would pick Javascript hands down, but there are other languages out there today. However. If all you know is Javascript and you want to write a small demo, then go for it. It will be the least friction. So with all this complaining and whining, how about some constructive stuff. What language / frameworks might be more interesting / better. 1) Go : good concurrency model, supported by a large community, good performance. Lots of big companies use it. 2) Elixir : new kid on the block, fun, one of the friendliest communities. Probably best concurrency model -- actors. It uses Erlang's VM, so that part is rock solid, battle tested for many years. But not as many libraries. But can use existing Erlang libraries from it. Also best for reliability and fault-tolerance. 3) Python : easy to learn, lots of libraries, lots of material how to use it. This is my go-to language to get stuff done quickly. Try Python 3 if you start from scratch. 4) Clojure, Scala, Java: run on JVM. Battle tested, probably lots of libraries. Personally not as familiar with it, most enterprise and big sites out there run on the JVM currently.
- Tloewald 11y ago
  If you want to level constructive criticism, then set aside language prejudice. Obviously, if you don't like javascript, move on. It's great you like Python. Use a Python framework. You can point out Javascript's warts and we can laugh at the Python 3 migration. (And really, both of these criticisms are out of date. Javascript is _fine_ these days and Python 3 is moving towards backwards compatibility; sure Javascript has warts, but that's because it's backwards-compatible. You know, like... never mind.)
JohnDotAwesome 11y ago
As a developer, doesn't it make you _itch_ when you repeat yourself? Do you feel that itch when you repeat the same application logic on the server as you do on the client? Getting the client-side validation in-sync with the server validation? This is where JavaScript is fan-fucking-tastic. All of my recent projects have been isomorphic react apps. I build my app like it were a fully client-side single page web app, but I get server rendering when there's a new http request. Once the page has rendered, the web app takes over and uses history pushState. There are very few pieces of code that aren't used in both places. Once you get the hang of it, you very naturally create mockable interfaces that can be swapped depending on environment. In my opinion, this is pretty much the only category that makes JavaScript "Best-in-class"; It's the easiest language to build isomorphic web apps.
- it_learnses 11y ago
  What are your thoughts on Meteor?
  - morenoh149 11y ago
    good for prototypes. Just build your software.
- brndn 11y ago
  What does your software stack look like for that?
  - JohnDotAwesome 11y ago
    Currently- * Babel - ESNext - JSX * Gulp * Browserify - Incremental * Express * React router * Rolled my own flux - This was interesting because I didn't truly understand flux when I started - I _get it_ now The routes on the server are the same routes on the client. When the server renders, React/ReactRouter take over on the client and use history pushState. And that's actually about it. There aren't any other major libs that change the nature of the project. One thing I'm looking to do next is get hot reloading working and to somehow cut down on the initial compile times.
curun1r 11y ago
Node is too often conflated with JavaScript. This is understandable, considering JavaScript is the interface between the developer and the platform. But as crazy as this might sound, JavaScript is an implementation detail of the Node platform, not a defining characteristic. For instance, there's a project [1] that replaces JavaScript in Node with Lua. But if you go back to the origin story of Node, it's all about libev (though it now uses libuv for the same purpose) and that pervasively-asynchronous mindset. JavaScript was chosen as the developer interface because it met the need to support that asynchronous philosophy. The result is that everything in the Node world is asynchronous and asynchronous is the path of least resistance for the developer. Other platforms that weren't conceived with this mindset often force developers to fight to be asynchronous. > It seems like whether you're aiming for ease/speed of prototyping, pure performance, a good concurrency model... It's a mistake to look at JavaScript as a fit for all of this. Instead, you should consider how the Node platform fills the need. For easy of prototyping, it's not JavaScript that makes Node excel, it's npm. The only package management system I've found that I prefer to npm is Rust's Cargo. And npm is still well ahead of Cargo in the richness of the package ecosystem. For pure performance, you can always write a native Node addon [2]. And, as mentioned, while JavaScript isn't concurrent at all, the Node platform provides the concurrency model in a way that has proven to be scalable but without most of the pain that comes with writing concurrent code. Writing concurrent code is hard...that's not news. The Node framework make writing concurrent code significantly easier by creating abstractions that hide the the fact that code is concurrent. I know it's bizarre to look at it this way, since you would be writing most of your application logic in JavaScript, but try to look at it as an implementation detail and consider the advantages of the Node platform and the ecosystem that surrounds it. When you take this perspective, Node becomes a lot more attractive than the JavaScript language is on its own. [1] https://luvit.io/ https://luvit.io/ [2] https://nodejs.org/api/addons.html https://nodejs.org/api/addons.html

qaq 11y ago

Well at the very least your are missing isomorphic/universal apps. One case when it's best in class is edge servers backing mobile clients/SPAs that need to have millions of web sockets open. Tooling I can have single package manager for backend and frontend I can use same packages on backend and frontend. I can use single language to develop for Server,Web,Mobile.

tzaman 11y ago

One language to rule them all. There is no way to handle complex UIs in the browser without JavaScript. So while you absolutely need JS developers, why not make the API/backned in the same language so that you can hire additional developers that know the same language your existing employees already do. From an employer's perspective, it's easier to manage and (re-)allocate resources if need be. JavaScript is becoming the web darling (or it already is?), whether we like it or not. And with some nice syntactic improvements ES6 brings, I don't mind.

moonchrome 11y ago
>There is no way to handle complex UIs in the browser without JavaScript Dart, ClojureScript, TS (technically JS superset but still a considerable improvement) are just the ones I've used. And I'd rather use both of them on server (Dart/Clojure) than JS. There are other languages as well. ES6 is a pain in the ass - no browser supports it and using transpilers + polyfills and the JS build/package tools to set that up is a PITA that only grows as you add dependencies and it bloats your code size to be comparable or larger than the compile-to-JS languages without making the language significantly better.
- enkephalin 11y ago
  do you honestly believe that ES6 is not an improvement for javascript? if so, why?
  - moonchrome 11y ago
    It's an improvement - but at this point ES6 is just another compile-to-JS language that needs to ship it's own standard library - except it's worse than all of the mentioned ones (it has no type checking, standard library is still meh, semantics are still good old JS semantics).
    - krisdol 11y ago
      What do you mean it's a compile to js language? I use ES6 with no transpilers.
      - TranquilMarmot 11y ago
        Same here; I guess it really depends on who your target market is. So far, all the ES6 I've written works just fine in Chrome, Firefox, Safari, Opera, and Edge. The only browser that breaks everything is Internet Explorer, but it seems like general consensus these days is that IE is only used in enterprise applications where you're locked into it.
    - qwertyuiop924 11y ago
      Where are all the people who like dynamic languages? Do they just hide while other people duke it out over this? It just seems like everybody except me hates dynamism sometimes.
      - EvanPlaice 11y ago
        I think ES6 is just in its in-between phase of adoption. The mainstream hasn't fully adopted it yet. As for the rest... The Coffeescript converts have moved on from the 'one true language' now that ES6 cherry-picked most of the good parts and people started realizing that CS source maps are buggy/inconsistent. Standards are for 'plebs' so they've moved on to the new shiney. By new shiney, I mean mimicing FP in Javascript and looking down on people who can't ELI5 monads and functors. Despite not being able to ELI5 monads and functors. Typescript, is really geared toward OOP devs who live in an IDE and compulsively twitch an invisible set of CTRL-SPACE keys when they get nervous. It's a well-known fact that Google is a OOP- heavy Java/C++ shop who have been developing algos in Java/C++ since their last CS course where they developed algos using Java/C++. It's within their best interest to get all of there desktop devs to convert to writing desktop apps on the web before all that penis pills/local singles ad money runs out. It's only a matter of time before we see the first JS AbstractFactoryFactoryServiceProvider class in the wild. Angular2 has made considerable progress on this front so far. /satire Honestly, I really enjoy ES6. The JS dev communities favorite past time is ragging on how ridiculously bad JS is. ES6 isn't bad so it's not worth talking about. The new features introduced in ES6 are pretty conservative. They consist of good concepts poached directly from popular superset languages or sensible additions that fit in nicely with the usual JS style. The really interesting additions are still in the specification phase. Additions, such as the new ES6 module and loader standard, decorators, native HTTP fetch, etc... As long as new standards are being introduced, transpiling will continue to be a requirement. I think it's cool that people can create and use new supersets of JS. It beats having to listen to them whine about how 'Javascript isn't exactly like some other language that I really like to use.' In a way it's the first democratic programming language. Instead of dictating what people should and shouldn't use, people are free to migrate around to different communities until they find one that more closely matches their worldview. Everybody follows the same baseline standard but there's a lot of legroom for differentiation. Why axegrind over our differences when we can celebrate them and start working together.
cantagi 11y ago
That's not really an argument for writing server code in javascript, since you could instead find a way of transpiling your favourite language to javascript and use it on the client and server. I give you typescript, clojurescript, haste, and GHCJS as examples.
- Wintamute 11y ago
  That would depend a lot on the story for using npm modules in your favourite language and your transpiled code. If it's not possible, it's a non-starter. And why would you write ClojureScript to use on the server, when you could just use Clojure?
bottled_poe 11y ago
If your developers only know JavaScript, they probably shouldn't be let anywhere near your backend. Any decent developer can rapidly pick up any other language.
- tzaman 11y ago
  I could not disagree more. Rapidly picking up any language is simply not possible (unless you're a genious). Because the language is not just the syntax; It's its history and evolution, design choices, documentation (or lack thereof), community (both kindness/aproachability and responsiveness), leadership, etc. It takes time. Which sometimes, as an employer, I'm not willing to invest in. Because money. Plus you've somehow managed to state that JS developers are not decent enough.
wslh 11y ago
I don't want to restart a flame war but after choosing NodeJS for some projects based on specific modules not available in other languages (e.g: bitcore*) I am moving away or leaving it for very specific tasks. The code we wrote more than one year ago making an SQL transaction in 8 statements with async is difficult to understand and have some implicit stuff that you need to take into account. The other problem is not having a multithreading environment (in the official release) because you may want to respond to new tasks instead of blocking the event loop. I have seen timeouts because of this. Even if the recommendation is to do simple tasks, you can't enforce this when using hundreds of third party modules.
- Wintamute 11y ago
  With the up-most respect, and we've all been there, but I would submit that maybe you just didn't write your Node code very well? Written properly, async code shouldn't be hard to understand. And there are tons of ways to spin up a new process or worker to execute a task without blocking the event loop of the main app. I mean, I could go away and use my limited experience to write a small project in Python to do a specific task ... but if it turned out to have deficiencies I wouldn't blame Python, rather my limited experience. Next time you need something written in Node, why not hire a experienced Node dev? And what is this recommendation to do simple tasks? I never heard that :)
- rco8786 11y ago
  How did you manage to block the event loop? For all of JS's warts, the language makes it basically impossible to do this.
  - wslh 11y ago
    If you use a module which uses longer cryptographic operations it is possible.
    - rco8786 11y ago
      OP said he was making a SQL transaction.
davedx 11y ago
What I'm missing at our current place is being able to share business logic code between the client and server. Even simple things like validations that are run in both environments would be nice to not have to rewrite and maintain in two languages. Meteor excels at this.
johnnydoebk 11y ago
> One language to rule them all. > JavaScript is becoming the web darling (or it already is?) I wonder, will it be still as popular if WebAssembly let us use any programming language on the client? I mean post MVP WebAssembly with support of GC, DOM, and so forth.
- s_kilk 11y ago
  I suspect the Javascript-or-death crowd are a (vocal) minority of web developers. Most will jump at the chance to use whatever language they please in the browser.

dev360 11y ago

I cant answer for keithwhor I think websocket support is a huge + for picking nodejs. Lately rails got their socket support, and python3 has been getting better support through async, but in both those languages, I've long felt its been pretty experimental, and there simply hasnt been a performant option available that has a good opinionated framework. Nodejs has performance going for it at least if you look at the language benchmarks, and now with ES6, it feels like the language is finally starting to shape up.

keithwhor 11y ago
Nodal doesn't have built-in socket support right now but the benefits of non-blocking IO in node are obviously huge. (It will. I just want to make sure I do integrated socket support right. I don't want to chase realtime frameworks because that's not Nodal's value prop, but I do want it to be easy to create socket connections when they're needed.)
irregularexp 11y ago
Elixir + Phoenix seems like a better choice if websockets is going to be a core feature, since the BEAM's concurrency model is better and Phoenix's "Channels" abstraction is so solid. I wouldn't think of using Rails for that use case, even with ActionCable in tow, unless it was a minor feature.
- dev360 11y ago
  YES!!! I've been looking very carefully at this, but Elixir still feels intimidating to me. A friend of me gave me an ebook which I'm working through at the moment. For me, the jury is still out on whether I will be able to model my domain well in a language like Elixir.. I love Haskell, but I sometimes wonder if its a healthy attitude to be so stubbornly against OO. That said, I understand the arguments against essentially `this` and mutability. Any pointers on how to model your domain model in FP would be really welcome!

zodiac 11y ago

> ease/speed of prototyping, pure performance, a good concurrency model out of curiosity, which language + library/framework pairs do you think is a better tool than javascript + nodejs when evaluated along each of your 3 metrics? I moved from python + flask to nodejs a while ago, I still thing nodejs is better than python + flask, but I'm trying to move away from javascript on the backend.

irregularexp 11y ago
I choose Rails for fast prototyping, recently Go if I want pure performance that I can't get from caching, and Elixir + Phoenix if I need a good concurrency model and/or high throughput, but don't necessarily care about the microseconds that can be shaved off with Go.
- matthewrudy 11y ago
  That's interesting. I should do some real world benchmarks on Elixir vs Go for my own purposes. But I'd imagine if you really care about microseconds, you should use a language without GC. Rust would seem a good choice.
- Scarbutt 11y ago
  I think the issue there for most is that you mentioned three different programming languages.
spoiler 11y ago
>> ease/speed of prototyping, pure performance, a good concurrency model > out of curiosity, which language + library/framework pairs do you think is a better tool than javascript + nodejs when evaluated along each of your 3 metrics? ease/speed of prototyping: Ruby (or Python, even), Go, [Crystal] pure performance: Go, Rust, C++, C, Scala, [Crystal] a good concurrency model: Erlang, Go, [Crystal (similar to Go)] A small note about why Crystal is in brackets: The language is very young compared to the rest, and it's currently very volatile in terms of syntax/API stability, or even compiler semantics, but it looks very promising and it's quite easy to get started with it or to become a contributor because the compiler is written in itself. http://crystal-lang.org/ http://crystal-lang.org/ (Sadly, /docs is a bit outdated and misses some crucial parts, but /api is very comprehensive).

gldalmaso 11y ago

I believe the main selling point is sharing business code in both client and server, recently known as Isomorphic Javascript Applications. I think that this is specially appealing for people that are building offline enabled clients, which end up having to handle more business logic than usual for client-side code.

tomelders 11y ago
A big chunk of UI work is typically input validation which should happen client side and server side. And you'll usually need regex for this at somepoint. Having the same validation logic and regex engine on either side is a huge win.
- Keats 11y ago
  In practice that depends on the app quite a bit, something like http://marshmallow.readthedocs.org/en/latest/ http://marshmallow.readthedocs.org/en/latest/ makes validation a breeze on the backend for an API and you will need the database for more complex ones anyway. Again that probably depends on the app, but the only duplication in mine right now would be the password length which is a 1 character change.
deleted 11y ago
[deleted]

chaostheory 11y ago

> Why use JavaScript on the server at all? One major advantage I can see is if you're a full stack dev. You don't have a switch languages when you're building the backend and the front end. Some people may not see this as an advantage, but personally it takes some time for my brain to switch to javascript for the front end when I've been using either java, python, or ruby for the backend.

enkephalin 11y ago
i could imagine that a decent full stack dev would rather use the right tool for the right job. thinking your scenario further, you would use something like couchdb instead of a relational db, because it utilizes javascript.
- chaostheory 11y ago
  > i could imagine that a decent full stack dev would rather use the right tool for the right job. The right tool depends on the requirements. If there's no special requirements then I don't see why javascript can't be a substitute for ruby, python, php, or perl on the backend. > you would use something like couchdb instead of a relational db I'm not sure this is a good analogy since javascript (as well as the backend languages that it seeks to substitute for) is more of a general purpose tool, and not a super specialized datastore.
- deleted 11y ago
  [deleted]

enkephalin 11y ago

i just started my first node project for the simple reason that i need 70% of the functionality of the application on both the server and the client.

wootez 11y ago

Everyone knows how to javascript, that's why it's the best. It's really that simple, put yourself in a position where you have to hire, you'll see why.

enkephalin 11y ago
that's like letting surgeons operate with kitchen knives, because everybody has experience with those.
- humbleMouse 11y ago
  Haha, that's a really good metaphor :)
- Gigablah 11y ago
  If you hire surgeons to cook meals, then by all means let them use kitchen knives.

hellbanTHIS 11y ago

developers developers developers! For example I'm taking some front end javascript I've been working on and putting it on the server (using another new node framework based on Laravel that so far I really like: http://adonisjs.com http://adonisjs.com ) and it would definitely perform better if I rewrote it in Go or Elixir - but even if I could figure out how to do that if the thing takes off I could never find anyone to help me with it. With JS though it should perform reasonably well (node is supposedly pretty fast where it counts, nonblocking and all that) and I could hire a danged high school kid to give me a hand with it if it somehow succeeds. I imagine a company like Walmart was thinking along those same lines when it chose Node.

dustingetz 11y ago

Client/server data sync and optimizations like server side rendering are easier with code-sharing between client and server. Though as far as I can tell, this framework doesn't leverage code sharing for either purpose.

anatari 11y ago

The one language to rule them all reasoning is a red herring. We chose nodejs for our server code for an iOS app as do many others. The reason why JS + node is popular is becasue it's pretty good at each of the metrics you mentioned. Even though it's not best in class at any one of those, it is well balanced for many tasks. Many other technologies are either too slow, too low level, too hard to scale, or too cumbersome to work with.

Wintamute 11y ago

- Yes there are better tools individually for prototyping, perf, concurrency ... but Node does pretty well on all this points, so it's arguably a strong all rounder - Node's package manager npm is fantastic, and (imo) gets package management more right than 90% of other package managers - There are 1000s of high quality actively maintained modules on npm to get you started on things (and 1000s of garbage ones, so you have to be careful) - The "holy grail" web app architecture (server rendering of frontend JS components coupled with client side rendering in a SPA) is only possible by running some JS on the server - Sharing JS UI components between the backend and frontend is a huge DX and productivity win - Another huge maintenance win is using the same language across the whole stack (frontend, backend and devops/automation) - With ES6, JS is slowly turning into a pretty cute language, check it out :) - A nice level of cross-pollination between JS and those geniuses in the ClojureScript community is bringing some really nice functional programming approaches and projects to Node/JS - You can use Node and JS to compile to both native desktop apps and native mobile apps. Having a centralised UI library of JS components that you can leverage for your desktop app, mobile app, frontend SPA and backend static rendering sounds pretty good to me!

yulaow 11y ago
I would just like to disagree on the "high quality" of modules. Personally I worked for a year in a very long lasting project about a specific type of social network. In the team I was the first one to push for the use of nodejs, react and mongo and... my god if I regretted it. The quality of node package is very bad in general. Like the most part are totally garbage. I don't know from where you come and what you used before, I worked only with java, php and ruby for the backend and in those i found: - far higher Documentation quality... like, node modules documentation is not even REMOTELY comparable: it is often extremely outdated, with very poor examples, the most of the times these example are not even working or are using functions deprecated since 3-4 versions of the module itself. - a infinite amount of bugs and undocumented behaviors rarely already reported and, when reported, just ignored for months. I usually would find infinite workarounds instead of solutions - extreme use of "I can do it better, so here my fork". I passed the big part of the time running from bug report to bug report and reading in the comments discussions about "The main maintainer of this package does not want to solve this problem of mine... so i made this other module, totally identical to this one but I just added this little hack, which totally broke the standard way of doinf things of this module, some functionalities I needed and never implemented the last 8-9 months of commits here." and chain this. Like this happened a dozen time each months when someone suggested "Why we don't try this module that says it solve our needs?" - No standards anywhere.

dbattaglia 11y ago

At this point you can probably say choosing node/js is similar to why you would choose Ruby or Python or PHP for your backend, it's another scripting language that offers decent performance, a large ecosystem and good developer productivity. It really boils down to preference in syntax, tooling and ethos ("micro frameworks", "batteries included" or somewhere in between). At this point I'm so comfortable in JS that I can be very productive in Node compared to the ramp up time I would require for Rails, django etc.

bryanlarsen 11y ago

Another reason : you can send ops over the wire rather than data. For example, you can send "add 7 to x" when the user makes a change rather than "set x to 21". Then you use the same code on server and client side to execute the ops. If you structure your ops to be reorderable and composable you can get nice stuff like multi user editing, arbitrary undo, multi data centre synchronization, etc. See the google docs papers for more details.

paulpepper 11y ago
Can you offer any references to the google docs papers that you refer to?
- bryanlarsen 11y ago
  Google for "Operational Transformation". That turns up lots of good stuff. The wikipedia article includes links to Google Wave papers, which I think is the papers I'm referring to. It's been several years since I read them, though.

impostervt 11y ago

I use it on the server because I like javascript.

hitgeek 11y ago
I think this is the correct answer.

rdtsc 11y ago

I wouldn't use it. 1) Bad concurrency model -- callbacks, promises and futures are in general inferior abstraction model compared to green threads, actors, regular threads. Performance-wise it might do well in some scenarios but you are forced to use a more complicated abstraction to get that performance It is not worth it. In general it is appealing because it looks simple in small demos, as applications grow it becomes a mess. 2) npm modules are easy to use and that's great. Good model (well maybe except for deep nesting which breaks based on max path in say Windows, but I hear they are fixing that). The problems I found was that a lot of modules were of low quality. Code half-finished, buggy, developer moved on to something else, etc. Somehow it seems more so than say in the Python community. 3) Javascript is not the best language. There is a reason there is a "Javascript: The Good Parts" book. Because there are lot of crazy decisions made in it originally and a lot of bad "parts". If there was a choice between FORTRAN, Cobol and Javascript. I would pick Javascript hands down, but there are other languages out there today. However. If all you know is Javascript and you want to write a small demo, then go for it. It will be the least friction. So with all this complaining and whining, how about some constructive stuff. What language / frameworks might be more interesting / better. 1) Go : good concurrency model, supported by a large community, good performance. Lots of big companies use it. 2) Elixir : new kid on the block, fun, one of the friendliest communities. Probably best concurrency model -- actors. It uses Erlang's VM, so that part is rock solid, battle tested for many years. But not as many libraries. But can use existing Erlang libraries from it. Also best for reliability and fault-tolerance. 3) Python : easy to learn, lots of libraries, lots of material how to use it. This is my go-to language to get stuff done quickly. Try Python 3 if you start from scratch. 4) Clojure, Scala, Java: run on JVM. Battle tested, probably lots of libraries. Personally not as familiar with it, most enterprise and big sites out there run on the JVM currently.

Tloewald 11y ago
If you want to level constructive criticism, then set aside language prejudice. Obviously, if you don't like javascript, move on. It's great you like Python. Use a Python framework. You can point out Javascript's warts and we can laugh at the Python 3 migration. (And really, both of these criticisms are out of date. Javascript is _fine_ these days and Python 3 is moving towards backwards compatibility; sure Javascript has warts, but that's because it's backwards-compatible. You know, like... never mind.)

JohnDotAwesome 11y ago

As a developer, doesn't it make you _itch_ when you repeat yourself? Do you feel that itch when you repeat the same application logic on the server as you do on the client? Getting the client-side validation in-sync with the server validation? This is where JavaScript is fan-fucking-tastic. All of my recent projects have been isomorphic react apps. I build my app like it were a fully client-side single page web app, but I get server rendering when there's a new http request. Once the page has rendered, the web app takes over and uses history pushState. There are very few pieces of code that aren't used in both places. Once you get the hang of it, you very naturally create mockable interfaces that can be swapped depending on environment. In my opinion, this is pretty much the only category that makes JavaScript "Best-in-class"; It's the easiest language to build isomorphic web apps.

it_learnses 11y ago
What are your thoughts on Meteor?
- morenoh149 11y ago
  good for prototypes. Just build your software.
brndn 11y ago
What does your software stack look like for that?
- JohnDotAwesome 11y ago
  Currently- * Babel - ESNext - JSX * Gulp * Browserify - Incremental * Express * React router * Rolled my own flux - This was interesting because I didn't truly understand flux when I started - I _get it_ now The routes on the server are the same routes on the client. When the server renders, React/ReactRouter take over on the client and use history pushState. And that's actually about it. There aren't any other major libs that change the nature of the project. One thing I'm looking to do next is get hot reloading working and to somehow cut down on the initial compile times.

curun1r 11y ago

Node is too often conflated with JavaScript. This is understandable, considering JavaScript is the interface between the developer and the platform. But as crazy as this might sound, JavaScript is an implementation detail of the Node platform, not a defining characteristic. For instance, there's a project [1] that replaces JavaScript in Node with Lua. But if you go back to the origin story of Node, it's all about libev (though it now uses libuv for the same purpose) and that pervasively-asynchronous mindset. JavaScript was chosen as the developer interface because it met the need to support that asynchronous philosophy. The result is that everything in the Node world is asynchronous and asynchronous is the path of least resistance for the developer. Other platforms that weren't conceived with this mindset often force developers to fight to be asynchronous. > It seems like whether you're aiming for ease/speed of prototyping, pure performance, a good concurrency model... It's a mistake to look at JavaScript as a fit for all of this. Instead, you should consider how the Node platform fills the need. For easy of prototyping, it's not JavaScript that makes Node excel, it's npm. The only package management system I've found that I prefer to npm is Rust's Cargo. And npm is still well ahead of Cargo in the richness of the package ecosystem. For pure performance, you can always write a native Node addon [2]. And, as mentioned, while JavaScript isn't concurrent at all, the Node platform provides the concurrency model in a way that has proven to be scalable but without most of the pain that comes with writing concurrent code. Writing concurrent code is hard...that's not news. The Node framework make writing concurrent code significantly easier by creating abstractions that hide the the fact that code is concurrent. I know it's bizarre to look at it this way, since you would be writing most of your application logic in JavaScript, but try to look at it as an implementation detail and consider the advantages of the Node platform and the ecosystem that surrounds it. When you take this perspective, Node becomes a lot more attractive than the JavaScript language is on its own. [1] https://luvit.io/ https://luvit.io/ [2] https://nodejs.org/api/addons.html https://nodejs.org/api/addons.html