20 ms·

I finally escaped Node

shmooth 6y ago
I will never get tired of hate-javascript/callbacks posts. I keep hoping that someone will re-invent Javascript to have all the things we want, but those efforts seem to have stalled Like a muktithreaded engine Typescript had a shot Deno is...still alive apparently? ReasonML seems interesting but I don't know what it says about concurrency
watermelon0 6y ago
I agree with some points author is making, but overall I wouldn't put them either on Node.js runtime, or Node.js ecosystem. a) Erratic max latency IME Node.js performs well if you are not pushing its limits. If you have a service receiving 25k+ requests per second, you should better benchmark it, regardless of the language. Horizontal scaling should be configured based on the results of the benchmark. b) Cognitive overhead Yes, there is a bit of an additional overhead when mixing async and non async functions, but same goes for every other language that supports promises, C#, Python, Rust, Scala, etc. Typescript should fail if you try to access a property/method of a promise, without resolving it, so I'd say it's not such a big deal. Personally, I rarely work on Node.js, but when I do, I'm really grateful for await/async and typescript. You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. c) `pg` connect & query I would say the issue lies with how the library is implemented. I'd definitely expect `query` to fail if it's not connected to the database.
- dnautics 6y ago
  > Languages without strong typing, like Elixir. Have you ever actually worked with elixir? In practice the (strong) dynamic typing of elixir is not a problem. I have not written a type error that has made it to prod in tens of thousands of lines of code. The last type error I made only showed up extremely rarely (once a week or so) and it didn't matter because the supervisory tree restarted the process that threw it. Guess what? I didn't fix it. No one will die and $0 will be lost. There's very little ambiguity about falsely values and you can't arbitrarily coerce from one value to the next. That in and of itself cuts down on the type confusion, and also the fact that there are only about ten types. Even struct field names are compile-time checked for you, and I get little squiggly lines warning me about statically checked type errors in elixir-ls. Sure it's not perfect, but saying it's a cognitive burden is just... Silly.
  - marshmellman 6y ago
    How is refactoring? I was considering moving from Node to Elixir, but now that I’m using TypeScript it does feel like I would be giving something up. It’s a breeze to make broad changes knowing the compiler will prevent me from missing a code path, etc.
    - dnautics 6y ago
      Write your tests, gradually make red go to green. Super rewarding. Code coverage reports are a thing. You should be writing your tests async (including tests that leave the VM) in elixir, that will give you a chance to catch and raise asserts on race conditions which will stress ouct timings in your vm, etc. https://youtu.be/hvgdWQuriB4 https://youtu.be/hvgdWQuriB4
      - mcintyre1994 6y ago
        Thanks for sharing this, looks like a really useful series of videos :)
    - thdxr 6y ago
      Having spent a lot of time in both it's hard to argue it's as easy in Elixir. You can do it reasonably with a lot of tests but it's nowhere near the same experience as TS
    - argvargc 6y ago
      I'm only just starting with Elixir, but my impression so far is that I will be refactoring a lot less, due to the way Elixir encourages simple and elegant approaches to many of the common problems a programmer faces. In node for example, I'm refactoring constantly (or, at least, should be...) because I keep backing myself into cognitive and developmental corners by using a kind of brick-by-brick approach that is perhaps encouraged not only by the language but by the eco-system. I'm not finding this with Elixir, possibly because many of the more important architectural decisions have already been made for me at the language level, and apparently been made very well. The hurdle becomes more understanding how to best do something, rather than figuring out how to do something at all. A big part of this also may be Elixir's REPL. It has help for everything built-in. Whereas in node for example I find I'm constantly searching online and piecing together things from many different parts, in Elixir I almost never am, it's all just right there.
- hnedeotes 6y ago
  > You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. I see this mentioned many times, but when I do my impression (which might be wrong) is that you haven't written Elixir or Erlang for any thing more serious than tutorials or docs examples. Besides, elixir is technically (?) strongly typed - but not statically typed. Regarding async/await, compared to the things you get in the BEAM - that part specially is like comparing a stone wheel car moved by oxen with a space shuttle that has the same costs (or less), to launch and operate. It might sound snobbish, but sincerely I don't know what to say when I read that. Although not compile time, pattern matching allows you to define as strict, and in some cases, stricter conditions for functions than many typed languages, without any additional cognitive overhead or complex type definitions that you need a PhD to understand. def do_it(<<a::binary-size(2), ":", b::binary-size(4)>>), do: IO.puts("the argument is a binary string, of the form xx:xxxx") Even conditions where it depends on more than the types, like with complex types such as maps, structs, tuples, lists, where parts of those conform to a certain pattern, in any combination needed.
  - thdxr 6y ago
    I've been using Elixir for five years and I think it's sorely missing a better type system. I've done fine without it and have gotten entirely used to it but that doesn't mean things wouldn't be better with one. I only really started noticing as I started to build more complex Typescript systems how much it helps. My teammate shipped a bug in Elixir yesterday that would have been caught by a static type checker
    - hnedeotes 6y ago
      I know there's plenty of people working with Elixir (and Erlang) that feel that way. I can also imagine that in very large codebases dialyser might not be enough and it would be great to have it. Also that obviously, outside web and telecom there's definitively software which I wouldn't want written in them, but not in TS either, and probably it would have more tests than code, property and fuzzy and all the remaining things. I also won't say that it doesn't happen but I do believe if the same effort that goes into writing typed typescript and tests, aka, using dialyser and writing tests, that there shouldn't really be any difference? And when you include things like guards, explicit pattern matching, casting your data at the entry points of your system that it provides a much more robust experience? But that's all optional - what I've seen is that theoretically there's nothing you can't express with the base syntax (+ecto) that you could with most (as in the common ones) type systems, perhaps the difference is that since in a typed language it won't compile you are forced to do those things, define all enums, all their variants, exhaustively match, etc?
