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

131–140 of 323 posts

Re: JavaScript is Eating the World

#131

Post by flavio81 »

falcolas wrote: post #62
alayek wrote: post #55

Earlier quoted context omitted.

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.

> a syntax known to a lot of web developers This is the key. And it reflects poorly on them for that. Syntax is the easiest part of a language to learn. The nuances of behavior is the hard part - and those nuances change as you move from the browser to the server; what makes good browser code will not make good server code. In reality they shunned a ton of knowledge and community support to keep a particular (and par…

> Even today, years after Node has reached popularity and many lessons have been learned, developers with no experience outside the browser think they can write perfectly good server code, simply because they know the syntax (...)

This is really true and it's sad, because it leads to more security problems on everyday software.

Re: JavaScript is Eating the World

#132

Post by flavio81 »

monsieurbanana wrote: post #112
flavio81 wrote: post #82

Earlier quoted context omitted.

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.

Theoretically, to what extend could the weird type conversions be prevented with the use of a strict linter? My intuition would be all, but I haven't thought much about it.

Once code reaches a certain complexity level (and mind you, the threshold is rather low), you'll need dynamic generation of code and data (or else, write 10x the amount of lines of code). For this to happen in a safe way, you really, really, do need the runtime to be strictly typed.

Re: JavaScript is Eating the World

#133

Post by ovao »

falcolas wrote: post #95
todd3834 wrote: post #74

Earlier quoted context omitted.

What does it warn you about? Not trolling, honest question.

That JavaScript was not designed to work as a *nix (or Windows for that matter) server language. And that any attempts to make it work as a server language are going to include some major workarounds to fit that round peg into a square hole. You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.

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".

Should we collectively eschew what's possible due to individual language gripes?

Re: JavaScript is Eating the World

#134

Post by specialist »

hood_syntax wrote: post #4

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.

My day gig is nodejs. I was interested in the problem space, didn't think too much about the stack. How bad could it be, right? Oops.

The worst aspect of nodejs is code construction (craftsmanship).

Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quite of a few new ones.

Frankly, I'd rather just write 'C' again. If I have to care about the fiddly bits, I'd rather the language not fight back.

My team spends a lot of time mitigating memory leaks and back pressure (bufferbloat due to thread/task starvation). I haven't done this kind of troubleshooting since my 'C' slinging days.

And this is apparently acceptable.

I find the current state of affairs (emperor has no clothes) appalling and baffling.

Re: JavaScript is Eating the World

#135

Post by tim333 »

falcolas wrote: post #62
alayek wrote: post #55

Earlier quoted context omitted.

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.

> a syntax known to a lot of web developers This is the key. And it reflects poorly on them for that. Syntax is the easiest part of a language to learn. The nuances of behavior is the hard part - and those nuances change as you move from the browser to the server; what makes good browser code will not make good server code. In reality they shunned a ton of knowledge and community support to keep a particular (and par…

Beyond the syntax, an event loop is conceptually simple in a way that other models often are not. (For example https://news.ycombinator.com/item?id=11555866 had a how to Python async and I found it a bit confusing compared to js).

Re: JavaScript is Eating the World

#136

Post by dboreham »

specialist wrote: post #134
hood_syntax wrote: post #4

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.

My day gig is nodejs. I was interested in the problem space, didn't think too much about the stack. How bad could it be, right? Oops. The worst aspect of nodejs is code construction (craftsmanship). Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quit…

My take on this (I have had the same experience, fwiw) is that it is like the well-known story of bridges falling down due to experienced engineers retiring (Tay Bridge Disaster, Tacoma Narrows Bridge for example). A new generation of folks who actually believe that "Single Threaded is a benefit" arrive on the scene and make a bridge that falls down..

Re: JavaScript is Eating the World

#137

Post by fundabulousrIII »

coldtea wrote: post #120
fundabulousrIII wrote: post #94

Earlier quoted context omitted.

Your paradigm is showing.

Notice how this doesn't even mean anything.

Sure it does. Ask a direct question get a direct answer.

Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.

Re: JavaScript is Eating the World

#138

Post by alayek »

krapp wrote: 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 app, and load chunks as per user demand.

Not just JS, you'd have to compile and inline your CSS, base-64 encode your images to data-urls, generate image stripes.

Before all these, you'd have to lint your code, and run unit tests on your code.

I fail to see how you can do all these with just a script tag. You need some sort of a compiler / transpiler; and a task runner that gives you a handy interface to these.

The package manager has no dependency, other than the Node runtime itself.

As for arbitrary toolchain, the metadata is codified with semantic versions in your package.json. You're one install step away from downloading all the necessary packages.

One thing I think lot of Node project misses, is to not add which Node version is to be used. It's not because it's impossible to do that - there are two well documented ways to do that (via .nvmrc and "engines" entry in package.json)

Re: JavaScript is Eating the World

#139

Post by shados »

The fact that JavaScript and the web platform kind of sucks while at the same time being "unavoidable" is why it's so good.

It forced a lot of very smart people and a lot of eyes onto the platform to try and find solutions within the extremely restrictive "box" to these problems.

How do you solve the API issues when you don't control the platform?

How do you solve for perf when things can't be installed?

How do you solve the API when you can't force people to upgrade?

How do you solve the language when you only have one language as a compilation target?

Out of these we got React and other vdom style view layers. FP paradigms got into the mainstream.

It exposed the mass to newer type system features

We got a toolchain that while complex, can do almost anything.

We got some test tooling that are ahead of other mainstream languages.

And every last bit of these went through tons of iterations (sure, javascript fatigue, whatever), and have had an immense amount of eyes on. You totally can look at any of the things I pointed out and say "Language X did it first!", but no one forced Language X on so many people, while JS was, so these things got a lot more exposure.

In short, I love the JS ecosystem precisely because it sucks so much.

Re: JavaScript is Eating the World

#140

Post by mattmanser »

randiantech wrote: post #15
hood_syntax wrote: post #4

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.

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…

I don't think it actually is going in the right direction, they've screwed up loads of things.

Things like getter/setters and object initializers. And don't even get me started on Web Workers, which basically seem to be dead on arrival. The Web Workers design is so shockingly bad and not fit for purpose that I don't understand how anyone signed off on it.

Some bits of the new js are in the right direction, and those are the things that people talk about and are getting used, but lots of things were definitely not.

Post reply on HN