Skip to content

Can we use Babel / Move inline JS ?

Modern JS

Making the choice to drop support for IE11 means we can write modern JavaScript.

There are just a handful of things we can't use yet. Two really nice features that we miss especially are actually not much more than a shorthand/convenience.

The JS we can write for modern browsers today is really very enjoyable, even without being able to use ??, ?. and { ...object, ...otherObject }.
We have fetch, promises, arrow functions, and many convenient Array. and Object. methods.

Instead of object destructuring, we still use Object.assign( { one: '1' }, { two: '2' } ) instead of the nicer { ...{ one: '1' }, ...{ two: '2' } }. In the end, it is only a small inconvenience.

Transpiling / Using Babel

In default Hyvä it makes little sense to use Babel. Which is not to say you can’t use it on top of Hyvä.

This is as much a design choice as a ideology. Considering the arguments from this FAQ about IE11, there is no use-case for making Hyvä IE compatible, because there are more factors than just syntax that weigh in.
There is very little functionality we really miss as a must have that don't outweigh the downsides.

  1. The added complexity of having a build process
  2. Code size being bloated by polyfilled code, not relying on native browser functionality
  3. Loss of in-browser debugging functionality (yeah, source-maps fills that partly)
  4. Loss of in-browser readability of code. We want people to be able to read and understand the code and being able to fiddle with it in the browser.

The future is today. Browser support is much better than most of us think. And if you're writing really complex components and you want to leverage compiling/transpiling, you're 100% free to write a library file or a main.js file for your theme where you do this. The default theme is as lightweight as possible, but you can slap anything on top of it.

In-lining JS

This is probably the most controversial topic: Inline JavaScript. Most time and consideration went into this architectural choice.

How do you rebuild the foundation and redo an entire frontend?
How do you make it comprehensible, composable, simple, lightweight and fun? The choice to use only inline JS is a opinionated preference, so naturally some people will disagree with it.

The reason PWA/SPA solutions are not a fit for everyone (and perhaps Hyvä won't be a fit for everyone either) is because of the complexity of those modern JS-driven frontends.
They add a lot of layers of complexity that are hard to get used to and for some, hard to master.

Magento's knockout stack was hard to learn. I think a Magento backend developer in general finds it easier to adjust a UI-component than a frontend developer. Finding out in which file things are declared and back-tracing from which file a jQuery plugin was extended and where variables were declared takes some serious debugging and tracing down multiple files.

That's were extensibility and modularity comes at the price of development speed and developer happiness.

Nothing is more frustrating than spending hours on a task that was expected to take minutes.

Besides that, when loading external dependencies, you're bound to load in dead code. You'll start to bundle code/files and load in more code than is actually needed on a particular page. It gets worse when your product evolves and code becomes deprecated and won't be cleaned up (for instance for backwards compatibility).
One argument we have heard often is "it is one bundle, but it will be cached, so it doesn't take time to load on consequitve requests". This doesn't consider the fact that all code that is loaded needs to be evaluated by the browser before execution of any code. The older/more underpowered a device, the more noticable this becomes.
The workaround is loading on dependency, which we all now how that plays out, looking at the current frontend (hi and bye, RequireJS).

The upsides of using inline JS with HTML are:

  1. Isolation of components. Everything is there together with your HTML: CSS through Tailwind CSS and JS through AlpineJS. You don't need to search. You know where to debug.
  2. Only the JS that is needed is loaded. If the HTML is not being rendered, neither is the JS. This principle is very much in line with how Tailwind works.
  3. Performant, since you write the code specifically for this component, no methods are present that are needed for other use-cases. For example, when writing a generic slider JS file, many effects will be incorporated for fading, sliding, scrolling, text overlays, click handlers, bullet navigation, pagination and so on.
    With an inline JavaScript section right next to the HTML, only the methods that are incorporated are used in this component.
  4. Well written .phtml templates are isolated, which allows them to be replaced. They have no dependencies on inheritance or the page. Often, code can be decoupled with JavaScript events. You can move the messages bar anywhere you want, and it will still work. The same goes for the mini-cart/cart-drawer or the PDP price-boxes and galleries. They can be replaced by placing a single phtml file anywhere on the page.
    Hyvä UI is a component library (much like tailwindui.com) that offers out-of-the-box elements to be used in your Hyvä Theme. All elements are meticulously designed and carefully crafted into copy-and-paste components. You can find more about it here hyva.io/hyva-ui.html

All these factors combine and make the developer experience enjoyable and allow for really fast development.
It is definitely the way we want to build a frontend, and apparently, the same goes for many, many other Magento developers.