Hacker News new | comments | show | ask | jobs | submit login
Node.js v9.2.0 (nodejs.org)
151 points by bricss 4 days ago | hide | past | web | 73 comments | favorite





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.


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.

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.


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.

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.


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.

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.


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.


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.


It sounds like what you want exists: it's gulp! If it's useful and makes sense to you, there's no reason to stop using it just because webpack is the hip new thing :)

webpack has fairly simple plugin interface you can write a plugin that will hook into anything you want you are basically implementing a single function apply(compiler).

I assume parent had "convention over configuration" in mind. https://en.wikipedia.org/wiki/Convention_over_configuration

not exactly, although my phrasing doesn't help that impression. I more meant that with webpack you're generating a config object which gets fed into the "webpack engine", where I'd rather have the power of numerous smaller plugins that I can glue together how I please.

It seems to tie into the debate around frameworks vs libraries, or the unix philosophy vs enterprise philosophy too, but that's a whole 'nother thing.


I forgot to mention that these days most of the projects that I see use a combination of webpack and npm scripts. I guess gulp will be obsolete in the next years.

I still think Grunt and Gulp have a place outside of npm scripts for build automation, deployment, and automation of one-off tasks. The fact that Gulp is fully concurrent by default makes IO and environment setup lightning fast. With Electron cross-platform builds especially it takes a lot of the headache out of trying to shim every possible platform configuration into a one-liner.

Broccoli (https://github.com/broccolijs/broccoli) has a really nice concept of "trees" that can be split or merged and composed together.

haven't you heard of browserify?

I have, but it's not what I'm talking about. See the comment above re. gulp.

What is your current toolchain in the node ecosystem?

Depends on the project, mostly a combination between

    - npm scripts ( mocha, nyc, tsc, etc... )
    - webpack
    - gulp

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.


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.


> Express uses callbacks extensively

This is true, Express goes way back to Node's pre-1.0 days before promises were a thing. For a more modern NodeJS experience, I'd recommend Koa http://koajs.com/. Rule number one for pain-free JS development: do everything with promises, if not async/await.

Koa is still "lightweight" in the sense that you piece together your middleware + request handler chain similar to Express (or Flask!) but it's just as capable once you've added what you need.


I have the same complaints. I've found NestJS (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.

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

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

If you want to build fast, elegant, real-time, consistent web apps for 2017 and onwards, take a look at Elixir and the Phoenix framework.

Elixir/Phoenix looks amazing. I actually flirted briefly with Rails, so looking at the docs for Phoenix, I sort of understood what was going on (even without having learned Elixir).

But doesn't using Phoenix still require JavaScript for the client-side? One of the benefits of Node is the potential for sharing code between client and server.


> sharing code between client and server

Never happens as much as you would think it might, except maybe for some very simple common utility functions. There is some benefit to consistent tooling (e.g. all you need is node+npm, then `npm i` and `npm run whatever`) for both client and server, but I have yet to find a project or framework that shares even the obvious stuff like domain model classes well.


It has not yet been done successfully, but that does not mean it cannot be done.

I have used Django and Ember together for a couple of projects, and having to define model classes twice is extremely wasteful in a large application. Not to mention having to use a third library for client-side validation (Ember does not do validations out-of-the-box), even though Django has most (if not all) the information needed for thorough validation sitting on the server.

In lieu of code-sharing, Django REST Framework does have schema generation support, but no major client-side framework supports it yet.


I hear you. Body parser is now bundled with express though so at least that is getting better.

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

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...


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.

5.4 has major regressions and was a hellish nightmare for me for a while. I'm stuck on 5.3 now, too. I can't believe such a major tool is so poorly tested.

They haven't unfortunately. npm 5.5.1 is still very broken, especially if you use postinstall scripts.

ahhahah

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)?


There's probably a pot of contributing factors, but I want to point out two, as an old-fashioned c/c++ turned Java developer who moved to node and typescript.

Typescript is fun. Java's type system is super unfun, with its interface-based approach to nominative typing. Of course, it has gotten better (I remember before generics, all the data structures had to have ridiculous cast statements to get stuff out). Type inference and structural are rad.

Also, the javascript runtime basically has cooperative parallelism, which makes concurrency way easier to reason about. I love this fact. I think golang is going to eventually beat out node (or node will make a seismic shift in a multithreaded direction) for just this reason. Goroutines are a really good parallelism story. I don't have as much fun in go (I admit, this is a personal and ineffable metric) but it does seem to perform really well in a web socket sort of situation.


  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.


"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.


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.


> 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?


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.


Okay, that's premature speculation because I don't have anything concrete in mind!

It's just a premonition I have of Haskell getting more complex while still tied to backwards compatibility and suddenly there's a new kid in town.

Maybe it will be something like Elixir is to Erlang or Reason to O'Caml, like, reusing the GHC runtime and GHC Core but with a new syntax and standard library.