- martinald 6y ago
  (This may have changed since I used it in anger last). NodeJS does not handle multicore servers well, and I imagine many people don't realise this and have a huge amount of unused CPU capacity. You need to run multiple nodejs processes (one for each core really) to get the most of it. But this then requires load balancing even on a single machine, so a lot of people don't do it. There are other solutions but often require json strings passed between the workers, instead of objects, which can end up stalling the whole thing (more time spend with json (de)seralization than actually doing work on complex models). .NET (core) handles this extremely well. It's trivial to do a parallel async foreach, and it's easy to scope services (eg database access) to avoid threading problems. It also automatically uses as many cores as you have without any extra problems for handling multiple requests at once. This is even more of a problem on mobile apps in React Native, which I've used a lot of. It is virtually impossible to use multiple CPU cores efficently on a RN application, which is pretty crazy considering how many cores mobile phones have. For 99% of projects it's not a huge issue, but on some it becomes a real killer, especially as the workarounds involve sending json strings between processes, which can end up being the blocker itself with complex state you want to pass between threads.
  - hajile 6y ago
    Node has worker threads and shared memory buffers to share data between them.
    - martinald 6y ago
      Do you have a link to the shared memory buffers? I can't find much about them. I've found some stuff about worker threads but can only pass strings.
      - hajile 6y ago
        Here's one overview that's a pretty easy overview. https://dev.to/feezyhendrix/worker-threads-in-node-js-2ikh https://dev.to/feezyhendrix/worker-threads-in-node-js-2ikh You can read more about atomics and shared array buffers in JS on MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
benlumen 6y ago
I'm just getting in to Node, coming from only having used PHP and then Laravel. Is it a bad time? Using Sails.js for rapid prototyping.
- ClawsOnPaws 6y ago
  No. Node is very widely used, it does work, and of course: A thing nobody criticizes is a thing nobody uses. I think you should be fine.
  - Fellshard 6y ago
    Except the criticisms for Node are many and widely spread.
- mjgs 6y ago
  I think you’ll probably be fine with node too. Different people gel with different languages for all sorts of different reasons. I had done c++, java, bash, python, but it wasn’t until javascript, and specifically NodeJS that I really started enjoying programming. I would start out with a lighter web framework than sails if you are just starting out, especially if you are new to web programming. I initially started with sails too but found it was always getting in the way, making it difficult to figure out what was going on. Since it used express under the hood, I switched to Express and it was immediately 10x easier to build stuff. That was my experience. These days I would probably be totally fine using any framework, but I’ve been mostly happy sticking with express.
- nikon 6y ago
  What does Sails.js offer you over Laravel?
- kgin 6y ago
  No you’ll be fine. Huge amounts of the internet are built with node. I’ve learned the hard way, you never want to pick a more-obscure solution because it’s technically better. The size of the community is just as much a feature language syntax is.
sradman 6y ago
The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple server-side 12-Factor Apps: 1. No web Gateway Interface like WSGI and Rack, and 2. No DBMS API/SPI like JDBC. Express was supposed to be a Microframework like Sinatra and Flask but developers have to spend most of their time defining a robust web server. Since the http server and app code are tightly integrated, 12-Factor Apps or JSON API Microservices are more complicated than they need to be in Node. The lack of a JDBC-like API/SPI hurts many languages included Node and Rust. The GIL languages are not performant nor concurrent but they have good httpd/dbms interfaces. All the popular server-side language/runtimes are flawed along some fundamental dimension. Server-side REST shouldn’t be this complicated.
- deleted 6y ago
  [deleted]
- alexhutcheson 6y ago
  Why would a DBMS API need to be built into the runtime?
  - phpnode 6y ago
    Because otherwise you end up with thousands of incomplete and incompatible implementations all fighting to be the best or running out of steam after a month or two. Node is a hellscape from a db perspective
    - tekknik 6y ago
      Most people have moved on from ORMs and the like, since most DBs are not SQL anymore and supporting all of the different DB types is just too hard.
      - 6y ago
robin21 6y ago
> data structures Spending too much time upfront thinking about the perfect data structure is a bad idea. Long walks on the beach and fasting is not going to deliver your perfect data structure. People (other than yourself) using your product and observing evolving requirements over time will reveal an optimal data structure. Rapid iteration and real-world usage is the key. I can’t count the number of times I thought I had the perfect design only to implement it and not find it useful to myself - after having thought so long about it. > node Node is great. And it’s great at iterating quickly which should be the goal of any project. The post comes off very naive and a classic grass is always greener vibe. > And it sounds like the exact kind of algorithmic kludge a programmer would introduce if her underlying foundation had a few flaws. Why use a gendered pronoun here? It’s a bit unfair that the only non-specific gendered pronoun relates to a bad programming practice.
- throwaway53453 6y ago
  > Why use a gendered pronoun here? It’s a bit unfair that the only non-specific gendered pronoun relates to a bad programming practice. Spoiler alert, but making mistakes isn't just a male issue. Real representation means taking the bad with the good.
  - nashalo_nighly 6y ago
    I agree. Women also code, which means we also make mistakes. Equality means no mercy
- purerandomness 6y ago
  > Why use a gendered pronoun here? Alternating pronouns in the English language is a concept to emphasize the "randomness" of the gender. [1] [1] https://english.stackexchange.com/questions/279494/do-any-style-guides-advocate-the-alternating-use-of-he-and-she-as-a-gender-n https://english.stackexchange.com/questions/279494/do-any-st...
amelius 6y ago
TL;DR: async programming does not work well from the commandline.
- yoz-y 6y ago
  Yeah, that's also my takeaway. I've also ran into this when debugging stuff inside the Dev Tools console, but it's not really an issue when writing code.
- SummerlyMars 6y ago
  As of Node 14.8, you can use await at the top level. In previous versions (not sure for how long), it was hidden behind a flag. https://nodejs.org/en/blog/release/v14.8.0/ https://nodejs.org/en/blog/release/v14.8.0/
- jtdev 6y ago
  And node.js approach to concurrency is a mountain of accumulated error.
cygned 6y ago
We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's economically impossible to vet and review dependencies - There's a tendency in the ecosystem to abandon projects rather soon (~1-2 years) and to keep changing things. Further, we have had several situations where maintainers did not respect semver, combined with npm's approach of updating patch versions upon installation, we have had too many broken builds from one day to another w/out code changes. The state of documentation of a lot of projects is non-existent. - Lack of multi threading. We have used all the options, including RPC implementations, but that doesn't even come close to approaches like Java threads or go routines. Neither in performance, nor in maintainability. - Lack of typing. That's probably the biggest one. Yes, we use TypeScript, quite extensively even. But TypeScript brings its own problems. First, it's only declarative. If you have a `something: number`, there's no guarantee that it's actually a number upon execution, so if you have a bug in a layer interacting with another system, that might fail a couple levels deep. You hence end up with type checks at some places and you cannot really trust it anyway. Second, TypeScript's tooling is slow and has some annoying quirks (e.g. aliases not being resolved upon compilation). Having aliases allowing to shorten import paths is a big, big win, though. Third, the typing, given the complexity of JavaScript, can be confusing, sometimes even seemingly impossible to get right. Is node a bad technology? Not at all. I'd not chose it for enterprise, big or long-lived projects, though. It's a very good technology for a lot of things, especially smaller projects. We are building on Java + Spring Boot now.
- haolez 6y ago
  How do you feel about the impact on developer productivity after migrating to Java + Spring Boot? I haven't used Java in a long while and every time that I try to come back to it, I get driven away by the difficulty and complexity to do simple things (thinking of annotations, dependency injection, complicated design patterns). It feels like an effort of one hour of Node or Python programming (or even Go) would take 10x more in Java.
