6 ms·

I recently looked at using Node for a simple API backend. ES6 seems like it's not there yet, the stability of Node makes me wary. Constant changes seem exhausti

I recently looked at using Node for a simple API backend. ES6 seems like it's not there yet, the stability of Node makes me wary. Constant changes seem exhausting to keep up with. For a simple microservice api you don't want to be upgrading it every 3 days. The continuous change doesn't make sense to me. Trying to get up to speed on all the Node.js ecosystem feels exhausting, only to have it change a few weeks later. Maybe someone using this daily for real APIs could comment if this is the case for them? I ended up opting for Flask and Python 3x instead, couldn't be happier. I had my API up and running within a day with no prior knowledge of Flask and some Python on and off. I've been able to discuss and teach other team members on it who were also able to pick it up easily.

agumonkey 11y ago
javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.
- Joeri 11y ago
  You jest, but this week i've been developing my first java web app using play framework, coming from a decade of PHP and javascript, and i found the experience surprisingly nice. You can get a good edit-refresh cycle going using incremental recompilation, and the api's are elegant and flexible. My preconceived notions of the verbosity and ugliness of java web app code proved unfounded.
  - agumonkey 11y ago
    Java was heavy, and still is but most of the perceived weight came from immaturity (the world wanted freeform template oriented scripts). Now all languages are moving towards types, packages/modules, conventions and structures. If a php3 dev discovers php 5.6 I'm sure he wouldn't enjoy it.
agumonkey 11y ago
javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.
alexwebb2 11y ago
No need to always be on the latest version. v4.2 is an LTS branch that will be supported for the next two and a half years. And with tools like nvm, it's incredibly easy to swap out different versions and go for a test drive.
- breck 11y ago
  "n" is another good node version manager that makes switching versions painless. https://github.com/tj/n https://github.com/tj/n
Killswitch 11y ago
Node.js keeps in line pretty heavily with V8, so if you're keeping up with changes in Chrome's JavaScript engine, you're already keeping up with Node. Plus you don't have to always upgrade to latest and greatest. If your app works fine in 4.2 and there's no crazy security issues you need to upgrade for, don't. 4.2 is LTS so it's going to get supported for a long time.
morgante 11y ago
There is continuous change, but the changes tend to be quite small. You can also safely stay on older versions for a long time (4.2 is LTS).
sotojuan 11y ago
You could've used Node 4.2 LTS and a simple Express server (is Flask the Express of Python?) and had as much stability. That said, I do understand your skepticism and concern.
- rplnt 11y ago
  I'd say bottle if you'd want to go for simple and small. Flask has two huge dependencies, one of which is template engine which you wouldn't need for a simple API.
matwood 11y ago
JS in general moves fast and packages range from great to WTF in quality. I would suggest using Babel(or something similar) for all future JS development. That way you can use ES2015/2016 features now and have them work in most environments. I have a built a small API using express and passport and so far these node changes have not impacted my code. Another option for fast API development is Java 8 with SpringBoot and Jetty. People hate on Java and Spring, but the latest versions of both are very powerful and easy to get going. If you end up needing more it is there.
- rhinoceraptor 11y ago
  Babel does some other magic that you might not realize, such as converting anonymous functions to named functions (and then assigning those to a variable of the same name).
  - matwood 11y ago
    It has some magic, but we already have to use polyfills to support multiple browser versions. I see something like Babel as the global polyfill of the future. Use latest es features now and have them go native over time.
- cdnsteve 11y ago
  But then you have to keep up with Babel changes too... http://babeljs.io/blog/2015/10/29/6.0.0/ http://babeljs.io/blog/2015/10/29/6.0.0/
  - merpnderp 11y ago
    Why this urge to keep up to the latest and greatest? Especially for a transpiler? If it is converting your code just fine, why update?
    - Goronmon 11y ago
      Probably the concern that waiting between updates means that if you are forced to update for some reason (critical bug or must-have feature) you have a tougher upgrade path.
