pianojacq VS es-module-shims

As someone who does this too: it depends. If you take time out every now and then to completely refactor your code base it can actually be surprisingly effective. I've done exactly that on my last project and I'm pretty happy with the end result, you can have a look for yourself:

https://gitlab.com/jmattheij/pianojacq/-/tree/master/js

This project will likely never be finished, there are always nice new things to add or requests from people, there is no commercial pressure because it is a hobby project and I don't have a boss to answer to. And even if such refactoring operations take me two weeks or more (this one I did while I was mostly just working on a laptop without access to a keyboard so it was sometimes tricky to ensure that nothing broke) in the end it is worth it to me because I am also paying the price for maintaining the code and if it is messy then I would stop working on it.

The project moves forward in fits and starts, sometimes I work on it for weeks on end and sometimes it is dormant for months. In a commercial setting or in a much larger team I don't think this approach would work.

Two things:

- adding interactivity to a web page vs building an application. Those are not the same thing, and what you read applies to the first

- there's a widely accepted belief that vanilla js is not suitable to build apps. I don't buy in this belief. I have a built networked Scrabble game written in vanilla js. Both the backend and the frontend. This simplicity allowed external contributors not well versed in the modern web stack to contribute. I also was able to enter the code of Pianojacq (from jaquesm) [1] and contribute quite easily because he also chose vanilla js. This simplicity is very valuable, and lost with modern framework, and nobody is really concerned about this.

I've done some React development, so I know my way in a modern app. I've also contributed to a frontend written in Vue. I think they solve problems but bring complexity to the table, in particular the tooling (bundlers, minifiers, etc), the dependencies and the debugging being much harder.

It seems DOM manipulation through native browser API scares many people, but when it's what you are familiar with, your usual "framework", it's manageable. You need to be disciplined to avoid things getting messy (a discipline frameworks partially enforce), but I really believe you can go far with vanilla js.

I believe React & Co are often picked to ease beginners' contribution, but they actually do require expertise. I'd rather touch vanilla js code from a beginner or an experienced developer than a React code from a beginner.

It's a matter of taste. Vanilla JS has the taste of fresh air to me. It's zen. You write the code and it runs. No tools, no slow compilation, no minification that complexifies the debugging. Minification which is only useful because with those framework you bundle an awful quantity of code in the first place. Yes, source maps exists but they don't do everything.

But today you won't have access to the whole ecosystem of existing React components with vanilla JS. It might be a curse or a benediction.

[1] https://gitlab.com/jmattheij/pianojacq

As for 1) yes, I can do that, the reason it is set where it is right now is because very soft keypresses on real pianos with sensorbars installed are typically fingers brushing keys on the way to other keys and these false triggers leave a lot of errors that aren't really errors. I'll make that setting configurable.

2) yes, if you look in the 'midi' directory on the gitlab site ( https://gitlab.com/jmattheij/pianojacq/-/tree/master/midi , but also linked from the application) there are whole bunch of them that all should work well

For full compatibility and extra features, we usually use the library es-module-shims.

You can polyfill for unsupported browsers, it works surprisingly well: https://github.com/guybedford/es-module-shims

https://github.com/guybedford/es-module-shims has a polyfill. (But it is fairly large: 53KB raw, 15KB gzipped, 32KB minified, 11KB minified+gzipped. It’s providing a lot of likely-unnecessary functionality. I’d prefer a stripped-down polyfill that can also be lazily-loaded, controlled by a snippet of at most a few hundred bytes that you can drop into the document, only loading the polyfill in the uncommon case that it’s needed—like how five years ago as part of modernising some of the code of Fastmail’s webmail, I had it fetch and execute core-js before loading the rest iff !Object.values (choosing that as a convenient baseline), so that the cost to new browsers of supporting old browsers was a single trivial branch, and maybe fifty bytes in added payload.)

If we call the shim a framework, would you be ok with it then?

If you want import maps to be supported in any browser, there is an ES Module Shims polyfill which is compatible with any browser that has baseline ES Module Support (i.e. Edge 17+, Firefox 60+, Safari 10.1+, and Chrome 61+).

An example of a polyfill that can be used is the ES Module Shims polyfill that adds support for import maps and other new module features to any browser with baseline support for ES modules (about 94% of browsers). All you need to do is include the es-module-shim script in your HTML file before your import map script:

i often use es-module-shims so i can load npm packages in browsers without a bundler 😎

I explored using client-side service workers for build-less deployment workflows a while back, but the blocker was the initial visit when the service worker hasn't been installed yet. Ended up using es-module-shim's fetch hook (https://github.com/guybedford/es-module-shims#fetch-hook) instead, which worked quite well.

I kept the demo repo around here, in case it's helpful to anyone: https://github.com/lewisl9029/buildless-hot-reload-demo.

The repo itself is quite out of date at this point, but my current project, Reflame, is essentially the spiritual successor: https://reflame.app/

Reflame has the same ideals of achieving the developer experience I've always wanted for building client rendered React apps:

- instant production deployments (usually <200ms)

- instant preview environments that match production in pretty much every imaginable way (including the URL), that can also be flipped into development mode for fast-refresh (for the seamless feedback loop we're used to in local dev) and dev-mode dependencies (for better error messaging, etc)

- close-to-instant browser tests (1-3 seconds) that enable image snapshot comparisons that run with maximum parallelism and only rerun when their dependency graphs change

The problem of course is that browser-support for Import Maps is sadly lacking (only Chrome/Chromium-based at time of writing). There are tricks/shims to get around this, like ES-Module-Shims. I find these approaches to be a little too intrusive, personally.