rockyj 6y ago
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). On top, any organization can hire JS devs with relative ease. And the same devs can also use the same skills to build a frontend. I am not a JS/TS/Node fan but unfortunately it seems we do not have a better story to sell right now and we are stuck here for a while.
- xwdv 6y ago
  How about Go?
  - rockyj 6y ago
    Yes, pretty good alternative. But you will still need to hire "frontend" devs who can code in JS/TS. Go will perhaps have a more performant backend. So plus one and minus one. Also, not sure how easy / hard it is to hire experienced Go developers.
- stefan_ 6y ago
  Uhm, CGI? Those are not at all impressive metrics.
- papaf 6y ago
  Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). Its probably a rhetorical question, but I would suggest Go as another alternative. Naturally, you wouldn't want to write the frontend in Go and it also has the "not perfect" quality.
- mtberatwork 6y ago
talkingtab 6y ago
from the article "JavaScript is evolution". Exactly. At any moment there may be some alternative that is better in some ways, but unless it also evolves it is not a long run contender. I don't love JavaScript, it can be a huge and gigantic pain (this, ==, null, undefined etc). But it continues to get better and is still for me the most productive language I have used.
- wtetzner 6y ago
  What alternatives are you thinking of that aren't evolving or improving?
iaml 6y ago
>And if only life were so simple: Life is pretty simple, just add --experimental-repl-await: > await Promise.resolve(42) 42
jkhdigital 6y ago
Funny story— Along with a friend who has at least a decade more development experience, I have been building a cryptocurrency trade execution platform. He started it in Node, and I picked up where he left off not even knowing what a Promise was. Fast forward a year, and after taking a distributed systems course that required me to use Elixir for all the projects I demanded that we abandon Node for Elixir.
- 3saryHg6LP2e 6y ago
  >I have been building a cryptocurrency trade execution platform. He started it in Node, and I picked up where he left off not even knowing what a Promise was. Sounds secure
  - jkhdigital 6y ago
    Security = don’t leak the API secret. It’s not that hard.
    - 3saryHg6LP2e 6y ago
      oh dear
- myth_drannon 6y ago
  which course it that?
benjaminjosephw 6y ago
> What you end up with is a paradigm for concurrency that a human can easily map to and reason about. I always feel like I'm thinking about concurrency at the right layer of the stack. Interesting. Is this a common view in the Elixir community? It's a hard problem to find a good abstraction for and I think it's only really possible to know if it holds up as a good abstraction after a fair bit of use. Can anyone corroborate this perspective? Is there something helpful about the module layer specifically?
- fredrikholm 6y ago
  Yes. When I open a module I haven't seen before, and the first line that I read is: use GenServer I immediately know how this module behaves in terms of (distributed) concurrency. If I can find where this module is started, I also know how it handles when things go wrong (via supervision trees). GenServer supports three ways of communicating: * call -> handle_call (sync) * cast -> handle_cast (async) * send -> handle_info (async system messages, signals etc) Here's an example: def send_greeting(pid, greeting, from) do GenServer.call(pid, {:receive_greeting, greeting, from}) end def handle_call({:receive_greeting, greeting, name}, sender, current_state) do IO.puts greeting {:reply, "Hello #{name}!", current_state} end ------------------------ {:ok, mikes_computer} = Greeter.start_link(:mike) response = Greeter.send_greeting(mikes_computer, "Hello Mike!", "Joe") IO.puts response > "Hello Joe!" There's more ways to implement concurrency than by GenServers, but it's the combination of GenServers and Supervisors that sets the BEAM and OTP a head above everything else (in this very specific domain of soft realtime distributed servers).
Jeema101 6y ago
I'm not a node.js programmer by trade, so maybe I have this all wrong, but I thought the main selling point of the language was that it is fast. The thing is, everything in computer science comes with a tradeoff: the tradeoff in this case seems to be that, in gaining speed, now you are sacrificing a layer of abstraction that would normally be hidden by the operating system. What I mean by that is that instead of just letting the operating system handle putting a thread to sleep when it blocks, and then waking it back up when it's ready (for example during a database query), now you have to start explicitly handling that blocking yourself in the form of callbacks. It seems like the author is realizing that maybe that is not really ideal.
- 7Uzyd7H80egR 6y ago
  Yeah, I think that's not quite right. I think the main selling point of Node has always been that it's Javascript and thus you can use the same language, and people, to do both frontend and backend development. Node is not fast and it's not trying to compete with compiled language in that regard.
  - blandflakes 6y ago
    FWIW I have _heard_ the pitch that node.js is fast, here on HN and elsewhere, but most times it's fast compared to like... Ruby. Which is fine, but that's not the only competition in town for node.js.
holografix 6y ago
Right now I’m trying to unit test an API on node that does a database query. I’m using express, mocha, supertest and typeorm. Mocking the database is fucking black magic. So I gave up and simply use an in memory SQLite db and add some records in the test body for my API to fetch and return so I can test. I’d like the db to basically get nuked and recreated after every test. So I use “afterEach” to close the connection and create a new one. No matter what I do, when I call the api endpoint using supertest it tells me my DB connection is closed. You’re thinking maybe the previous test didn’t reopen it or something. But there only one test. It’s like it’s closing it _before_ the test runs. As if afterEach is not waiting on the result from supertest (yes I awaited). I spent a _whole day_ today trying to understand just what the fuck is going on. Gimme goroutines _any day_.
- akoutmos 6y ago
  Testing with the database has to be one of the things I love the most about Ecto. No need to mock anything, no need to have special branching logic for test versus prod. Just use the database like you normally do. It gives you a degree of confidence that is on another level. Check out https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html for more info!
  - striking 6y ago
    Testing with the database isn't particularly efficient. If you have enough tests, it becomes worth it to mock whatever would touch the database just so the tests pass in a reasonable amount of time.
    - napsterbr 6y ago
      > Testing with the database isn't particularly efficient. Anecdata, but my experience with Ecto sandbox + thousands of tests says otherwise. Mocking would be faster? Probably. But IMO not worth the effort, given it's already fast enough. To be fair, I have worked with Elixir codebases that generated humongous amount of data per-test, only to test a fraction of this data. This kind of test was slow, but it would be much more efficient to generate only the data you actually need.
