Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is Eating the World

dev.to

Post reply on HN
Print view View original

51–60 of 323 posts

Re: JavaScript is Eating the World

#51

Post by Brockenstein »

phaedryx wrote: post #13

Summary: "Javascript is eating the world because 5 huge companies use NodeJS" Not sure I buy the argument.

Javascript is eating the world because so much stuff runs through the browser these days and javascript is a given to be available.

That alone will effectively stop the world from migrating away from JS. More and more people will give NodeJS a whirl, confident at very least that JS isn't going anywhere for quite a long time.

It just creates a cycle where you're going to see very little slippage in JS usage and most of the time ever increasing usage. It won't be this way "forever" but we're probably a decade away from peak JS.

Re: JavaScript is Eating the World

#52

Post by alayek »

nilved wrote: post #6

What a depressing idea. I don't take JavaScript seriously at all.

Sorry to say this, but this kind of statements don't really add anything to the discussion. _Only a sith deals in absolutes_.

Recently, JavaScript has adopted lot of language feature from C#, Ruby etc., that make it really useful for most common tasks. And the community moves really really fast, hence adoption of new language syntax is quite fast.

JavaScript has some killer platforms / apps, that are being used in production by high-traffic companies.

You can do cross-platform Desktop app in Electron (Slack, VSCode, Atom etc. are written with this).

Front-end build tools are written in Node JS, and they do lot of heavy lifting as well. Babel is a transpiler, Webpack is a bundler.

These days, native mobile apps (not hybrid apps) in JS are also gaining traction, via React Native.

From open source communities to big behemoths are behind this.

I would like to hear what about JS turned you off so much?

Re: JavaScript is Eating the World

#53

Post by g00gler »

phaedryx wrote: post #13

Summary: "Javascript is eating the world because 5 huge companies use NodeJS" Not sure I buy the argument.

Right. The following could be written as "Netflix uses Node to render React components" which is pretty much a given.

> Java still powers the backend of Netflix, but all the stuff that the user sees comes from Node. In addition to Node, Netflix is also using ReactJS in their stack.

Re: JavaScript is Eating the World

#54

Post by falcolas »

TrickyRick wrote: post #44
johannes1234321 wrote: post #28

Earlier quoted context omitted.

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.

What computations do you do in a webserver which hosts a REST API? Most of it is simple CRUD connected to a database, possibly with an auth layer on top, which is pretty much what you describe, passing IO through to a database and back.

Compression, hash computation, regular expression routing lookups, parsing text, building and serializing datastructures, reading and writing caches; I could go on.

Sure, JavaScript (and Ruby and Python) are usually fast enough with modern hardware - but we can't pretend there's no cost.

Re: JavaScript is Eating the World

#55

Post by alayek »

falcolas wrote: post #39
alayek wrote: 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…

Using non-blocking IO is a very old trick. Even nginx does exactly this, and it's written in C. The ability to use non-blocking IO does not make a language unique in any real fashion.

I have never claimed that it's unique. In fact, most ideas in tech is just old wine in a new bottle.

However, I guess what made it appealing initially, was that it uses a syntax known to a lot of web developers. The callback pattern helped.

Although these days, we have been moving away to generators or async-await.

Re: JavaScript is Eating the World

#56

Post by Brockenstein »

nilved wrote: post #6

What a depressing idea. I don't take JavaScript seriously at all.

It is an interesting example of how a camel is a horse designed by committee.

And basically the reason we have JS is because we can't agree on anything else. So JS is what we've got.

But you should take JS seriously, because it's what we've got. It's not going anywhere. And it powers the Internet. And for right now the Internet is the end all, be all, technology.

Re: JavaScript is Eating the World

#57

Post by falcolas »

sk5t wrote: post #36
fao_ wrote: post #32

Earlier quoted context omitted.

Do you deny that implementations are part of the language? If the Javascript specification left this out, what other implementation gotchyas exist for them to exploit?

Few but you likely consider the implementation part of the language.

Count me as one of them.

The implementations are what matter. They're the only thing that matters. It's the business axiom "Ideas are worthless, it's the implementation that counts" at work.

Ask yourself this: If V8's performance was still at 2010 levels, would Node exist?

And if some other language were the one which had been picked for browsers - JavaScript relegated to only running on servers - I wager JavaScript would hardly be used at all.

Re: JavaScript is Eating the World

#58

Post by jononor »

jcelerier wrote: post #27
alayek wrote: 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 ?

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 service: done by a load-balancing HTTP router and/or a message broker like RabbitMQ. Another example is when using out-of-process persistence like with Redis.

Re: JavaScript is Eating the World

#59

Post by alayek »

falcolas wrote: post #49
talmand wrote: post #37

Earlier quoted context omitted.

I'm beginning to think npm has joke potential like regex. "I had a problem. I started using regex and now I have two problems." Becomes... "I had a problem. I ran npm install and now I have 21,735 problems."

It bothers me that I have to agree with this. I watched an NPM install once, and noticed that one particular library was downloaded and compiled somewhere around 40 times (and each compiled version was different). Think about that for a moment: one library, 40 versions downloaded and compiled to fill NPM dependencies. What if there was a vulnerability in a version of that library - how do I audit that? Can I even fix…

Personal experience: NPM can be mind-bogglingly slow in Windows. In my previous day-job, an NPM install on Windows 7 could take hours, for some reason. That's NPM 3 with about 20 dependencies on a small project.

NPM on Windows also had other problems such as Python path is wrong or C++ compiler is missing.

Then we switched to Yarn. Uncached install took about 2-3 minutes, and cached install would finish in seconds.

Recently, NPM 5 has been released, and it's been competing well against Yarn.

Re: JavaScript is Eating the World

#60

Post by onion2k »

What you build is infinitely more important than what you built it with. If someone writes a better Google the users won't care if it's using Javascript, Rust, or QBasic. They'd still be all over it.
Post reply on HN