
Node.js v9.2.0 - bricss
https://nodejs.org/en/blog/release/v9.2.0/
======
drinchev
Node.js and the community behind it are really great. It helped me put bread
on my table for several years now.

I remember I passed through all the "trends" around it and I'm super impressed
how fast the ecosystem is evolving.

From browserify to webpack, from grunt to gulp, from coffee-script to
typescript. It's never been so exciting.

~~~
beaconstudios
now all we need is a code-over-configuration replacement for webpack (like
gulp was for grunt) and the build system will have evolved from a mess of JSON
to a programmable compiler ecosystem. That's pretty cool.

~~~
chatmasta
You can write webpack “config” in JavaScript. It’s already programmable.

Not to mention every loader is programmed...

I’m really not sure what you’re getting at here.

~~~
beaconstudios
have you used gulp? It allows you to code up a processing pipeline in a pretty
intuitive way. Webpack, even though its config is written in JS, is basically
magic JSON files. Gulp offers near-total control over the build process which
also helps with optimising things like build speed.

~~~
chatmasta
Perhaps there is a reason webpack has surpassed gulp in terms of popularity.

Build systems have historically favored declarative configuration over
programmability. See Makefiles for an example.

I’m not saying that’s necessarily the right approach, but it does seem like
declarative configuration is a natural way to define a build system.

That said, I wholeheartedly agree there is much room for improvement with
webpack.

~~~
beaconstudios
I'd argue that Makefiles are a good argument in favour of programmability,
compared to something like Maven which is configurable. Gulp doesn't really
play in the same league as webpack as it's not really got the ecosystem, nor
is it optimised for, web builds. Declarative config definitely seems to be
winning out in terms of popularity but the more configurable you need your
build to be, the more the config ends up replicating a programming language
anyway - or you end up being locked into restrictive rulesets and patterns,
like webpack does.

~~~
alayek
This is an apple to orange comparison.

Gulp is a tool that lets you decide what the build process should look like.

Webpack is a tool where you define entry points, split points etc., and what
you finally need. Based on that webpack decides how to go about the build.

Most of what Gulp does, can be replaced with NPM scripts.

~~~
beaconstudios
it's the streaming/caching side of gulp that I find most useful to be honest.
When I have 3-4 build outputs being generated and I can offload intermediate
objects into a cache file and back it can lead to really fast builds. In
replacing grunt with gulp and setting up gulp correctly I've reduced builds
from 10-15 seconds to nearly instant before, and I think the main failing of
webpack is how slow a non-watch build can run, or how large its output size
can be. I think entrypoints and code splitting could be achieved with a gulp-
like system by picking files to be packaged into different builds.

It's also very easy to find build bottlenecks with gulp which is very handy if
you have a large project with a slow build. It allows you to scale out
efficiently.

~~~
chatmasta
Webpack hot reload server solves this problem and provides nearly instant
builds.

Yes, production (“non-watch”) builds can take a while. But who cares? You
shouldn’t be running a production build after every code change. That’s why
the hot reload server is so useful; it only recompiles the code you changed.

------
STRML
Not a lot of notable changes in here, but it's nice to see the v9 branch
moving quickly. The sheer velocity of NodeJS - even now after all the ES6
features & async/await are finally available without flags - is something to
behold.

Looking forward to v10 once the churn has settled.

------
ralmidani
My current tools of choice for server-side are Python 3 + Django + Django REST
Framework (DRF).

I want to really get into Node, but developing with it currently feels like
I'm Dr. Frankenstein hacking and stitching his monster together.

I realize Node developers tend to prefer small, focused libraries rather than
big, monolithic frameworks. But taken to an extreme, this results in a
codebase that has litle beauty, consistency, or symmetry.

Want to initialize an Express app? Don't use the new keyword. Want to declare
a Mongoose schema? You have to use the new keyword.

Express uses callbacks extensively, but for Mongoose I can configure promises
(oh, should I also install and import Bluebird or just use global promises?)

And really, why is body-parser installed separately from Express?

I'm not disparaging Node in order to elevate Python, Django, and DRF. I really
want to embrace Node and build fast, elegant, real-time, universal ES 2015+
Web apps. But as it stands now, exploring the Node ecosystem is exhausting and
frustrating.

Edit: if nobody builds a universal, consistent, ES 2015+ framework for Node, I
fully intend to do it myself.

