Live data from Hacker News

JavaScript is Eating the World

dev.to

141–150 of 323 posts

Re: JavaScript is Eating the World

#141
post #21

Earlier quoted context omitted.

Node is single threaded, in the sense that your code runs in a single thread. Your code assigns microtasks, to be executed later. Basically, if you write in Node JS, there's no concept of a thread. The thread API is not visible or accessible to the developer. This forces you to think from the ground up about asynchronous operations that would take some time to complete - file opening, network requests etc., and have…

> In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?

Because Node is just a very thin wrapper around V8 and V8 has a limitation that it isn't re-entrant (can't handle multiple threads without breaking).

Re: JavaScript is Eating the World

#142
post #86
post #78

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…

You have it all backwards. Fashion is the reason you hate it, but before it was fashionable it was not. I get that you're bitter and angry, but you do yourself no service by sticking your head in the sand and willfully ignoring the forces that drive popularity.

I'm frustrated that better stuff doesn't win in the market as well, but I've been a web developer 20 years and Node's appeal was pretty obvious and exactly as the GP states. Without that it would not have gained traction to become fashionable.

Re: JavaScript is Eating the World

#143
post #138
post #96

I feel like it's less Javascript that's eating the world and more Node and NPM. It seems as if it's impossible to publish a Javascript project without taking for granted that the developer has, or even wants , a package manager with dependencies, arbitrary toolchain and transpiler along with it. Maybe I'm just a dinosaur for not wanting my "build process" for javascript to be more complicated than including a script…

The way to look at it, is that browser is a target runtime platform. When you write code in a team, you optimize for readability, maintainability etc. You spread your code over 5 directories, 50 subdirectories, 3000 files. When you want to run this in a browser environment, it needs to be optimized for delivery - faster download, less time-to-be-interactive. You need to split your JS codebase as per routes in your ap…

Agreed. 90% of the complexity of JS has to do with loading, in some form or another. You can't deliver 100MB application to your end user.

Re: JavaScript is Eating the World

#144

Earlier quoted context omitted.

Javascript as a language and ecosystem has evolved quite dramatically during the last years. Its not perfect though: it lacks features and ecosystem is still not in the level of maturity of other platforms, but is definitely going in the right direction. Regarding the single threaded server, its an architecture used before JS exists, and used by many other platforms/systems. Just to give you an example, Nginx workers…

In Nginx you're not doing computation, just passing IO thru between file system, external processes (i.e. PHP via fpm) and the network. If Nginx ever is CPU bound there's something bad happening. As I mentioned PHP: In PHP each worker is single threaded, too, but you can scale by having more workers in isolation.

I had this same idea until I found about: http://openresty.org/en/ https://github.com/Mashape/kong/

Making a full API on nginx via lua sounds crazy but it appears that people do it.

Re: JavaScript is Eating the World

#145
post #86
post #78

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…

After two decades in this industry, I've come to the same conclusion. Developers may use logic in coding, but trend-wise, we're bunch of herds following whatever others are doing. We forget whatever lessons we learned previously whenever something new comes out. It's good to see there are others who see insanity in it as well.

Re: JavaScript is Eating the World

#146
post #61

Earlier quoted context omitted.

Still a bigger fan of Yarn here. My personal tests have Yarn running a bit faster still, but I also like that Yarn's command syntax is easier. NPM seems content with making a million aliases of everything and it's annoying. I think they even added 'add' from Yarn. Also, Yarn's run command can be used to run locally installed NPM binaries, not just NPM scripts. i.e., you can do `yarn run -- webpack` and it will run th…

FWIW npm 5 comes with npx [0] which basically does similar things. If you run npx webpack it would use the local copy of webpack or even install one run it and discard it. [0] https://www.npmjs.com/package/npx

That's not the same thing. Npx is for running commands you install from npm, and yarn [command] allows you to run scripts defined in your package.json file.

Re: JavaScript is Eating the World

#147
post #122

Earlier quoted context omitted.

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 That's the point. There is no explanation, other than the same reason that bellbottoms are in again this year. Or out, I don't actually know. We pretend like we're "engineers" or "scientists" but there's nothing objective about what we do...

> That's the point. There is no explanation, other than the same reason that bellbottoms are in again this year. Or out, I don't actually know. You mean you can't come up with one. Because for me, which followed the scene for 20+ years, there is a perfect explanation.

which followed the scene for 20+ years

I had a homepage in 1994. I've seen them all come and go. This one's no different.

Re: JavaScript is Eating the World

#149

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.

[deleted]
Post reply on HN