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

231–240 of 323 posts

Re: JavaScript is Eating the World

#231

Post by softawre »

thehardsphere wrote: post #219
quacker wrote: post #188

Earlier quoted context omitted.

I think it's more accurate to compare Node to C++, compare NPM to apt/yum/etc+CMake, and compare something like Electron to Qt. Of course, your point still stands. But's a tradeoff. C++/Qt has a ton of compile-time bloat, while Node/Electron has runtime bloat (see the Slack client using hundreds of megs of ram). And you can use bindings, like PyQt, where you have Python/Qt and then you get Python's dependency managem…

Compile-time bloat and runtime bloat are not equivalent. Runtime bloat inflicts pain upon users and therefore is usually worse.

Yes.. Don't you think that's why he bothered mentioning the words "runtime" and "compile-time"?

Re: JavaScript is Eating the World

#232

Post by thehardsphere »

woah wrote: post #116
falcolas wrote: post #43

Earlier quoted context omitted.

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.

Js is a scripting language that relies on the program being scripted to interact with the outside world. In browsers, this is the DOM and xhr APIs. On servers, this is the node stdlib which lets you interact with the system. The fact that this kind of modularity bothers you is bizarre.

It is a modularity that is an unnecessary point of failure compared to other choices available, and involves poor abstractions for Javascript to use things it was not intended to use.

Re: JavaScript is Eating the World

#233

Post by always_good »

tomc1985 wrote: post #189
woah wrote: 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.

Eh, scroll through the comments in every submission that mentions JavaScript (like this one) and you'll see a bunch of people lambasting anyone that uses JavaScript.

"Ugh, why would anyone use it on the server? Idiots!"

"Lol web developers only know one language. Sad!"

As if anybody that chooses a different set of trade-offs is incompetent, not just comfortable with a different set of trade-offs.

Re: JavaScript is Eating the World

#234

Post by free_everybody »

bigtunacan wrote: post #217
ryanmarsh wrote: post #209

Earlier quoted context omitted.

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…

The issue is not that "the web is over complicated". The bigger issue is that people are allowing themselves to be brainwashed into thinking that everything is a "web application". Some sites offer benefits as web applications; GMail and Pivotal Tracker come to mind right away as good examples. Other websites like CNN should not be applications and would do end users a disservice by over-complicating things by making…

I think this sums up the most poignant complaint against the javascript/node trend. It's not that we don't need SPA's. SPA's are awesome. But sites like Reddit and Hacker News prove that they don't need to be implemented everywhere.

Re: JavaScript is Eating the World

#235

Post by thehardsphere »

0xffff2 wrote: post #191
flavio81 wrote: post #132

Earlier quoted context omitted.

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.

Are you making this claim about JavaScript or as a general statement? I've probably written less than 1000 lines of JS ever (and that only for hobby projects), but I would strongly disagree with this statement as applied to C++, Java, etc.

I'm sorry, I'm confused by the way you expressed that. The argument was you need strict typing for large projects. C++ and Java have strict typing. What exactly is the basis of your strong disagreement?

Re: JavaScript is Eating the World

#236

Post by always_good »

quacker wrote: post #211
mmirate wrote: post #104

Earlier quoted context omitted.

Python is still dynamically typed, though at least it is less weakly-typed than JS. While the benefits of moving any distance away from JS's weak-typing are certainly obvious, why stop at Python rather than a language which is both strongly and statically typed?

They didn't mention anything about typing as reason for switching. They said "It's a really frustrating ecosystem to work in, all the deps, toolchains, build process is extremely fragile." They switched to python for the ecosystem and tooling.

I don't understand the distinction.

JavaScript tooling is notoriously complicated on the front-end, not the back-end. And I doubt they're saying that they switched to Python on the front-end.

Re: JavaScript is Eating the World

#237

Post by thehardsphere »

coldtea wrote: post #123
rootlocus wrote: post #110

Earlier quoted context omitted.

> If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow? If you're better with screwdrivers, why struggle with a hammer? JavaScript has a painfully slow runtime. Writing servers requires attention to performance and reliability, which javascript is very poor at. If you want to make a toy service and don't care about any of this, go ahead and use your favourite lang…

> If you're better with screwdrivers, why struggle with a hammer? Hammers and screwdrivers are not general purpose tools in the way that languages are. For most things, most languages are just as fine. It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. > JavaScript has a painfully slow runtime. I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of ta…

> It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is.

Uhh, what? You don't consider "programatically manipulate the DOM in the browser" to be a niche?

Re: JavaScript is Eating the World

#238

Post by thehardsphere »

johannes1234321 wrote: post #28
randiantech wrote: post #15

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.

PHP isn't exactly the best alternative to compare node to; it was pretty much designed specifically to live in an Apache request-response cycle. It's not hard for most things to beat it in contexts outside the one it was intended for.

Re: JavaScript is Eating the World

#239

Post by zeveb »

alayek wrote: post #52
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 pr…

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

I don't think that Electron is an argument for JavaScript.

Re: JavaScript is Eating the World

#240

Post by falcolas »

ovao wrote: post #133
falcolas wrote: post #95

Earlier quoted context omitted.

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

Here's my thoughts about that from a sibling thread:

https://news.ycombinator.com/item?id=15090278

TL;DR: Writing JavaScript for the browser won't really help you write good JavaScript for the server.

Post reply on HN