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.
What does Sails.js offer you over Laravel?
I finally escaped Node
101–110 of 181 posts
Re: I finally escaped Node
#102We 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 econo…
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 1…
> 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.
You are comparing stuff that is super helpful on large project with how to be quick in 1 hour by one person. If I have 1 hour long project in java, I wont use complicated design patterns. If I dont need Spring Boot or dependency injection, I wont use them. I am not sure what you mean by complicated annotations tho.
In Java, if all what you want is a method that processes some data, you wont use any of that and will just do a class or something like that. So if python have better methods to achieve whatever you want to achieve out of the box, it will be somewhat faster. But it will have zero to do with annotations.
Re: I finally escaped Node
#103I'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 sile…
Most Node devs are JavaScript monoglots, who just recently learned frontend, and figure "Let's use JavaScript for everything!"
Re: I finally escaped Node
#104Earlier quoted context omitted.
I think I might be missing what you mean? You can write an async/await implementation from scratch in a few dozen lines of elixir if wanted, but you also have Tasks that provide that already written for you (with support for being included into supervision trees, etc)? How does JS interoperate with something outside V8?
A JS library that wants to interop with something outside of its runtime (which is not necessary V8 - it isn't in WinRT, for example) can do so through FFI facilities. So long as said FFI supports all the same things that C does, it supports callbacks via function pointers. And if you can pass a function pointer + data pointer to some API, you have a stateful callback - i.e. a promise/future/task. And you can map any…
Here I'm a bit out of my depth.
I think with Erlang you don't need to know >that particular implementation of green threads, but you need to implement the required specifics of the VM FFI (which in practical terms might be what you meant) - but this has a reason, in that, for the VM to provide its guarantees it needs to be able to count "cycles", refs, etc in order to preempt the execution of any function/process at given points, so that no single process can block the scheduler. It also needs to transform things from and into data types usable inside the VM.
I think you can also use "dirty" nifs, but here you might crash the VM so you really need to know what you're doing (and you still have to translate things to and from the vm).
And there's also ports, and C Nodes. These have a higher sync cost but can be treated by the VM as if they were processes/erlang nodes.
Lastly, you can also just shell from the VM to an OS level process, or use sockets, etc.
But I doubt this is anything 99% of the people writing JS do in JS? One of the things people using Elixir or Erlang is exactly because of the guarantees and programming model of the VM.
Again, might be missing what you mention because it's not an area I have explored in any meaningful way.
Re: I finally escaped Node
#105Earlier quoted context omitted.
- Lack of a good standard api: I don't understand this one. I've never had a problem with its documentation and the API always seemed fine to me, but I don't use C# or Go so maybe I'm missing out? - There's a tendency in the ecosystem to abandon projects rather soon: This can certainly happen, but it's important to choose libraries and frameworks carefully. My node servers (Express.js) are extremely light weight, so…
Was the Java utility one that started and didn't run for very long, like a command line application? The JVM (at least the Oracle one) takes a long time to start up, so any application that runs on the JVM takes a long time to start up. The JVM is much better for long running processes.
A vendor gave us a .jar cli tool for managing an enterprise product last year, and I swear it starts up in under half a second (to the familiar spring boot splash too), so it is possible, just uncommon :)
Re: I finally escaped Node
#106Funny 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.
which course it that?
Re: I finally escaped Node
#107The 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.
Re: I finally escaped Node
#108Earlier quoted context omitted.
Your original point was that node.js has an edge because it has something nobody else has - low memory footprint, low latency, quick time-to-market, scalable. If the response is that "any modern web framework"can do it, then your point does not stand at all.
Sorry, communication gap. I was only referring to the part - "> can spin up a http service in a day Surely this is a typo?" I thought we were contesting that point only. I agree that a lot of frameworks can do that. On top Node/JS also allow developers to do web/native(ish with RN) and desktop apps with great tooling, libs etc. this combo is hard to beat.
It seems to me that a lot of frameworks can also do the other things! Even Java (though not for a lot of entrenched codebases) has frameworks sporting millisecond startup times and latencies nowadays, with very low time-to-develop.
I would also bicker that node.js is not that easy to scale horizontally, at least not notably easier to do so than any other single-threaded runtime.
IMO the only edges that node.js has are:
* some people know javascript
* for a dynamic language, the runtime is quite performant - you get more for your core, and that's cool
* I agree with the ideal that you can run the same language on the front and backend, but I have found in practice that two things are true. First, that they are actually different languages, with different runtimes and libraries. Second, the holy grail of e.g. serverside rendering your react app and having the browser take over represents a miniscule minority of JS deployments.
Nothing here means node.js is a bad platform, obviously, but it also is a platform I would only choose because I knew JS and was working with others who knew JS, or I was REALLY committed to the dream of isomorphic Javascript. It doesn't have any characteristics that would cause me to suggest non-JS developers go learn node.js.
Re: I finally escaped Node
#109We 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 econo…
- Lack of a good standard api: I don't understand this one. I've never had a problem with its documentation and the API always seemed fine to me, but I don't use C# or Go so maybe I'm missing out? - There's a tendency in the ecosystem to abandon projects rather soon: This can certainly happen, but it's important to choose libraries and frameworks carefully. My node servers (Express.js) are extremely light weight, so…
About lack of standard library:
I don‘t personally work with node for the backend but typescript/javascript in the browser. And I think what is meant is something like LINQ in C# (all kinds of functions you can apply on enumerables/arrays), some basic DateTime library (how to add two dates in JS? How to get the diff of two dates in days or hours in JS? Both are 1 liners in C#) and maybe some more stuff for string mutation and so on.
Re: I finally escaped Node
#110Earlier quoted context omitted.
- Lack of a good standard api: I don't understand this one. I've never had a problem with its documentation and the API always seemed fine to me, but I don't use C# or Go so maybe I'm missing out? - There's a tendency in the ecosystem to abandon projects rather soon: This can certainly happen, but it's important to choose libraries and frameworks carefully. My node servers (Express.js) are extremely light weight, so…
About lack of standard library: I don‘t personally work with node for the backend but typescript/javascript in the browser. And I think what is meant is something like LINQ in C# (all kinds of functions you can apply on enumerables/arrays), some basic DateTime library (how to add two dates in JS? How to get the diff of two dates in days or hours in JS? Both are 1 liners in C#) and maybe some more stuff for string mut…
It's a one liner if you use Day.js. It's makes no sense to include this functionality in Node.