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

211–220 of 323 posts

Re: JavaScript is Eating the World

#211

Post by quacker »

mmirate wrote: post #104
cdnsteve wrote: post #69

JavaScript has eaten my time. It's a really frustrating ecosystem to work in, all the deps, toolchains, build process is extremely fragile. I'm pushing everything to Python these days and some light front-end in JS where needed. Couldn't be happier!

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.

Re: JavaScript is Eating the World

#212

Post by pwdisswordfish »

shados wrote: post #139

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 s…

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

You don't, even when things can be installed. And that's where editors that eat half a gigabyte of memory to open a 6 MiB file come from.

Re: JavaScript is Eating the World

#213

Post by k__ »

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…

Also, it seems highly unstable.

Just look at all the Node.js drama. Today I read they want to fork again, while they just consolidated their last fork...

Re: JavaScript is Eating the World

#214

Post by Someone »

alayek wrote: post #138
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 ap…

I think your point stands, but something feels wrong to me about "you optimize for readability [...] You spread your code over 5 directories, 50 subdirectories, 3000 files."

We need lots of tooling to keep our code readable across a zillion files.

And it is worse than you mention. You rarely get 60 files per directory, and, in addition to the files you want, your package manager and build system add a few zillion of their own that all can break your build in 'interesting' ways.

Re: JavaScript is Eating the World

#215

Post by fahrradflucht »

eliaslfox wrote: post #146
fahrradflucht wrote: post #73

Earlier quoted context omitted.

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.

npm always did this. The OC said that he likes that yarn can also run local binaries that are not a npm script.

Re: JavaScript is Eating the World

#216

Post by thehardsphere »

k__ wrote: post #213
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…

Also, it seems highly unstable. Just look at all the Node.js drama. Today I read they want to fork again, while they just consolidated their last fork...

Is that the fork about the one contributor who annoyed some people on Twitter? Because that fork isn't worth paying any attention to; it's not going to go anywhere because it's pure politics.

Re: JavaScript is Eating the World

#217

Post by bigtunacan »

ryanmarsh wrote: post #209
enraged_camel wrote: post #187

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…

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 them JavaScript based.

One of the trends I'm seeing is that a lot of developers once they have built one web site as a SPA they seem to start thinking everything should be built this way. More consideration should be given to deciding which is appropriate.

Re: JavaScript is Eating the World

#218

Post by OtterCoder »

k__ wrote: post #213
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…

Also, it seems highly unstable. Just look at all the Node.js drama. Today I read they want to fork again, while they just consolidated their last fork...

Oh, this fork isn't in earnest. It's being overhyped because it's a select few people throwing a tantrum about ableism in the absence of any actual malice. There's no actual instability in the platform itself this time.

Re: JavaScript is Eating the World

#219

Post by thehardsphere »

quacker wrote: post #188
dirkc wrote: post #172

Earlier quoted context omitted.

I felt frustrated by the typical Node toolchain until I remembered the typical Qt toolchain for developing cross-platform desktop apps. I can't remember everything, but here goes. To compile a Qt app you need: - the meta object compiler (moc) to add dynamic features to C++ for Qt use - the Resource Compiler (rcc) to embed icons or sounds as arrays in header files - the Qt Quick Compiler if you are using QML files for…

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.

Re: JavaScript is Eating the World

#220

Post by Someone »

ashark wrote: post #84
lunchables wrote: post #14

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.

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…

I think most of what you share is the effort needed to learn the language.

Also, it 'helps' if both server and client are single-threaded, because then, you can use similar solutions on both server and client (even if they sometimes aren't the most pleasant approach for solving your domain)

I hope that Web Assembly will take of and get a decent interface to the DOM, allowing developers to pick other languages in the role that JavaScript now has.

Post reply on HN