christiansakai 6y ago
The issues described here is so overblown and mostly non issue/nitpicking. But I'm not gonna write counter-points here, plenty of those already online. Some of the commenters here will also write it.
egeozcan 6y ago
Javascript these days is a very productive language, especially with Typescript. Node however, with its lack of a remotely passable standard library, is not doing it justice. The async await is amazing and top level await works just fine in a browser console. The fact that node still has it behind a flag is... I mean, they surely have their reasons and I don't know enough to question the decisions of the maintainers, but it feels detached from modern times when using. Node is not web, don't know why they hesitate so much before remotely breaking things. I'm not advocating for moving fast and breaking things, remind you, I'm just saying that the io.js kick maybe needs to happen again.
- nickthemagicman 6y ago
  I think the author's argument wasn't that JS was a 'productive' language but that it was an overall poorly designed and bad language.
  - egeozcan 6y ago
    So my argument is that a significant portion of the poorly designed part comes from node. It's also not a bad language. It's okay for its main purpose: Creating web applications. If people start using it to write distributed systems, async/await won't save you from any troubles you might have. Next.js is a perfect example for what JS is good for. However, the super lacking standard library frustrates me to no end.
    - nickthemagicman 6y ago
      It's not bad. Would I rather use anything else if possible? Yes.
debrice 6y ago
It’s really hard to read such posts. The tool is only as good as the contributor, that’s all there is. Great things were built in all languages and frameworks. For god sakes, stop blaming the tool by doing naive comparisons with other languages/framework. Nothing’s perfect, that’s a given, but these kinds of post smells so much like entitlement. You don’t need to trash your previous framework/language and discourage others. If you struggled using node don’t fool yourself that it was because of the tool and try to do the hard work of introspection and understand why you failed. Disclaimer: In case you think I’m bias toward node, I’m more of a python fast API guy, but I have tremendous respect toward NodeJS performance and async elegance (and even more when mixed with typescript)
- harryf 6y ago
  I get where you're coming from - the post meanders around some topics every programmer has to learn by hard experience, such as the value of being able to reason about code / systems and the importance of data structures. That said my feeling is Node gives you multiple pump action shotguns you can easily shoot yourself in the foot with. For example https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ > One common way to block the Event Loop disastrously is by using a "vulnerable" regular expression. If you're leading an engineering team, just this should be giving you panic attacks every time you hire someone new into the team. What makes this worse is it's very hard to detect problems at scale, if you missed it in code reviews. If you have one "vulnerable regex" in your event loop that only exposes itself on certain request inputs, it means that only every now and again - when given "bad input" - it's going to block the event loop. But then how to you detect issue? It's likely going to manifest itself first in _other_ requests that got blocked taking an excessively long time to respond. From an operational point of view, that's a nightmare scenario. Every now and again you're going to see slow requests in your logs but when you dig into it you find no problems. And that's going to make you very uncertain on how you're doing when it comes to scaling up; instead of a gradual slow down across all requests, you're going to see erratic spikes and jams. ...which actually occurs to me it's not unlike how traffic jams occur - https://www.youtube.com/watch?v=azmcu1cn2vg https://www.youtube.com/watch?v=azmcu1cn2vg - https://traffic-simulation.de/ https://traffic-simulation.de/
conradfr 6y ago
I'm still astonished that someone was writing Javascript on the browser and found the experience so great that he thought "I also want to do it on the backend!". More seriously, I'll admit I'm not a competent Node dev but the worst part for me is how convoluted you have to write large parts of code that don't need to be asynchronous or non-blocking in the first place. I also never figured why sometimes Node just silently ends without pointing my syntax error (and more importantly the line number). Like the author, in my mind Elixir is a better Node (Go never clicked for me). Some weeks ago I had to write a feature that was so perfect for Phoenix Channels, Presence etc that it was almost magical and quite fun. Nothing groundbreaking but I wrote about it here https://conradfr.github.io/ProgRadio/ https://conradfr.github.io/ProgRadio/
- MangoCoffee 6y ago
  >I'm still astonished that someone was writing Javascript on the browser and found the experience so great that he thought "I also want to do it on the backend!". I'm currently playing and learning Microsoft Blazor server side. i like the appeal of writing the whole app that feel like a Single Page Application in one language. whether that's good or bad is another matter.
- DrFell 6y ago
  Most Node devs are JavaScript monoglots, who just recently learned frontend, and figure "Let's use JavaScript for everything!"
- LargeWu 6y ago
  "More seriously, I'll admit I'm not a competent Node dev but the worst part for me is how convoluted you have to write large parts of code that don't need to be asynchronous or non-blocking in the first place. I also never figured why sometimes Node just silently ends without pointing my syntax error (and more importantly the line number)." This, so much. Even for moderately complex data workflows, 95% of the time what I needed to do was "execute a query or other IO operation, then do something with the result of that operation." But since js is async by default, I have to do extra work every time. Even if it's just a simple async/await declaration, there can be complications. Oh, your query failed with an exception so you want to do a rollback? Sorry, you lost scope to that db query when your promise was rejected. And don't even get me started on the stack traces, or lack thereof. If an exception was thrown inside a promise there's a 75% chance you're not getting anything useful out of that.
progx 6y ago
In some years: I escaped Elixir. Use the right tool to get the sht done.
- joelbluminator 6y ago
  So true. People pick new stacks all the time and then complain when after 10 years it's boring and there's shinier or more suitable tools out there. Now Node wouldn't be my first choice but I'm sure it's good enough for most purposes, easy to find people to hire etc. There's absolutely no reason to do a rewrite to java imo. I don't buy the "because types" argument.
justsomeuser 6y ago
The thing I dislike about message passing vs async/await is that it makes it easy to understand each individual process (that send and receive messages), but harder to understand the whole system. Assuming your CPU load fits on a single thread, a single threaded event loop with async/await seems easier to understand the whole system because: - Using functions to compose computations keeps the connection between functions at both write time in your IDE (jump to def), and production time with stack traces. - With message passing systems, you only get the stack trace from when you received the message. - Having a single thread means you are not sharing memory between threads. - You can combine results using Promise combinators, which form an await tree.
ipsocannibal 6y ago
The author took way too many words to say message passing between processes is a more grokable form of concurrency than callbacks. Then goes on to say that Node is less grokable than Erlang because concurrency in Node heavily relies upon async/await which is just pretty callbacks. There are some weak analogies to the importance of data structures mixed in to the text which aren't helpful. I think BOTH models of concurrency have their uses. The only problem I see is not being able to apply the appropriate one at the appropriate time because the language doesn't support it.

