> JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required.

Mind that this was not that much of a problem back in 1997 with Netscape Navigator and Netscape Enterprise Server. I think, the real issue here is that the JS ecosystem is targeting an abstract implementation, rather than a real world one. Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking).

> Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking).

So long as you have browsers in various states of compliance and paying customers using those browsers, this will always be a problem.

The challenge of JS is and has always been finding a productive corner of all the possibilities of what you can do with it, and optimizing within that corner.

Usually that means picking up a subset of well supported frameworks that you like and find works well in the domain you’re in. It also means learning what language features not to use, or at least abstract away their use. People coming from highly opinionated languages with a large standard library tend to shoot themselves in the foot because they don’t understand this, and nobody really tells them. And inevitably a discussion turns into an argument with different sides becoming Balkanized because they use different parts of the possible language/library set.

> be careful what you install and read the source code to understand what it is doing.

That’s the reason why I started to love pika.dev ‘s package search. Webpack still sucks and will ruin your day with hours of unnecessary configurations and fixes.

On the other hand, when setting yourself a rule to use plain ESM only without any build system, coding has been a joy.

The only thing that still sucks is UI frameworks, because all major frameworks still require a shitty babel workflow in one form or the other. Vue.js has an ESM module which is useless without babel (due to the .vue file format), and Angular/React are still in the lets-invent-our-own-language fatigue.

Lately I've been developing with a JS workflow that's finally made me think "hey this is fun!" again:

Chrome target, native ESM modules, VS Code with JSDoc annotations for types. All libraries (chosen preferentially from microjs.com) are copied into vendor/, and the front end is written in preact.js using htm [0] for native JS tagged html strings, leading to code like:

  import ImageView from "./image-view.js";
  render({ trail_item, selector }, state) {
    /** @type {LinkItem} */
    let link_item = trail_item;

    let title = this.render_title(trail_item);

    let favicon = this.render_favicon(trail_item);

    let img = html`<ImageView src=${favicon} />`;

    return html`${img}${title}`;
  }

There's a VS Code extension which formats html`` strings as actual HTML, and the Typescript checker built in to VS Code gives me advanced types and autocomplete, all with a workflow that's as simple as "refresh page".

Granted, not every project can afford to target just evergreen browsers, but for my use case it works perfectly and I finally feel like I have the perfect blend of old-style web dev (in terms of refresh cycle) with modern language features and typing. The overhead, both in page-weight and cognitive load, is as small as I can make it.

EDIT: Modified my code sample to show how you can use Preact components in a JSX-like way.

[0] https://preactjs.com/guide/v10/getting-started/#alternatives...

Yeah, the microjs approach is much nicer than the Node approach.

I think the mistake of modern JS (and many other languages) is conflating source files with libraries. A better model is combining many source files into one library file, which provides one toplevel name when imported. A good example is how Three.js, which has a complex internal structure, gets distributed as one file and provides one toplevel name THREE. And of course there are many examples in C-land, where a large library can live behind a single header file. A project should only depend on a handful of those, and there should be few dependencies between them, so package management becomes easy enough to do by hand - just drop a file in your project's vendor/ directory.

As a bonus, this fixes the problem of having many fine-grained imports. If done right, your project's source files might not need any import statements at all. Anything inside the project could be available without ceremony, as if it was all one big file, and external libraries live in a handful of big namespaces which are also available without ceremony.

I don't know enough about Three.js to say if that works well for them or not, it probably does, but I don't think a future where all libraries would do this would be very bright. If the library is big, you'd end up shipping a whole lot of unused code to the client, making the end user bored and angry while waiting the page to load (especially if they are the sort of person who hangs around in Hacker News). In fact, the direction has been the exact opposite in recent years! Look at how lodash has moved to exporting one function per one file so you can include just as much of the library as you need.

I was mostly talking about how things should look to the programmer. The compiler could still tree-shake the final version.

Sure, it's just that the person you were answering to--and this whole thread really--seem to be advocating for just importing module files without any sort of build step. Without a build step I also assumed tree shaking wouldn't be an option. Tools that handle tree shaking, like Webpack and Rollup, aren't really the simplest of JS tools anyway so if we are talking about simplicity of dev experience, I'd argue that multiple direct file imports--how inconvenient it may be--is still _simpler_ to get right than "single namespace import" + tree shaking.

> The only thing that still sucks is UI frameworks, because all major frameworks still require a shitty babel workflow in one form or the other. Vue.js has an ESM module which is useless without babel (due to the .vue file format), and Angular/React are still in the lets-invent-our-own-language fatigue.

The pain is real. Create-react-app will dump 250 MB+ of files in node_modules

however, newer approaches are emerging and (hopefully) will be stable soon. few noteworthy ones are:

1. SnowPack[0] (in early access) 2. Vite[1] (from author of Vue.js) . It is in experimental phase. but is quie good. 3. Unnamed project by Author of Preact.

[0] https://www.snowpack.dev/ [1] https://github.com/vitejs/vite [2] https://twitter.com/_developit/status/1264062182326710273

A lot of UI Frameworks need webpack, I had been looking at web components...

You can build Vue applications without bundler... file is JS extension, you use

const template =` <you html stuff here> `

React has no invented language. You’re thinking about jsx which isn’t needed. It is recommended, however.

> It is used everywhere, however.

Fixed that for you.

React without jsx components is just as useless as Vue without .vue files. If you cannot use the ecosystem of a framework in practice, your framework isn’t a framework anymore.

> React without jsx components is just as useless as Vue without .vue files.

It's not useless at all. JSX in React is just an alternate syntax for React.createElement calls.

Wrong, you can still use VueJS without the vue extension...

https://dev.to/arswaw/create-a-lightweight-componentized-spa...

Is it me or is the real problem that someone wrote a package and quickly wrote use “import ...“ instead of writing “const x = require(“...“

Node works fine out of the box from the command line, modules just need to have the correct instructions for the README.

That wouldn't have helped anyway. The file was written in TypeScript. Node would have barfed immediately.

Libraries with TS codebase almost always have a prebuilt bundle.