111–120 of 323 posts
Earlier quoted context omitted.
It gets easier once you get use to it. The output is a plain script tag include. Aot is one of the most amazing things I have seen. I can tell when an app uses it and when it is slow.
Do you mean to tell me my 5000 lines script is no longer acceptable?
Earlier quoted context omitted.
With ES6, JS became a really nice scripting language. Personally, I'm glad to see more and more projects that use javascript outside of web browsers and I've also added V8 to my most recent C++ project. The only major drawback in my opinion is, that it's not statically typed.
The deeper problem is that JS is not strongly typed. Typescript gives you static type checks but the runtime is still weakly typed and will still do all sorts of weird type conversions.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
(Worth watching no matter what your background is, it's funny and informative)
Earlier quoted context omitted.
And it seems, his operating system allowing the browser process to take all the CPU.
I would argue that all modern Operating Systems have dark corners and hidden bugs. It is just a question of time until you hit a similar bug on any OS. I had a similar experience on macOS with Chrome Canary watching a YouTube movie full screen. My laptop simply froze, nothing, except a restart, worked.
The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.
So, like Nginx's model? Or 99% of Python servers?
You can still run multiple processes...
Earlier quoted context omitted.
I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've never written anything on node.js, but that's the only argument that's ever given me pause.
It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.
What they don't say in this panegyric to node is that.. 1. The language (js) is absolutely horrific. 2. node is single threaded and non-blocking/async in I/O for some operations but when blocking requires libuv and gymnastics. 3. It moves too fast for stability. I've encountered huge memory leaks with node at various versions that are terrible to debug. 4. It is designed to the lowest possible specification for devel…
> It is designed to the lowest possible specification for development: web developers. This is not a productive comment.
Maybe. Callback / promise hell in a language that needs a book like "Javascript the good parts" is probably not eating the world. Yeah it is cool, npm package system is (was?) one of the easier ones to use. It is a good starter thing for someone who has only learn or done frontend development before. But I have not had a good experience with it on the backend.
Earlier quoted context omitted.
It has nothing to do with the language, there were other serverside javascript frameworks before node; they didn't take off (e.g. Narwhal). Node's success has everything to do with the environment itself in combination with the language. The node runtime, the associated stdlib, and most open source/3rd party modules have been written for a non-blocking runtime from day #1. The same stuff can be achieved in plenty of…
Node's success has everything to do with the environment itself in combination with the language. Let's be honest: it is nothing to do with either of those and purely a matter of fashion. In a couple of years at most there will be a new new thing and everything will revert to version 0.1, keeping everyone busy but making no actual progress. Gotta soak up those CPU cycles the hardware people are giving us somehow righ…
Let's be honest: if you need "fashion" or "idiocy" etc to explain a trend in tech, you don't have an explanation.
Your explanation wouldn't even explain why it was Node+JS that got to be "in fashion" and not something else from the 20000 options.
Earlier quoted context omitted.
I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the…
Your paradigm is showing.