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)

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 who spend more time wrestling with webpack et al than working on actual features.

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.

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.

Absolutely agree. But keep it off the server.

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.

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.

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.

>>For those of us who are building applications we need the complexity

I'm not saying don't build applications. I'm saying web applications can be server-only and should not spill over into the client.

Again there are exceptions - things like control panels or consoles do benefit from being SPAs. But in a lot of cases there is also nothing wrong or insufficient or unsatisfactory (from a UX perspective) about clicking a link and having the server send you pre-rendered HTML. JavaScript can still be used as icing on the cake to enhance those interactions, such as by displaying a spinner on the submit button and disabling it once the user clicks it.

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.

Agreed. 90% of the complexity of JS has to do with loading, in some form or another. You can't deliver 100MB application to your end user.

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 your interface - the C++ compiler, linker, etc.

This is either driven by CMake, qmake or your IDE!! I see you can use Qbs to generate the CMake or qmake files! I remember learning CMake, make, ant, etc being non-trivial!

Oh, and you were on your own when it comes to dependencies!

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

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

Well, the way I read what he wrote was that he was suggesting that bloat is bloat wherever it happens so that it's all a wash.

When I had the revelation I was thinking about the whole npm, bower, gulp, webpack toolchain.

Comparing C++ to Node or Python doesn't help me. If I could write Python that run in the browser I wouldn't be commenting here.

You can use unpkg[1] or other similar services to download or even directly embed scripts from npm. Great for testing.

[1]: https://unpkg.com

Like anything new-but-different in tech, it's probably a matter of using it for a while until you see the benefits.

I used to prefer a 0-dependency, no-build format for sites. Nowadays if something doesn't have an npm module it's enough for me to not want to use it for a variety of reasons.

I used to install "dependencies" by copy and paste and was happy, but because I didn't know how it could be better. Despite all of npm's woes (which are many) the concept is sound, and not just for JavaScript.

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.

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.

It gets easier once you get use to it. The output is a plain script tag include. Aot is one of the most amazing things I have seen. I can tell when an app uses it and when it is slow.

Do you mean to tell me my 5000 lines script is no longer acceptable?

No, but you do get a dependency tree of 5000 one-liners.

Don't be mean

be mern (sorry)