I will never get tired of hate-javascript/callbacks posts. I keep hoping that someone will re-invent Javascript to have all the things we want, but those efforts seem to have stalled Like a muktithreaded engine Typescript had a shot Deno is...still alive apparently? ReasonML seems interesting but I don't know what it says about concurrency

watermelon0 6y ago

I agree with some points author is making, but overall I wouldn't put them either on Node.js runtime, or Node.js ecosystem. a) Erratic max latency IME Node.js performs well if you are not pushing its limits. If you have a service receiving 25k+ requests per second, you should better benchmark it, regardless of the language. Horizontal scaling should be configured based on the results of the benchmark. b) Cognitive overhead Yes, there is a bit of an additional overhead when mixing async and non async functions, but same goes for every other language that supports promises, C#, Python, Rust, Scala, etc. Typescript should fail if you try to access a property/method of a promise, without resolving it, so I'd say it's not such a big deal. Personally, I rarely work on Node.js, but when I do, I'm really grateful for await/async and typescript. You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. c) `pg` connect & query I would say the issue lies with how the library is implemented. I'd definitely expect `query` to fail if it's not connected to the database.

dnautics 6y ago
> Languages without strong typing, like Elixir. Have you ever actually worked with elixir? In practice the (strong) dynamic typing of elixir is not a problem. I have not written a type error that has made it to prod in tens of thousands of lines of code. The last type error I made only showed up extremely rarely (once a week or so) and it didn't matter because the supervisory tree restarted the process that threw it. Guess what? I didn't fix it. No one will die and $0 will be lost. There's very little ambiguity about falsely values and you can't arbitrarily coerce from one value to the next. That in and of itself cuts down on the type confusion, and also the fact that there are only about ten types. Even struct field names are compile-time checked for you, and I get little squiggly lines warning me about statically checked type errors in elixir-ls. Sure it's not perfect, but saying it's a cognitive burden is just... Silly.
- marshmellman 6y ago
  How is refactoring? I was considering moving from Node to Elixir, but now that I’m using TypeScript it does feel like I would be giving something up. It’s a breeze to make broad changes knowing the compiler will prevent me from missing a code path, etc.
  - dnautics 6y ago
    Write your tests, gradually make red go to green. Super rewarding. Code coverage reports are a thing. You should be writing your tests async (including tests that leave the VM) in elixir, that will give you a chance to catch and raise asserts on race conditions which will stress ouct timings in your vm, etc. https://youtu.be/hvgdWQuriB4 https://youtu.be/hvgdWQuriB4
    - mcintyre1994 6y ago
      Thanks for sharing this, looks like a really useful series of videos :)
  - thdxr 6y ago
    Having spent a lot of time in both it's hard to argue it's as easy in Elixir. You can do it reasonably with a lot of tests but it's nowhere near the same experience as TS
  - argvargc 6y ago
    I'm only just starting with Elixir, but my impression so far is that I will be refactoring a lot less, due to the way Elixir encourages simple and elegant approaches to many of the common problems a programmer faces. In node for example, I'm refactoring constantly (or, at least, should be...) because I keep backing myself into cognitive and developmental corners by using a kind of brick-by-brick approach that is perhaps encouraged not only by the language but by the eco-system. I'm not finding this with Elixir, possibly because many of the more important architectural decisions have already been made for me at the language level, and apparently been made very well. The hurdle becomes more understanding how to best do something, rather than figuring out how to do something at all. A big part of this also may be Elixir's REPL. It has help for everything built-in. Whereas in node for example I find I'm constantly searching online and piecing together things from many different parts, in Elixir I almost never am, it's all just right there.
hnedeotes 6y ago
> You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. I see this mentioned many times, but when I do my impression (which might be wrong) is that you haven't written Elixir or Erlang for any thing more serious than tutorials or docs examples. Besides, elixir is technically (?) strongly typed - but not statically typed. Regarding async/await, compared to the things you get in the BEAM - that part specially is like comparing a stone wheel car moved by oxen with a space shuttle that has the same costs (or less), to launch and operate. It might sound snobbish, but sincerely I don't know what to say when I read that. Although not compile time, pattern matching allows you to define as strict, and in some cases, stricter conditions for functions than many typed languages, without any additional cognitive overhead or complex type definitions that you need a PhD to understand. def do_it(<<a::binary-size(2), ":", b::binary-size(4)>>), do: IO.puts("the argument is a binary string, of the form xx:xxxx") Even conditions where it depends on more than the types, like with complex types such as maps, structs, tuples, lists, where parts of those conform to a certain pattern, in any combination needed.
- thdxr 6y ago
  I've been using Elixir for five years and I think it's sorely missing a better type system. I've done fine without it and have gotten entirely used to it but that doesn't mean things wouldn't be better with one. I only really started noticing as I started to build more complex Typescript systems how much it helps. My teammate shipped a bug in Elixir yesterday that would have been caught by a static type checker
  - hnedeotes 6y ago
    I know there's plenty of people working with Elixir (and Erlang) that feel that way. I can also imagine that in very large codebases dialyser might not be enough and it would be great to have it. Also that obviously, outside web and telecom there's definitively software which I wouldn't want written in them, but not in TS either, and probably it would have more tests than code, property and fuzzy and all the remaining things. I also won't say that it doesn't happen but I do believe if the same effort that goes into writing typed typescript and tests, aka, using dialyser and writing tests, that there shouldn't really be any difference? And when you include things like guards, explicit pattern matching, casting your data at the entry points of your system that it provides a much more robust experience? But that's all optional - what I've seen is that theoretically there's nothing you can't express with the base syntax (+ecto) that you could with most (as in the common ones) type systems, perhaps the difference is that since in a typed language it won't compile you are forced to do those things, define all enums, all their variants, exhaustively match, etc?
