Node.js v9.2.0
nodejs.org
nodejs.org
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.
Not to mention every loader is programmed...
I’m really not sure what you’re getting at here.
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.
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 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.
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 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.
- npm scripts ( mocha, nyc, tsc, etc... )
- webpack
- gulpLooking forward to v10 once the churn has settled.
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.
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.
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.
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.
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.
>= 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...
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)?
And, in my opinion nodejs is really good for quick & lightweight solutions.
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)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#.
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.
1: https://trends.google.com/trends/explore?date=all&q=Node.js,...
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.
I don't think it works that way.
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.
Dynamically-typed(for fast iteration)
NodeJS rose to popularity because it was a gateway into non-PHP backends for your typical frontend dev.
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.
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.
What do you have in mind when you say that?
One of the existing contenders? (SML, OCaml, Rust, Elm)
Or something completely different?
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.
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.
(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.)
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.
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.
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.
- 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
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.