3 ms·
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!"
by 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 agoMost 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.
- hajile 6y agoTry writing evented code in Python or Ruby. It’s very hard because most libraries in those languages block all over the place. There just isn’t much run in the middle between these paradigms. Any time you spin off a new thread or process, it’s going to eliminate that nice continuous call stack (though there has been some work on this). That’s not a JS issue but more an issue of async programming in general. I’d love to see JS unify web workers with BEAM-style lightweight, managed actors since they aren’t incompatible. In the meantime, I’ll take the minor pain around async for the massive performance boost relative to other scripting languages.
- dariusj18 6y agoIt's not that they loved writing Javascript on the frontend, it's that they can't write anything else on the front end. So why use two languages when one will do?
- schwartzworld 6y agoHurr durr JavaScript Bad! Lots of people like writing JavaScript, and it's perfectly capable of lots of tasks both large and small. > 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 Perhaps your reticence to actually learn the language is the source of your difficulty?