5 ms·

>Why is the JavaScript ecosystem like this? Because it's the product of a collaboration between ~1M beginner programmers, 100k intermediates, and 10k experts.

>Why is the JavaScript ecosystem like this? 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.

andrewstuart 4y ago
Nicely put. But what is this "build-less front-end" you speak of? Surely there's build somewhere, you're just hiding it?
- canadianfella 4y ago
  [dead]
- javajosh 4y ago
  The browser itself performs a kind of build step. It happens per script tag, and you can catch "compilation errors" in your own code using window.onerror if you want to.
  - andrewstuart 4y ago
    Surely you must use JavaScript libraries in your front end though ... don't they need compilation?
    - javajosh 4y ago
      Believe it or not, using libraries, compiled or otherwise, is not a requirement of either the HTML or Javascript specifications! The single biggest benefit of front-end builds is modularization; however browsers support that natively now (e.g. script type=module), and have for some years.
      - andrewstuart 4y ago
        >> using libraries, compiled or otherwise, is not a requirement of either the HTML or Javascript specifications But no substantial modern application can possibly be built without them. I can see that using modules could avoid the need for compilation.
        javajosh 4y ago
        >no substantial modern application can possibly be built without them. 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.
        deleted 4y ago
        [deleted]
        pwdisswordfish9 4y ago
        > no substantial modern application can possibly be built without them Check out Firefox.
    - deleted 4y ago
      [deleted]
- 778hbff 4y ago
  Plain foo.js file. Included in the web page. That's it. No compilation, uglify, translation, crap. Plain file, straight from your scm.
- Joeri 4y ago
  No build frontend dev is a thing, although obscure. Preact has a no build path in their documentation: https://preactjs.com/guide/v10/getting-started/#no-build-tools-route 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 https://github.com/jsebrech/create-react-app-zero
- ElectricalUnion 4y ago
  You can "do the build step" before deploying it to the CDN, kinda like how skypack esm modules work: https://www.skypack.dev/view/luxon https://www.skypack.dev/view/luxon 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.
778hbff 4y ago
> JS is the first language to really solve the distribution problem 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.
- javajosh 4y ago
  JavaScript is the only language in which you can write a program and distribute to every device in the world, today, cheaply and reliably. (technically this is an exaggeration - not everything has a browser. but you get the point.)
  - yakshaving_jgt 4y ago
    You don't need to write it though. The average Internet building person would be better off writing in a language which isn't terrible, and only using JS as the bytecode of the web.
    - javajosh 4y ago
      Maybe. I think of it as an experiment. You may be right. It may also be that the potential of raw javascript hasn't been fully explored. That's my hypothesis. I don't think jquery was the best it could do. Time will tell who is right!
      - yakshaving_jgt 4y ago
        JavaScript won’t go through any revolutionary fundamental change because such a change would break the entire internet.
      - JeremyBanks 4y ago
        [dead]
    - jakelazaroff 4y ago
      Believe it or not, some of us have written other "not terrible" languages and actually prefer JavaScript.
alkonaut 4y ago
To switch from JS to TS I’m willing to give up absolutely anything. I’d do five minute build times per small source file to do TS.
- javajosh 4y ago
  TS is probably as good as transpilers get. It really is quite good. I like that it maps one ts file into one js file and creates readable code (although output is normally bundled so readability is lost). I like that ts aids dev discovery in tools (intellisense) at write-time. But ts still needs a build step, and that's a big down-side to the immediacy of "plain" javascript. If browser vendors bundled tsc or its equivalent then we'd both be stoked.
  - ElectricalUnion 4y ago
    > 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 https://github.com/tc39/proposal-type-annotations Deno on the server side is pretty cool and uses https://swc.rs/ 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.
  - erik_seaberg 4y ago
    Having a build step is our only hope of being able to extend and customize the language.
mamcx 4y ago
> and to some degree it's design (or lack thereof) reflects the trade-offs required to hit the distribution problem out of the park. 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).
notacoward 4y ago
I'm trying not to sound all gatekeep-y, but I think this is the downside of a low barrier to entry. JavaScript has attracted a lot of programmers who just don't have the experience to manage things like maintainability, dependency management, or non-breaking upgrades. Some of them go on to create things that are great in the moment and deservedly become popular, but then fall prey to problems in these areas as they age. The same has happened to various extents and at various times with Python, Ruby, PHP, and so on. 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.
- Existenceblinks 4y ago
  I really don't like PLs that's optimized for beginners because I believes they are not in "beginner" phase for that long (probably a few months), and often time the PL trades that with downside that developers have to live with in next 10 years+. The selling point I'd like to see is not "beginner friendly" but median developers friendly.

andrewstuart 4y ago

Nicely put. But what is this "build-less front-end" you speak of? Surely there's build somewhere, you're just hiding it?

canadianfella 4y ago
[dead]
javajosh 4y ago
The browser itself performs a kind of build step. It happens per script tag, and you can catch "compilation errors" in your own code using window.onerror if you want to.
- andrewstuart 4y ago
  Surely you must use JavaScript libraries in your front end though ... don't they need compilation?
  - javajosh 4y ago
    Believe it or not, using libraries, compiled or otherwise, is not a requirement of either the HTML or Javascript specifications! The single biggest benefit of front-end builds is modularization; however browsers support that natively now (e.g. script type=module), and have for some years.
    - andrewstuart 4y ago
      >> using libraries, compiled or otherwise, is not a requirement of either the HTML or Javascript specifications But no substantial modern application can possibly be built without them. I can see that using modules could avoid the need for compilation.
      - javajosh 4y ago
        >no substantial modern application can possibly be built without them. 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.
      - deleted 4y ago
        [deleted]
      - pwdisswordfish9 4y ago
        > no substantial modern application can possibly be built without them Check out Firefox.
  - deleted 4y ago
    [deleted]
778hbff 4y ago
Plain foo.js file. Included in the web page. That's it. No compilation, uglify, translation, crap. Plain file, straight from your scm.
Joeri 4y ago
No build frontend dev is a thing, although obscure. Preact has a no build path in their documentation: https://preactjs.com/guide/v10/getting-started/#no-build-tools-route 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 https://github.com/jsebrech/create-react-app-zero
ElectricalUnion 4y ago
You can "do the build step" before deploying it to the CDN, kinda like how skypack esm modules work: https://www.skypack.dev/view/luxon https://www.skypack.dev/view/luxon 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.

778hbff 4y ago

> JS is the first language to really solve the distribution problem 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.

javajosh 4y ago
JavaScript is the only language in which you can write a program and distribute to every device in the world, today, cheaply and reliably. (technically this is an exaggeration - not everything has a browser. but you get the point.)
- yakshaving_jgt 4y ago
  You don't need to write it though. The average Internet building person would be better off writing in a language which isn't terrible, and only using JS as the bytecode of the web.
  - javajosh 4y ago
    Maybe. I think of it as an experiment. You may be right. It may also be that the potential of raw javascript hasn't been fully explored. That's my hypothesis. I don't think jquery was the best it could do. Time will tell who is right!
    - yakshaving_jgt 4y ago
      JavaScript won’t go through any revolutionary fundamental change because such a change would break the entire internet.
    - JeremyBanks 4y ago
      [dead]
  - jakelazaroff 4y ago
    Believe it or not, some of us have written other "not terrible" languages and actually prefer JavaScript.

alkonaut 4y ago

To switch from JS to TS I’m willing to give up absolutely anything. I’d do five minute build times per small source file to do TS.

javajosh 4y ago
TS is probably as good as transpilers get. It really is quite good. I like that it maps one ts file into one js file and creates readable code (although output is normally bundled so readability is lost). I like that ts aids dev discovery in tools (intellisense) at write-time. But ts still needs a build step, and that's a big down-side to the immediacy of "plain" javascript. If browser vendors bundled tsc or its equivalent then we'd both be stoked.
- ElectricalUnion 4y ago
  > 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 https://github.com/tc39/proposal-type-annotations Deno on the server side is pretty cool and uses https://swc.rs/ 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.
- erik_seaberg 4y ago
  Having a build step is our only hope of being able to extend and customize the language.

mamcx 4y ago

> and to some degree it's design (or lack thereof) reflects the trade-offs required to hit the distribution problem out of the park. 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).

notacoward 4y ago

I'm trying not to sound all gatekeep-y, but I think this is the downside of a low barrier to entry. JavaScript has attracted a lot of programmers who just don't have the experience to manage things like maintainability, dependency management, or non-breaking upgrades. Some of them go on to create things that are great in the moment and deservedly become popular, but then fall prey to problems in these areas as they age. The same has happened to various extents and at various times with Python, Ruby, PHP, and so on. 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.

Existenceblinks 4y ago
I really don't like PLs that's optimized for beginners because I believes they are not in "beginner" phase for that long (probably a few months), and often time the PL trades that with downside that developers have to live with in next 10 years+. The selling point I'd like to see is not "beginner friendly" but median developers friendly.