Hacker News Reader

Comment by Animats | Hacker News Reader

It's become easier to build with hard-compiled languages than with interpretive ones. Interpretive ones shouldn't need "building", but they seem to acquire build systems anyway. Compile and link systems at least diagnose what's missing during the build process, not during execution.

View on HN

I don't know why people do this. In more complex areas of programming the code and tooling are simpler. It seems like any ecosystem just fills up to the certain level of complexity regardless of the complexity of the original task at hand.

Since you mentioned complexity, past a certain level of application complexity, you realistically can't do a linear list of Javascript files that you import on the page in order. When you have hundreds of views, you don't want to manually go and figure out what each of them needs as prerequisites. Circular dependencies are annoying when you do it by hand but practically trivial with a packer as long as they're logically sound. Inversion of Control. On-demand loading. These are all problems that have been previously solved by hand, but when you don't want to solve these prerequisite problems before your actual business (or hacking) problems, you build tools to do it for you.

"Can't do a linear list of Javascript files that you import on the page in order" - sounds like a problem that a BCPL developer has stumbled upon 50 years ago while writing his include directives.

If web programmers had the choice to install an arbitrary language's runtime in users' browsers, they would. But users have disparate browsers with disparate JS implementations, so if you want to code in a sane language with consistent behavior, you'll need to transpile and polyfill it.

You can't just distribute arbitrary binaries to users on the web, so web developers have to deal with a layer of complexity that other programs don't have to. That said, maybe WebAssembly will change this story.

> web developers have to deal with a layer of complexity that other programs don't have to

yep, other programs totally don't need to deal with different OS, graphics APIs, GPU driverstacks and hardware architectures.

Those are all runtime concerns. They don't affect the literal syntax that you write, as is the case with JavaScript. You can't feature-detect syntax. Instead your entire program will just fail to parse.

So like shaders?

Are there other languages that suffer from this? I think Python, Erlang, Ruby at least seem to have escaped the fate so far.

The upside of the JS transformation into just another compiler target is that there is little reason to use JS as the source language, IMO. These JSVM languages do suffer from the same problems to varying degrees.

Python has "eggs" and "wheels" and many headaches involving them.

They most of the time work though. Except for a python environment + python version, not much is required to work with it.

There is no package.json, typescript, flow, javascript mix, with tens of things configured which change frequently.

Also continuing to work on a python project after a year often is not much of a hassle.

That being said: virtualenvs still seem to be complex matter, especially when you are a beginner.

A major difference is that JS developers have little control over the runtime of their users, while all these other languages and especially compiled languages do. JS is a special case because it's the sole supported language of browsers, which all implement it differently—that comes with a unique layer of complexity.

Reply on news.ycombinator.com