rdtsc 11y ago
> I ended up opting for Flask and Python 3x instead Yap good choice. Python to me is more readable (so I can understand my own code and others' better) and I find the echo system to be friendlier and more mature.
- cglace 11y ago
  Funny how yesterday in the pypy thread it was all doom and gloom for python and yet in the real world people keep choosing it for new projects.
  - untog 11y ago
    Why was the pypy thread "not the real world" when this thread "is the real world"?
  - oldmanjay 11y ago
    It's almost like there are many people doing many things in many directions all at once!
bryanlarsen 11y ago
We have apps on Node v0.10, which is over 2.5 years old and will be supported for one more year.
- cdnsteve 11y ago
  3.5 years for an API, that's decently long, but dependent on industry. What does your upgrade path look like? Are you basically rewriting everything into ES6, aka starting over? Three years isn't long in a corporate environment.
  - bryanlarsen 11y ago
    We've lightly tested some of our components, and they work unchanged in Node 4. Heavier testing may find a couple of issues. The only reason we haven't switched is that need for heavier testing. No big rewrite will be needed.
    - cdnsteve 11y ago
      Good to know, thanks for responding back.
malandrew 11y ago
As an engineer, I assume you use a programming language and the libraries from its ecosystem to solve problems. Unless the latest features are essential to solving your problems, I would say this is unnecessary worry. We use both ES5 and ES6 (via transpilation) where I work. I had to write a lot of the tooling to support ES6 because a lot of front-end engineers were asking for ES6. To this day, I have yet to hear one engineer justify their "need" for ES6 with one of the features that make something easy that is hard or cumbersome with ES5. Pretty much every feature engineers were wanting to use were simple sugary syntax features like the spread operator that is trivially dealt with with a library like `xtend` (the irony is seeing these same engineers continue to use _.each on arrays instead of Array.prototype.forEach) There is a corollary to Wadler's Law in here somewhere: https://wiki.haskell.org/Wadler's_Law https://wiki.haskell.org/Wadler's_Law In any debate on the merits of migrating to ES6, the total number of times an ES6 feature is cited as justification to migrate to ES6 is proportional to two raised to the power of its position. 0. Semantic features 1. Syntax features 2. Lexical syntax features 3. Lexical syntax of comments features

agumonkey 11y ago

javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.

Joeri 11y ago
You jest, but this week i've been developing my first java web app using play framework, coming from a decade of PHP and javascript, and i found the experience surprisingly nice. You can get a good edit-refresh cycle going using incremental recompilation, and the api's are elegant and flexible. My preconceived notions of the verbosity and ugliness of java web app code proved unfounded.
- agumonkey 11y ago
  Java was heavy, and still is but most of the perceived weight came from immaturity (the world wanted freeform template oriented scripts). Now all languages are moving towards types, packages/modules, conventions and structures. If a php3 dev discovers php 5.6 I'm sure he wouldn't enjoy it.

agumonkey 11y ago

javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.

alexwebb2 11y ago

No need to always be on the latest version. v4.2 is an LTS branch that will be supported for the next two and a half years. And with tools like nvm, it's incredibly easy to swap out different versions and go for a test drive.

breck 11y ago
"n" is another good node version manager that makes switching versions painless. https://github.com/tj/n https://github.com/tj/n

Killswitch 11y ago

Node.js keeps in line pretty heavily with V8, so if you're keeping up with changes in Chrome's JavaScript engine, you're already keeping up with Node. Plus you don't have to always upgrade to latest and greatest. If your app works fine in 4.2 and there's no crazy security issues you need to upgrade for, don't. 4.2 is LTS so it's going to get supported for a long time.

morgante 11y ago

There is continuous change, but the changes tend to be quite small. You can also safely stay on older versions for a long time (4.2 is LTS).

sotojuan 11y ago

You could've used Node 4.2 LTS and a simple Express server (is Flask the Express of Python?) and had as much stability. That said, I do understand your skepticism and concern.

rplnt 11y ago
I'd say bottle if you'd want to go for simple and small. Flask has two huge dependencies, one of which is template engine which you wouldn't need for a simple API.

matwood 11y ago

JS in general moves fast and packages range from great to WTF in quality. I would suggest using Babel(or something similar) for all future JS development. That way you can use ES2015/2016 features now and have them work in most environments. I have a built a small API using express and passport and so far these node changes have not impacted my code. Another option for fast API development is Java 8 with SpringBoot and Jetty. People hate on Java and Spring, but the latest versions of both are very powerful and easy to get going. If you end up needing more it is there.

rhinoceraptor 11y ago
Babel does some other magic that you might not realize, such as converting anonymous functions to named functions (and then assigning those to a variable of the same name).
- matwood 11y ago
  It has some magic, but we already have to use polyfills to support multiple browser versions. I see something like Babel as the global polyfill of the future. Use latest es features now and have them go native over time.
cdnsteve 11y ago
But then you have to keep up with Babel changes too... http://babeljs.io/blog/2015/10/29/6.0.0/ http://babeljs.io/blog/2015/10/29/6.0.0/
- merpnderp 11y ago
  Why this urge to keep up to the latest and greatest? Especially for a transpiler? If it is converting your code just fine, why update?
  - Goronmon 11y ago
    Probably the concern that waiting between updates means that if you are forced to update for some reason (critical bug or must-have feature) you have a tougher upgrade path.

rdtsc 11y ago

> I ended up opting for Flask and Python 3x instead Yap good choice. Python to me is more readable (so I can understand my own code and others' better) and I find the echo system to be friendlier and more mature.

cglace 11y ago
Funny how yesterday in the pypy thread it was all doom and gloom for python and yet in the real world people keep choosing it for new projects.
- untog 11y ago
  Why was the pypy thread "not the real world" when this thread "is the real world"?
- oldmanjay 11y ago
  It's almost like there are many people doing many things in many directions all at once!

bryanlarsen 11y ago

We have apps on Node v0.10, which is over 2.5 years old and will be supported for one more year.

cdnsteve 11y ago
3.5 years for an API, that's decently long, but dependent on industry. What does your upgrade path look like? Are you basically rewriting everything into ES6, aka starting over? Three years isn't long in a corporate environment.
- bryanlarsen 11y ago
  We've lightly tested some of our components, and they work unchanged in Node 4. Heavier testing may find a couple of issues. The only reason we haven't switched is that need for heavier testing. No big rewrite will be needed.
  - cdnsteve 11y ago
    Good to know, thanks for responding back.

malandrew 11y ago

As an engineer, I assume you use a programming language and the libraries from its ecosystem to solve problems. Unless the latest features are essential to solving your problems, I would say this is unnecessary worry. We use both ES5 and ES6 (via transpilation) where I work. I had to write a lot of the tooling to support ES6 because a lot of front-end engineers were asking for ES6. To this day, I have yet to hear one engineer justify their "need" for ES6 with one of the features that make something easy that is hard or cumbersome with ES5. Pretty much every feature engineers were wanting to use were simple sugary syntax features like the spread operator that is trivially dealt with with a library like `xtend` (the irony is seeing these same engineers continue to use _.each on arrays instead of Array.prototype.forEach) There is a corollary to Wadler's Law in here somewhere: https://wiki.haskell.org/Wadler's_Law https://wiki.haskell.org/Wadler's_Law In any debate on the merits of migrating to ES6, the total number of times an ES6 feature is cited as justification to migrate to ES6 is proportional to two raised to the power of its position. 0. Semantic features 1. Syntax features 2. Lexical syntax features 3. Lexical syntax of comments features