If you intentionally code JS with referential transparency in mind, then this type of refactoring is just as esay, if not easier.

Would you mind to elaborate? How does "having referential transparency in mind" protect against typical refactoring errors, such as an unexpected "undefined" value due to a typo in a field name?

(Of course you could argue that you don't need OCaml for that, as TypeScript or Flow can prevent this, too. But then the argument of using "dynamic" JavaScript instead of static types is moot.)


I am gladly switching back from a 'good type system' for web development. Why? For fast development and interactions.

Native types like int/string/float/etc in Java/C# help little, but are a lot more write. With dynamically typed languages one doesn't have to babysit such redundant things, and often there is therefore no need to refactor function declarations, etc. And with a proper IDE refactoring works great and is as easy as with a stactically typed language.


Nodejs is incredibly fast to prototype in... Performs well under load and scales well.

The simple fact is you can try new ideas out quickly and very easily in Nodejs and then even take the raw prototype into production with a simple re-factor.


I highly doubt people programming in other languages make more on avg. than same level eng. in Netflix or Linkedin programming in JS/Node.

- Lightweight

- Portable

- Cross-platform

- “Fast enough” out-of-the-box

- Massive ecosystem

- No need for an application container

- Actively developed and maintained

- Supports procedural, object-oriented, and functional styles equally

- Non-proprietary programming language


Really hard to understate the "Massive ecosystem" aspect for Node.

It's the reason why Node was at the forefront for this new wave of client-centric graph query systems (GraphQL, Falcor) that is well on its path to displacing REST as the go-to model for client-server communication.


Cheaper developers, anyone doing webpages can be hired for doing server stuff and easily replaceable, the dream of most enterprise shops.

I see. Web pages are easy. Programming is hard, but we can fix that simply by putting programs in web pages. Then we take that same syntax out of the web page and put it elsewhere, so that all programming is easy.

I don't think it works that way.


I understand your point. I started out as an embedded systems C developer. There are actually huge parallels between embedded work and nodejs.

One of the reasons is you can forget about all that nasty race condition stuff you get with threading in most high level languages. There are also no pointers or direct memory manipulation. Nodejs is pretty much asynchronous by design.

I think it really is harder to “shoot yourself in the foot” than using the oldguard method of developing backend systems.

Maybe this partly explains why it is at least plausible.


Moot point tbf, Java developers are a dime a dozen too, it's something they learn in school. JS wasn't taught yet back in my day.

The JS ecosystem does seem a lot more approachable though, you can just click through an installer and run a copy / past example, instead of a custom Java installer, IDE, configuration, Maven, all that stuff.


It's nice to have people able to work on both backend and front-end. I think that's really the reason Node exists. Being able to fix anything within the stack makes you more agile than waiting for X team to do it for you. So it saves you time and possibly money as well(i.e expertise is easier to build). Now Node comes with all the JS issues so that's the tradeoff.

I think that the development speed was a huge factor, it was probably easier to get a good-enough node system up in 3 months than a similar system in java.

I don't know of any mainstream language where 3 months is too short to do something fairly large.

I do agree with your point, but I'd say "1 day" instead of 3 months. After enough time elapses, JS quirks and lack of typing become a net time loss, compared to (for example) C#.


Really any developer that really wants to work on the backend should be able to pick up another language.

End of the day it's just syntax, framework weirdness (js devs should be used to crazy language contortions), and data structures for ~80% of day to day work.

Node just made the transition easier.


According to google trends [1]. Golang seems more popular than nodejs.

1: https://trends.google.com/trends/explore?date=all&q=Node.js,...


Different search terms give different trends: https://trends.google.com/trends/explore?date=all&q=node%20j...

I only search for 'node' not 'node.js'


I asked this question to a CEO who pushed hard for nodejs. His answer was that the growth curve of the quantity of modules on npm was steep.

I'm not an expert but finding good javascript developers is easier than other languages. Since javascript has lot of hypes lately, people started to move javascript.

And, in my opinion nodejs is really good for quick & lightweight solutions.


Is it really? I thought that there were many more experienced java and c# devs and not that many with node experience.

IMHO, one of the biggest barriers right now for developers is getting "pigeonholed" in the hiring process by hiring managers and recruiters into thinking that programming skills in one language don't translate to others. The automated filtering of resumes/applications only makes the issue worse.

I think my reply to your comment would have to be something like:

  * it depends what type of project experience is required (desktop app, mobile app, web server, embedded device, etc)
  * it depends where the job is
  * it depends what sector you are talking about (governments tend to choose Microsoft languages more than startups)
  * it depends what age range of applicants is expected (I'd wager Java has is a decent bias towards older programmers who probably wouldn't get hired at most companies I've interviewed at)

How many new businesses are built around Java or C#?

People thought that frontend skills transfer to the backend if you only use the same language (And sadly they did).

Elixir?

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

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



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: