Live data from Hacker News

JavaScript is Eating the World

dev.to

201–210 of 323 posts

Re: JavaScript is Eating the World

#201
post #124

Earlier quoted context omitted.

There are languages that I like better than JS. However, JS servers power trillions of dollars of business. People who grasp for reasons to hate on JS are a little like people who get into flame wars about video game franchise rivalries. It's symptomatic of deep unmet emotional needs in that person's life.

> It's symptomatic of deep unmet emotional needs in that person's life. Pretty sure pronouncements like that are the real indicator of unmet emotional needs. The way this community needles dissenting opinions needs to change. If you don't like the HN flavor of things, the resulting swarm of nitpicking, self-righteous commenters blots out the sun.

Is that really what you're seeing on this thread? Whinging about how horrible node.js and how horrible it is that we're all forced by the government to use it, is the conventional wisdom on HN. A few people disagreeing with CW is not "this community needles dissenting opinions".

Re: JavaScript is Eating the World

#202
post #84

Earlier quoted context omitted.

The front end/back end sharing argument never appealed to me. In practice, how much are you actually going to be able to share? No way it's worth it. What's finally got me writing way more Javascript than I'd like to is React Native. It's by far the easiest way I know of to share code between iOS and Android, it papers over a lot of Android's irritating/broken UI bits (introducing others, but overall improving the si…

the front/backend sharing stuff matters more these days with server side rendered apps, but I've used nodejs plenty for this lifetime and have no plans to touch the stuff again for serious applications

It's kind of funny how you say "these days with server side rendered apps". At one time not so long ago, there were only server side rendered apps.

Re: JavaScript is Eating the World

#203
post #133

Earlier quoted context omitted.

I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do". Shou…

No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.

> collectively evaluate competency and correctness of a developer

I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment.

As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as we've seen routinely evidenced, using a different language on the server is no panacea.

Re: JavaScript is Eating the World

#204

Earlier quoted context omitted.

That's exactly what it is. The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server. But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers wh…

Can you list any examples? My hunch is that there are good reasons javascript is included on most sites where it is found. Some of the incentives fueling this trend could be viewed as undesirable (e.g. monstrous ads on news sites as a desperate bid for profitability), but that doesn't negate the fact that the incentives exist, and aren't simply "people love over-complicating stuff".

Most of the web is so-called "content". Formatted text, images, video, audio. These require very little interaction. If you don't have user interaction and are just serving content, you probably need very little javascript. So I would say most major news sites, weather sites, etc. are examples.

To illustrate, hacker news and reddit work fine with javascript disabled, and the javascript they use is simple and just makes some interaction like voting work nicer. Even amazon, which is a pretty bulky and interaction-heavy site, works quite well with javascript disabled.

As for incentives vs over-complication, there's an interaction there. The incentives are to put some fancy whirly whingding on your website because it looks flashy and your target audience has (according to you) fast internet connections and web browsers. The incentives are to do this with the minimum of effort even if that means serving multiple-meg, javascript-heavy pages that don't even have any interaction.

Re: JavaScript is Eating the World

#205
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.

Even nginx? Nginx is fairly new compared to all the really old C code.

Re: JavaScript is Eating the World

#206
post #203

Earlier quoted context omitted.

No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.

> collectively evaluate competency and correctness of a developer I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment. As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as…

I'm sorry, what don't you understand? Complexity is best discussed by those who introduce it.

To be clear: I said js is misplaced on the 'server' side and is a wart in general when applied in that context. Any educated comment on these sentiments?

Re: JavaScript is Eating the World

#207
post #124

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…

There are languages that I like better than JS. However, JS servers power trillions of dollars of business. People who grasp for reasons to hate on JS are a little like people who get into flame wars about video game franchise rivalries. It's symptomatic of deep unmet emotional needs in that person's life.

I don't care much what websites use on their back end servers. As long as it keeps my data secure. But my interactions with JS on the front end are almost always unpleasant, so it's hard to be happy seeing JS succeed and proliferate in general.

Re: JavaScript is Eating the World

#208

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.

> 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??? So, like Nginx's model? Or 99% of Python servers? You can still run multiple processes...

>You can still run multiple processes...

The problem with Node is it's unsuitable for a whole class of server applications - you're going to run into trouble whenever you need to maintain serial access to a single resource. Whereas in Java you'd have some sort of token that gets "taken" by different threads, there's no clean way to do this in a multiprocess Node environment.

Re: JavaScript is Eating the World

#209

Earlier quoted context omitted.

This sounds a lot like how it's possible to fit a square peg in a round hole if you have the right drills and grinders and so on.

That's exactly what it is. The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server. But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers wh…

I wish this "the web is over complicated" meme would die. The web at one point was only for hypertext. It is still fine for hypertext but it is now also an application platform and the browser a runtime and app container.

Your solution to the JS ecosystem is to make news websites less interactive. I see why you long for simpler times but I don't see how that fixes things.

For those of us who are building applications we need the complexity. It solves problems that come from the fact that the web has evolved from a hypertext system to an application platform.

Re: JavaScript is Eating the World

#210

Earlier quoted context omitted.

This sounds a lot like how it's possible to fit a square peg in a round hole if you have the right drills and grinders and so on.

That's exactly what it is. The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server. But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers wh…

In my experience, even conventional form interactions like a list view with mass actions can be impossible without Javascript, and then unwieldy without some sort of framework to keep the UI consistent and a pleasure to use for users.
Post reply on HN