martinald 6y ago
(This may have changed since I used it in anger last). NodeJS does not handle multicore servers well, and I imagine many people don't realise this and have a huge amount of unused CPU capacity. You need to run multiple nodejs processes (one for each core really) to get the most of it. But this then requires load balancing even on a single machine, so a lot of people don't do it. There are other solutions but often require json strings passed between the workers, instead of objects, which can end up stalling the whole thing (more time spend with json (de)seralization than actually doing work on complex models). .NET (core) handles this extremely well. It's trivial to do a parallel async foreach, and it's easy to scope services (eg database access) to avoid threading problems. It also automatically uses as many cores as you have without any extra problems for handling multiple requests at once. This is even more of a problem on mobile apps in React Native, which I've used a lot of. It is virtually impossible to use multiple CPU cores efficently on a RN application, which is pretty crazy considering how many cores mobile phones have. For 99% of projects it's not a huge issue, but on some it becomes a real killer, especially as the workarounds involve sending json strings between processes, which can end up being the blocker itself with complex state you want to pass between threads.
- hajile 6y ago
  Node has worker threads and shared memory buffers to share data between them.
  - martinald 6y ago
    Do you have a link to the shared memory buffers? I can't find much about them. I've found some stuff about worker threads but can only pass strings.
    - hajile 6y ago
      Here's one overview that's a pretty easy overview. https://dev.to/feezyhendrix/worker-threads-in-node-js-2ikh https://dev.to/feezyhendrix/worker-threads-in-node-js-2ikh You can read more about atomics and shared array buffers in JS on MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

benlumen 6y ago

I'm just getting in to Node, coming from only having used PHP and then Laravel. Is it a bad time? Using Sails.js for rapid prototyping.

ClawsOnPaws 6y ago
No. Node is very widely used, it does work, and of course: A thing nobody criticizes is a thing nobody uses. I think you should be fine.
- Fellshard 6y ago
  Except the criticisms for Node are many and widely spread.
mjgs 6y ago
I think you’ll probably be fine with node too. Different people gel with different languages for all sorts of different reasons. I had done c++, java, bash, python, but it wasn’t until javascript, and specifically NodeJS that I really started enjoying programming. I would start out with a lighter web framework than sails if you are just starting out, especially if you are new to web programming. I initially started with sails too but found it was always getting in the way, making it difficult to figure out what was going on. Since it used express under the hood, I switched to Express and it was immediately 10x easier to build stuff. That was my experience. These days I would probably be totally fine using any framework, but I’ve been mostly happy sticking with express.
nikon 6y ago
What does Sails.js offer you over Laravel?
kgin 6y ago
No you’ll be fine. Huge amounts of the internet are built with node. I’ve learned the hard way, you never want to pick a more-obscure solution because it’s technically better. The size of the community is just as much a feature language syntax is.

sradman 6y ago

The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple server-side 12-Factor Apps: 1. No web Gateway Interface like WSGI and Rack, and 2. No DBMS API/SPI like JDBC. Express was supposed to be a Microframework like Sinatra and Flask but developers have to spend most of their time defining a robust web server. Since the http server and app code are tightly integrated, 12-Factor Apps or JSON API Microservices are more complicated than they need to be in Node. The lack of a JDBC-like API/SPI hurts many languages included Node and Rust. The GIL languages are not performant nor concurrent but they have good httpd/dbms interfaces. All the popular server-side language/runtimes are flawed along some fundamental dimension. Server-side REST shouldn’t be this complicated.

deleted 6y ago
[deleted]
alexhutcheson 6y ago
Why would a DBMS API need to be built into the runtime?
- phpnode 6y ago
  Because otherwise you end up with thousands of incomplete and incompatible implementations all fighting to be the best or running out of steam after a month or two. Node is a hellscape from a db perspective
  - tekknik 6y ago
    Most people have moved on from ORMs and the like, since most DBs are not SQL anymore and supporting all of the different DB types is just too hard.
    - 6y ago

robin21 6y ago

> data structures Spending too much time upfront thinking about the perfect data structure is a bad idea. Long walks on the beach and fasting is not going to deliver your perfect data structure. People (other than yourself) using your product and observing evolving requirements over time will reveal an optimal data structure. Rapid iteration and real-world usage is the key. I can’t count the number of times I thought I had the perfect design only to implement it and not find it useful to myself - after having thought so long about it. > node Node is great. And it’s great at iterating quickly which should be the goal of any project. The post comes off very naive and a classic grass is always greener vibe. > And it sounds like the exact kind of algorithmic kludge a programmer would introduce if her underlying foundation had a few flaws. Why use a gendered pronoun here? It’s a bit unfair that the only non-specific gendered pronoun relates to a bad programming practice.

throwaway53453 6y ago
> Why use a gendered pronoun here? It’s a bit unfair that the only non-specific gendered pronoun relates to a bad programming practice. Spoiler alert, but making mistakes isn't just a male issue. Real representation means taking the bad with the good.
- nashalo_nighly 6y ago
  I agree. Women also code, which means we also make mistakes. Equality means no mercy
purerandomness 6y ago
> Why use a gendered pronoun here? Alternating pronouns in the English language is a concept to emphasize the "randomness" of the gender. [1] [1] https://english.stackexchange.com/questions/279494/do-any-style-guides-advocate-the-alternating-use-of-he-and-she-as-a-gender-n https://english.stackexchange.com/questions/279494/do-any-st...

amelius 6y ago

TL;DR: async programming does not work well from the commandline.

yoz-y 6y ago
Yeah, that's also my takeaway. I've also ran into this when debugging stuff inside the Dev Tools console, but it's not really an issue when writing code.
SummerlyMars 6y ago
As of Node 14.8, you can use await at the top level. In previous versions (not sure for how long), it was hidden behind a flag. https://nodejs.org/en/blog/release/v14.8.0/ https://nodejs.org/en/blog/release/v14.8.0/
jtdev 6y ago
And node.js approach to concurrency is a mountain of accumulated error.

cygned 6y ago

We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's economically impossible to vet and review dependencies - There's a tendency in the ecosystem to abandon projects rather soon (~1-2 years) and to keep changing things. Further, we have had several situations where maintainers did not respect semver, combined with npm's approach of updating patch versions upon installation, we have had too many broken builds from one day to another w/out code changes. The state of documentation of a lot of projects is non-existent. - Lack of multi threading. We have used all the options, including RPC implementations, but that doesn't even come close to approaches like Java threads or go routines. Neither in performance, nor in maintainability. - Lack of typing. That's probably the biggest one. Yes, we use TypeScript, quite extensively even. But TypeScript brings its own problems. First, it's only declarative. If you have a `something: number`, there's no guarantee that it's actually a number upon execution, so if you have a bug in a layer interacting with another system, that might fail a couple levels deep. You hence end up with type checks at some places and you cannot really trust it anyway. Second, TypeScript's tooling is slow and has some annoying quirks (e.g. aliases not being resolved upon compilation). Having aliases allowing to shorten import paths is a big, big win, though. Third, the typing, given the complexity of JavaScript, can be confusing, sometimes even seemingly impossible to get right. Is node a bad technology? Not at all. I'd not chose it for enterprise, big or long-lived projects, though. It's a very good technology for a lot of things, especially smaller projects. We are building on Java + Spring Boot now.

