Excuse me, what? I just spilled my coffee all over the desk.
Care to explain what you mean with the problem and how js "solved" it? In my view dependencies and distribution are terrible in javascript, but maybe we mean different things.
To want more failure is to be insane. I think rather a lot of programmers think they’ve tried alternatives, but in reality have experimented with syntax swaps of what is essentially the same language.
Elm would be an example of a language which is fundamentally better than JavaScript (and is a practical substitute for what most people are writing JavaScript for), but it isn't the only one.
I think you are falling into a trap of thinking there is a “best” in engineering when that’s basically never the case. Ask experienced developers why they prefer Javascript if you want to get a more nuanced view. I almost always reach for Javascript first, especially for server applications.
My code is not poetry; it kinda sucks. I’m not a gifted programmer, which is why I make up for my shortcomings with better tools. I use Haskell entirely for the sake of pragmatism [and have in fact bet my businesses on it]. My experience is such that I can build something that just works much more quickly and reliably in Haskell or Elm than I ever could in PHP or Ruby or JavaScript or Clojure[Script]. And I wrote each of these professionally for years.
In other words, there's a simple way to disabuse yourself of your position in this comment: https://news.ycombinator.com/item?id=34257196 -- just ask experienced engineers why they prefer languages that you consider to be irreparable.
Ah sorry, overlooked that.
Related to C pray they didn't hardcode implicitly something of the architecture. Or be surprised when a bad pointer fails in one OS but works in another.
The .net languages are wonderful. The best time I remember in my life was trying to debug what version of the .net runtime was required for a program. So much better than getting laid or going on holiday /s
This environment is additionally hostile to compilation - TypeScript had to bring some really amazing type system features to the table to get most engineers to reluctantly accept the headaches of compilation for the browser.
ES6 Modules, HTTP/2 and sourcemaps were supposed to fix these issues to some extent and all of them created major new headaches instead. Its like there is something fundamentally broken about the browser that we're not getting which sabotages all solutions we've come up with so far.
The JS ecosystem is the furthest ahead in making this broken environment barely usable with a bunch of hacks to compensate for its shortcomings - a new language will need to fight hard to get close.
But what is this "build-less front-end" you speak of? Surely there's build somewhere, you're just hiding it?
But no substantial modern application can possibly be built without them.
I can see that using modules could avoid the need for compilation.
That's certainly false, since substantial applications predate React, Angular, svelte, etc.
But you have a point. Steve Yegge once wrote that his company wanted to write a word processor in assembly and it seemed like a good idea at first, but then it was like drawing a straight line 100m long using only 2mm line-segments. The major purpose of these libraries is to increase the "length of the line-segments" to something more consistent with the distance you want to cover. The question is whether or not their exists a unit of abstraction in raw js/html that serves this same purpose. E.g. it's a demonstration proof.
Working on it.
Check out Firefox.
Preact has a no build path in their documentation: https://preactjs.com/guide/v10/getting-started/#no-build-too...
And here’s my no build react setup: https://github.com/jsebrech/create-react-app-zero
Of course, unless you do it tailored for your project, you don't get some nice features like tree shaking, but it's very convenient.
How so? The first part I agree (as pure accident and the fact is thing bundled on the browser) but JS/C share the same problem: Terrible "design", ill-suited to the task, but sadly what was bundled.
And resistance to fix them (where in the case of JS could be super-mega-easy).
If browser vendors bundled tsc or its equivalent then we'd both be stoked.
Not exactly this, but there was a proposal that would allow for typescript type hints to be considered as normal JS syntax: (in the same way python PEP 484 – Type Hints are considered optional type hints)
https://github.com/tc39/proposal-type-annotations
Deno on the server side is pretty cool and uses https://swc.rs/ (Speedy Web Compiler) - doesn't take forever to start, but kinda implements typescript as if it was just a type annotations without the more in-depth actual type checking, so it is possible.
On balance lower barrier to entry is a good thing, but it does have characteristic problems too. In fact, I'd say fault lies partly with more experienced programmers and particularly packagers, who often tend toward avoidance (or worse) instead of helping these newer ecosystems avoid known pitfalls.
Because it's the product of a collaboration between ~1M beginner programmers, 100k intermediates, and 10k experts. Because the language and runtime are "mushy" - aka "under-constrained", which allows for all the ideas to flourish, even the "bad" ones.
It's a mess, but a glorious one. JS is the first language to really solve the distribution problem, and to some degree it's design (or lack thereof) reflects the trade-offs required to hit the distribution problem out of the park. In hindsight, it was bound to turn out this way!
IMHO the single worst thing about js is the front-end build experience. It's so nice to write build-less front-end! And yet (most of) the community seems obsessed with WebPack and inventing new transpiled languages etc. It's really bad! Not only is it a far, far worse DX but it breaks the thing that makes the web cool, that you can "view source" and figure out how other people made stuff.