~~~
kerryritter
I have the same complaints. I've found NestJS
([https://nestjs.com](https://nestjs.com)) to be a wonderful solution for a
lot of what you're talking about. There's a few recipes to get you up and
rolling with a real framework and also an ORM (TypeORM or Mongoose). Highly
recommend.

~~~
ralmidani
Thank you! Checking it out now. Looks very promising!

~~~
dvlsg
Loopback next is actually looking quite good, if you're in to typescript.

------
Wintamute
Have they sorted out npm 5 yet? Bundling a borked version of npm with Node 8
was a real misstep I think.

~~~
jarvelov
Most of my issues were solved with 5.3.0 as of 8e979bf80. [0]

>= 5.0 && < 5.3.0 were really messy and causing lots of problems for my
dependencies with peer dependencies. And on top of that there were the issues
with the lock file causing incomplete installs.

Since 5.3.0 it's been reliable for me. I've stopped using yarn altogether
after it just because it's yet another installation to manage. Although the
build times are much better still with yarn, but npm is making some progress
with every release.

[0]
[https://github.com/npm/npm/commit/8e979bf80fb93233f19db003f0...](https://github.com/npm/npm/commit/8e979bf80fb93233f19db003f08443e26cfc5e64)

~~~
Wintamute
I'm sticking with yarn for the time being I think. It feels years ahead of npm
at the moment. Speed and robustness/correctness are much better, but stuff
like `yarn upgrade-interactive` is also huge, also the workspaces feature.

------
Scarbutt
Serious question, why has nodejs become so ubiquitous in big companies
(netflix, linkedin, walmart, trello, uber, paypal, medium, ebay, groupon,
NASA) ?

Is it because is the most practical option? like, there are no fast runtimes
for dynamically-typed(for fast iteration) languages that also have big
ecosystems and is well sponsored?

Fast - rules out Python and Ruby.

Dynamic - rules out Java, Scala and Go?

Clojure - to awkward for most companies, small ecosystem but can call Java,
JS.

Lua - to niche.

If you need to write a backend(frontend?) for a SPA with SSR(or no SSR) or
WebApp why would chose something else besides nodejs (ignoring familiarity
with other lang and hating on JS)?

~~~
tejasmanohar

      Dynamically-typed(for fast iteration)
    

Such a popular mis-association. Once you get familiar with a good type system,
you _will_ be more productive. People are fooled by Java-- type inference cuts
over half the pain.

NodeJS rose to popularity because it was a gateway into non-PHP backends for
your typical frontend dev.

~~~
vog
"Dynamically-typed" often leads to "hard to refactor", which in turn slows
down your iterations at a certain (surprisingly low) amount of code. This may
still be less annoying than Java (especially before 1.8), but:

Have you ever refactored code in OCaml? (or SML, or Haskell, for that matter)
This is a breeze! It's mostly the ecosystem that drives me to Python and/or
JavaScript.

~~~
mbrock
Haskell with Aeson and Lens starts to approach convenience when dealing with
deep JSON structures, but it's still kind of messy and arcane compared to
JavaScript—in my opinion as a Haskell coder since 2004 who went to Chalmers,
studied advanced functional programming, learned Agda, and works with Haskell
full time.

After years of learning I'm quite proficient with Haskell, and of course I
recognize its enormous benefits, but I still totally understand the choice to
use Node rather than Haskell, just like I also understand the choice to use
bash for a lot of things!

I think Haskell is a transition language that will be replaced soon enough,
because its warts and deficiencies significantly hinder learning and adoption.

TypeScript is probably a way more pragmatic choice for most people who want
the majority of the benefits of a static type system.

~~~
vog
_> I think Haskell is a transition language that will be replaced soon enough_

What do you have in mind when you say that?

One of the existing contenders? (SML, OCaml, Rust, Elm)

Or something completely different?

~~~
hajile
SML 2.0 is the best candidate IMO.

Rust isn't a competitor as it's too close to metal and too verbose (great for
those kinds of things, but not for everything).

Elm has nice libraries (though not even all the the standardized web APIs are
supported yet). It also gets rid of Haskell's lazy evaluation, so reasoning is
easier. It doesn't have type classes though (and misses many advanced
features). The side effect question isn't great either IMO (I believe side
effects are necessary for real-world code).

SML would benefit from a little more syntax (borrow a couple good ideas from
Ocaml), but is very simple to learn and despite the simplicity, has an
amazingly powerful type system. While it could gain some benefit from type
classes, at least it isn't lazy, allows side effects, and is immutable by
default (but allows mutation if you need).

It doesn't have classes like Ocaml or F#, but I don't consider that to be a
loss. It has sane operator rules (and overloading which is important for
native-feeling APIs). SML is very fast (thank you mlton) and unlike Ocaml,
doesn't have to lose all its performance when you need 32 or 64-bit integers
for something. Unlike Ocaml, there are actually working multi-threading
implementations like poly-ml (mlton has an experimental one like Ocaml). It's
worth noting that because there is a standard, you don't have one
implementation/company that defines the spec.

The big flaws of SML are adoption, libraries, and the need for some extra
syntax (there is work on this that is ongoing). In the grand scheme of things,
it's in a very good position for a language that isn't that popular.

------
singularity2001
await keyword not usable in repl yet? [without (async _=>{x=await wtf()})()]

~~~
STRML
Bare `await` (REPL-only) came in Chrome 62 - and it's on the way to Node soon.
[https://github.com/nodejs/node/pull/15566](https://github.com/nodejs/node/pull/15566)