haolez 6y ago
How do you feel about the impact on developer productivity after migrating to Java + Spring Boot? I haven't used Java in a long while and every time that I try to come back to it, I get driven away by the difficulty and complexity to do simple things (thinking of annotations, dependency injection, complicated design patterns). It feels like an effort of one hour of Node or Python programming (or even Go) would take 10x more in Java.

rockyj 6y ago

From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). On top, any organization can hire JS devs with relative ease. And the same devs can also use the same skills to build a frontend. I am not a JS/TS/Node fan but unfortunately it seems we do not have a better story to sell right now and we are stuck here for a while.

xwdv 6y ago
How about Go?
- rockyj 6y ago
  Yes, pretty good alternative. But you will still need to hire "frontend" devs who can code in JS/TS. Go will perhaps have a more performant backend. So plus one and minus one. Also, not sure how easy / hard it is to hire experienced Go developers.
stefan_ 6y ago
Uhm, CGI? Those are not at all impressive metrics.
papaf 6y ago
Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). Its probably a rhetorical question, but I would suggest Go as another alternative. Naturally, you wouldn't want to write the frontend in Go and it also has the "not perfect" quality.
mtberatwork 6y ago

talkingtab 6y ago

from the article "JavaScript is evolution". Exactly. At any moment there may be some alternative that is better in some ways, but unless it also evolves it is not a long run contender. I don't love JavaScript, it can be a huge and gigantic pain (this, ==, null, undefined etc). But it continues to get better and is still for me the most productive language I have used.

wtetzner 6y ago
What alternatives are you thinking of that aren't evolving or improving?

iaml 6y ago

>And if only life were so simple: Life is pretty simple, just add --experimental-repl-await: > await Promise.resolve(42) 42

jkhdigital 6y ago

Funny story— Along with a friend who has at least a decade more development experience, I have been building a cryptocurrency trade execution platform. He started it in Node, and I picked up where he left off not even knowing what a Promise was. Fast forward a year, and after taking a distributed systems course that required me to use Elixir for all the projects I demanded that we abandon Node for Elixir.

3saryHg6LP2e 6y ago
>I have been building a cryptocurrency trade execution platform. He started it in Node, and I picked up where he left off not even knowing what a Promise was. Sounds secure
- jkhdigital 6y ago
  Security = don’t leak the API secret. It’s not that hard.
  - 3saryHg6LP2e 6y ago
    oh dear
myth_drannon 6y ago
which course it that?

benjaminjosephw 6y ago

> What you end up with is a paradigm for concurrency that a human can easily map to and reason about. I always feel like I'm thinking about concurrency at the right layer of the stack. Interesting. Is this a common view in the Elixir community? It's a hard problem to find a good abstraction for and I think it's only really possible to know if it holds up as a good abstraction after a fair bit of use. Can anyone corroborate this perspective? Is there something helpful about the module layer specifically?

fredrikholm 6y ago
Yes. When I open a module I haven't seen before, and the first line that I read is: use GenServer I immediately know how this module behaves in terms of (distributed) concurrency. If I can find where this module is started, I also know how it handles when things go wrong (via supervision trees). GenServer supports three ways of communicating: * call -> handle_call (sync) * cast -> handle_cast (async) * send -> handle_info (async system messages, signals etc) Here's an example: def send_greeting(pid, greeting, from) do GenServer.call(pid, {:receive_greeting, greeting, from}) end def handle_call({:receive_greeting, greeting, name}, sender, current_state) do IO.puts greeting {:reply, "Hello #{name}!", current_state} end ------------------------ {:ok, mikes_computer} = Greeter.start_link(:mike) response = Greeter.send_greeting(mikes_computer, "Hello Mike!", "Joe") IO.puts response > "Hello Joe!" There's more ways to implement concurrency than by GenServers, but it's the combination of GenServers and Supervisors that sets the BEAM and OTP a head above everything else (in this very specific domain of soft realtime distributed servers).

Jeema101 6y ago

I'm not a node.js programmer by trade, so maybe I have this all wrong, but I thought the main selling point of the language was that it is fast. The thing is, everything in computer science comes with a tradeoff: the tradeoff in this case seems to be that, in gaining speed, now you are sacrificing a layer of abstraction that would normally be hidden by the operating system. What I mean by that is that instead of just letting the operating system handle putting a thread to sleep when it blocks, and then waking it back up when it's ready (for example during a database query), now you have to start explicitly handling that blocking yourself in the form of callbacks. It seems like the author is realizing that maybe that is not really ideal.

7Uzyd7H80egR 6y ago
Yeah, I think that's not quite right. I think the main selling point of Node has always been that it's Javascript and thus you can use the same language, and people, to do both frontend and backend development. Node is not fast and it's not trying to compete with compiled language in that regard.
- blandflakes 6y ago
  FWIW I have _heard_ the pitch that node.js is fast, here on HN and elsewhere, but most times it's fast compared to like... Ruby. Which is fine, but that's not the only competition in town for node.js.

holografix 6y ago

Right now I’m trying to unit test an API on node that does a database query. I’m using express, mocha, supertest and typeorm. Mocking the database is fucking black magic. So I gave up and simply use an in memory SQLite db and add some records in the test body for my API to fetch and return so I can test. I’d like the db to basically get nuked and recreated after every test. So I use “afterEach” to close the connection and create a new one. No matter what I do, when I call the api endpoint using supertest it tells me my DB connection is closed. You’re thinking maybe the previous test didn’t reopen it or something. But there only one test. It’s like it’s closing it _before_ the test runs. As if afterEach is not waiting on the result from supertest (yes I awaited). I spent a _whole day_ today trying to understand just what the fuck is going on. Gimme goroutines _any day_.

akoutmos 6y ago
Testing with the database has to be one of the things I love the most about Ecto. No need to mock anything, no need to have special branching logic for test versus prod. Just use the database like you normally do. It gives you a degree of confidence that is on another level. Check out https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html for more info!
- striking 6y ago
  Testing with the database isn't particularly efficient. If you have enough tests, it becomes worth it to mock whatever would touch the database just so the tests pass in a reasonable amount of time.
  - napsterbr 6y ago
    > Testing with the database isn't particularly efficient. Anecdata, but my experience with Ecto sandbox + thousands of tests says otherwise. Mocking would be faster? Probably. But IMO not worth the effort, given it's already fast enough. To be fair, I have worked with Elixir codebases that generated humongous amount of data per-test, only to test a fraction of this data. This kind of test was slow, but it would be much more efficient to generate only the data you actually need.

christiansakai 6y ago

The issues described here is so overblown and mostly non issue/nitpicking. But I'm not gonna write counter-points here, plenty of those already online. Some of the commenters here will also write it.

egeozcan 6y ago

Javascript these days is a very productive language, especially with Typescript. Node however, with its lack of a remotely passable standard library, is not doing it justice. The async await is amazing and top level await works just fine in a browser console. The fact that node still has it behind a flag is... I mean, they surely have their reasons and I don't know enough to question the decisions of the maintainers, but it feels detached from modern times when using. Node is not web, don't know why they hesitate so much before remotely breaking things. I'm not advocating for moving fast and breaking things, remind you, I'm just saying that the io.js kick maybe needs to happen again.

nickthemagicman 6y ago
I think the author's argument wasn't that JS was a 'productive' language but that it was an overall poorly designed and bad language.
- egeozcan 6y ago
  So my argument is that a significant portion of the poorly designed part comes from node. It's also not a bad language. It's okay for its main purpose: Creating web applications. If people start using it to write distributed systems, async/await won't save you from any troubles you might have. Next.js is a perfect example for what JS is good for. However, the super lacking standard library frustrates me to no end.
  - nickthemagicman 6y ago
    It's not bad. Would I rather use anything else if possible? Yes.

debrice 6y ago

It’s really hard to read such posts. The tool is only as good as the contributor, that’s all there is. Great things were built in all languages and frameworks. For god sakes, stop blaming the tool by doing naive comparisons with other languages/framework. Nothing’s perfect, that’s a given, but these kinds of post smells so much like entitlement. You don’t need to trash your previous framework/language and discourage others. If you struggled using node don’t fool yourself that it was because of the tool and try to do the hard work of introspection and understand why you failed. Disclaimer: In case you think I’m bias toward node, I’m more of a python fast API guy, but I have tremendous respect toward NodeJS performance and async elegance (and even more when mixed with typescript)

harryf 6y ago
I get where you're coming from - the post meanders around some topics every programmer has to learn by hard experience, such as the value of being able to reason about code / systems and the importance of data structures. That said my feeling is Node gives you multiple pump action shotguns you can easily shoot yourself in the foot with. For example https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ > One common way to block the Event Loop disastrously is by using a "vulnerable" regular expression. If you're leading an engineering team, just this should be giving you panic attacks every time you hire someone new into the team. What makes this worse is it's very hard to detect problems at scale, if you missed it in code reviews. If you have one "vulnerable regex" in your event loop that only exposes itself on certain request inputs, it means that only every now and again - when given "bad input" - it's going to block the event loop. But then how to you detect issue? It's likely going to manifest itself first in _other_ requests that got blocked taking an excessively long time to respond. From an operational point of view, that's a nightmare scenario. Every now and again you're going to see slow requests in your logs but when you dig into it you find no problems. And that's going to make you very uncertain on how you're doing when it comes to scaling up; instead of a gradual slow down across all requests, you're going to see erratic spikes and jams. ...which actually occurs to me it's not unlike how traffic jams occur - https://www.youtube.com/watch?v=azmcu1cn2vg https://www.youtube.com/watch?v=azmcu1cn2vg - https://traffic-simulation.de/ https://traffic-simulation.de/

conradfr 6y ago

I'm still astonished that someone was writing Javascript on the browser and found the experience so great that he thought "I also want to do it on the backend!". More seriously, I'll admit I'm not a competent Node dev but the worst part for me is how convoluted you have to write large parts of code that don't need to be asynchronous or non-blocking in the first place. I also never figured why sometimes Node just silently ends without pointing my syntax error (and more importantly the line number). Like the author, in my mind Elixir is a better Node (Go never clicked for me). Some weeks ago I had to write a feature that was so perfect for Phoenix Channels, Presence etc that it was almost magical and quite fun. Nothing groundbreaking but I wrote about it here https://conradfr.github.io/ProgRadio/ https://conradfr.github.io/ProgRadio/

MangoCoffee 6y ago
>I'm still astonished that someone was writing Javascript on the browser and found the experience so great that he thought "I also want to do it on the backend!". I'm currently playing and learning Microsoft Blazor server side. i like the appeal of writing the whole app that feel like a Single Page Application in one language. whether that's good or bad is another matter.
DrFell 6y ago
Most Node devs are JavaScript monoglots, who just recently learned frontend, and figure "Let's use JavaScript for everything!"
LargeWu 6y ago
"More seriously, I'll admit I'm not a competent Node dev but the worst part for me is how convoluted you have to write large parts of code that don't need to be asynchronous or non-blocking in the first place. I also never figured why sometimes Node just silently ends without pointing my syntax error (and more importantly the line number)." This, so much. Even for moderately complex data workflows, 95% of the time what I needed to do was "execute a query or other IO operation, then do something with the result of that operation." But since js is async by default, I have to do extra work every time. Even if it's just a simple async/await declaration, there can be complications. Oh, your query failed with an exception so you want to do a rollback? Sorry, you lost scope to that db query when your promise was rejected. And don't even get me started on the stack traces, or lack thereof. If an exception was thrown inside a promise there's a 75% chance you're not getting anything useful out of that.

progx 6y ago

In some years: I escaped Elixir. Use the right tool to get the sht done.

joelbluminator 6y ago
So true. People pick new stacks all the time and then complain when after 10 years it's boring and there's shinier or more suitable tools out there. Now Node wouldn't be my first choice but I'm sure it's good enough for most purposes, easy to find people to hire etc. There's absolutely no reason to do a rewrite to java imo. I don't buy the "because types" argument.

justsomeuser 6y ago

The thing I dislike about message passing vs async/await is that it makes it easy to understand each individual process (that send and receive messages), but harder to understand the whole system. Assuming your CPU load fits on a single thread, a single threaded event loop with async/await seems easier to understand the whole system because: - Using functions to compose computations keeps the connection between functions at both write time in your IDE (jump to def), and production time with stack traces. - With message passing systems, you only get the stack trace from when you received the message. - Having a single thread means you are not sharing memory between threads. - You can combine results using Promise combinators, which form an await tree.

ipsocannibal 6y ago

The author took way too many words to say message passing between processes is a more grokable form of concurrency than callbacks. Then goes on to say that Node is less grokable than Erlang because concurrency in Node heavily relies upon async/await which is just pretty callbacks. There are some weak analogies to the importance of data structures mixed in to the text which aren't helpful. I think BOTH models of concurrency have their uses. The only problem I see is not being able to apply the appropriate one at the appropriate time because the language doesn't support it.