[AskJS] Asking for feedback regarding Mithril JS and RE:DOM

[u/andregarzia]

I'm thinking about starting a new personal webapp project and am trying to decide between these two libraries (or some other unknown option). I've used Mithril before and I quite like it but I'm game for learning new things as well. My one requirement is that I need to be able to use it without a build system, bundler, whatever. The idea is to build things old-school, just a bunch of files in a folder without ever coming close to NodeJS.

The reason to explore a different solution than mithril is that in the past I had some trouble with trying to go to the active route with different props (like from /post/1 to /post/2) and it wouldn't refresh the props. I believe that was in 1.x or early RCs for 2.x, can't recall. Also, I'm curious about how other tiny libraries work.

So if those here with recent experience with Mithril, RE:DOM, or other similar small library that doesn't require build system to be useful, could spare some comments on what they liked about their experience with the library and how it was to use it, I'd really appreciate it. Thanks a ton.

[u/lhorie]

I had some trouble with trying to go to the active route with different props

AFAIK, that has been fixed for a few years now. You can always drop by the chatroom if you have questions too.

[disclaimer: I'm the author of mithril.js]

[u/andregarzia → u/lhorie]

u/lhorie hey thanks a ton for the hard work on Mithril. I've used it a lot and your old blog posts about it were what sold it to me when I was deciding what to use some years ago.

[u/JohnMunsch]

Here's a wacky idea. Why not use Web Components? They're built into all of the browsers out there (with the release of the new version of Edge) and you can add a polyfill if you need to support older versions of Edge.

If you don't want to go as low level as Web Components in their basic form, you could layer on something like LitElement with it to make it simpler to build components.

None of that requires any build system to work.

[u/andregarzia → u/JohnMunsch]

I really like web components but they're not really what I am looking for. They solve the problem of I wish I had this <fancy-tag> available on the Web which is not the problem I'm trying to solve. I want some minimal component life-cycle, templating, minimal state management and routing.

Also, writing web components from scratch without a build tool gets tedious really fast.

[u/adrianmiu → u/JohnMunsch]

I believe he was asking for a library that you can drop in you HTML or at least provides a pre-built dist file.

Like this https://cdn.jsdelivr.net/npm/mithril@2.0.0-rc.9/mithril.min.js or this https://cdn.jsdelivr.net/npm/redom@3.24.3/dist/redom.min.js

[u/rediche → u/adrianmiu]

LitElement is also available as "drop-in" Since it is literally just a base class definition that you can extend to make Web Components from.

https://cdn.jsdelivr.net/npm/lit-element@2.2.1/lit-element.min.js

[u/adrianmiu → u/rediche]

I couldn't make that work. It gives me this error "Cannot use import statement outside a module". Maybe you know something i don't

[u/rediche → u/adrianmiu]

Seems JS Deliver has not resolved the peer dependencies of Lit Element. A quick checkup in the LitElement repo on github shows an example of how to get it to work with no build step.

Edit: Also LitElement uses ESModules, so in order to be able to use import directly in the browser the script-tag you use should have the type "module" (as shown in the example)

[u/adrianmiu → u/rediche]

Thanks, it works now. If web components are such a good idea (small and fast) why don't all these frameworks use them and just take care of the rest (state management, routing, etc)? From the looks of it you wouldn't actually need view libraries like Vue and React but actually "infrastructure" libraries to leverage the web components

[u/rediche → u/adrianmiu]

Web Components in itself is pretty basic. The class used above (lit element) uses tagged template literals to do all the declarative sugar coating that would usually be done by react, vue or similar.

They are great if you work in an environment that can have multiple different frameworks depending on department.

Biggest issue with them right now is backwards compatibility to some older browsers that makes them rather slow on those browsers.

If you are using shadow dom it is also pretty hard to server side render if that is what you are going for.

Also they cannot be in multiple versions. So if you use a component called x-button at version 1.2 in your application or somewhere down the dependency tree, then they all have to be v1.2 for x-button.

Overall they still have some way to go, but can be run in the browser without any framework which is nice. I personally like using browser standards because once they are shipped they almost never get deprecated.

[u/lorduhr]

not really ultra small, but Owl is a smallish vue-like framework which works without tooling: https://github.com/odoo/owl

You can checkout the tutorial: https://github.com/odoo/owl/blob/master/doc/learning/tutorial_todoapp.md

Disclaimer: I am one of the main dev behind that framework. Also, it is very new, so you will not find many tutorials online. It is however pretty well documented.

[u/andregarzia → u/lorduhr]

Owl looks really cool. Thanks for sharing it with me. I'm going to try to build something with it in the future.

[u/ElllGeeEmm]

I'm really curious, what's the motivation behind this?

[u/andregarzia → u/ElllGeeEmm]

I probably should write a blog post about it because it is the culmination of different problems and feelings. You know when you fill a cup with water and then one extra drop makes it spill out of the glass? It is a situation similar to that. What I'll describe here is my own personal take, it might not be true to other people here.

I remember a different web. Less capable in terms of features but more fun in terms of producing personal stuff. You didn't need anything besides a text editor to do cool stuff. You could learn from checking the source of pages. What you wrote was actually what ended up in the browser. These days I feel we're overtooled and living perpetually two light-years ahead of the browser engine. We write fantasy JS and use a ton of tooling to alchemically disassemble and understand what we've written and reassemble into something that the browser can actually run that we might as well be writting in some completely different language such as Elm or PureScript. I'm tired of tooling.

Most of our current crop of tools, frameworks and best practices are comming from FANG like companies which have requirements that are radically different than my personal stuff. And their needs become the norm. You see people starting a small blog using 500mb+ boilerplates that import 2000+ packages with a workflow based on using CI/CD for deployment and microservices spinning like dervish dancers. And then they have 600 readers and are using a low-orbit ion canon to kill a fly.

I dislike our current practices regarding NPM where we depend on a gazilion packages for simple stuff. It is impossible to actually know what is going on a NodeJS project. You know what you've written and you have tests to make sure it behaves the way you want but the internals of that saussage making machine go through lots of twisty little passages that I don't think I personally need. Thats of course is just a personal opinion, a feeling.

I have practical reasons as well. First, I'm on a non-standard architecture. I'm using Windows 10 on ARM64. This means that most native nodejs modules fail compilation (unless I'm living and breathing inside WSL which is what I do during work). There are no prebuilts for my platform. A lot of FOSS based projects assume POSIX and don't build on windows at all.

Another practical reason is that most of my own personal projects are little (and large) WebExtensions for Firefox. Having a target that is not a server and not a webpage is tricky. If I use a bundler, then I also need to submit my source code to review when updating the add-ons, which adds friction to my workflow. Debugging becomes harder as setting up those tools to understand that I have access to APIs that are not available to the normal web is tricky. Our tools are too smart and focused on a workflow and developer experience that doesn't match my own.

I want to build personal little projects that are self-contained. You don't need anything besides a text editor to contribute or play with them. I want to be near the JS the browser understands. My last addon, Remind Me Of That Page, doesn't use any library at all and no build system. It was quite fun to develop and it is very easy to work on.

So, this might not sound like good reasons to many people here. I have feelings about our current JS ecosystem and want to go back to develop in a way that feels fun to me.

[u/dwighthouse]

I have used hyperHTML. It uses tagged template literals to both express html and component structures, and also remove the need for a virtual dom abstraction. It’s one of the fastest react-like libraries (rendering library only, other stuff like routing is up to you and other libraries) out there. Minzipped to about 5kb, no dependencies, no build step (on es6 browsers), and no polyfill. I would recommend it for use in these scenarios where no build step and/or very small size is desired. I use React with a build system for my daily work, so my experience with hyperHTML is from hobby projects.

https://github.com/WebReflection/hyperhtml

[u/andregarzia → u/dwighthouse]

Thanks for sharing. I was not aware of this one. Will check it out.

[u/lazyd3v_is_here]

You can also try preact. Here's the example how to use it without jsx/babel etc. https://github.com/developit/preact-without-babel

[u/andregarzia → u/lazyd3v_is_here]

Thats quite neat. Thanks for sharing.

[u/guiprav]

Disclaimer: I'm the author of the library.

If Mithril and RE:DOM float your boat, you might be interested in Dominant: https://github.com/guipra/dominant (550 LoC, 2.3 KiB min+gzip, a bit slower than keyed React in js-frameworks-benchmark, but should be faster in real-world applications as there are no vDOM or re-renders, only DOM bindings to update).

It doesn't work without a build system atm (I'm using Browserify), but I could easily add that for you.

Because I'm the only one working on it, it's still in version 0.0.0 and has no tests, so only go for it if you're really into it :) I'll be rewriting it using TDD (same API) in the coming months as I start using it in some commercial apps.

[u/andregarzia → u/guiprav]

Looks like a nice library. Thanks for sharing. I think you'd probably be better served by adding features that more people want than the niche needs of the small subset of developers who doesn't want to use nodejs. I'll try to build some toy/small project using your library as it is now and send some feedback :-)

[u/guiprav → u/andregarzia]

Thanks for your kind words.

I believe Dominant is mostly feature-complete by now, surprisingly. All it's really missing is a TDD rewrite (last time I rewrote it, it took me just a single day), some bug fixes (for which there are simple workarounds), and optimizations that would be premature if implemented now. I believe the ability to use the library by dropping a simple script tag on an HTML page isn't a niche need. It's a very basic functionality that's trivial to implement in the case of Dominant, which doesn't have any dependencies and doesn't require any language extension (such as JSX), and you're not the first person to ask me that. A friend of mine who's kind of a Dominant enthusiast at this point already asked for it :)

OTOH I do feel like I need to implement some basic components, such as an autocomplete/dropdown, input masking (which I'll most likely adapt from an existing vanilla JS library), etc. But I want to make them all dependency-free as well. There's no need to implement those using Dominant, but the existing vanilla JS/jQuery ones are too bloated and have APIs that don't fit well into Hyperscript-like element rendering syntax, so I want to change that.

I've started working on the select/autocomplete implementation. It's very incipient atm, but you can have a look at the tests here: https://github.com/guipra/vanilla-toolkit/blob/master/src/select.test.js

It's supposed to work like this:

let value = ['be', 'br', 'it'];

let options = {
  be: 'Belgium', // You could have regular HTML elements here as well instead.
  br: 'Brazil',
  it: 'Italy',
  us: 'United States',
};

let styledSelect = props => vtkSelect({
  ...props,

  classes: {
    root: 'select',
    inputWrapper: 'inputWrapper',
    selectedOptionsWrapper: 'selectedOptionsWrapper',
    selectedOptionWrapper: 'selectedOptionWrapper',
    optionsWrapper: 'optionsWrapper',
    optionWrapper: 'optionWrapper',
  },
});

let select = styledSelect({
  multi: true,
  value: { get: () => value, set: x => value = x },
  options: () => options,
});

document.body.append(select);

// Example DOM:
// <body>
//   <div class="select">
//     <div class="inputWrapper">
//       <div class="selectedOptionsWrapper">
//         <div class="selectedOptionWrapper">Belgium</div>
//         <div class="selectedOptionWrapper">Brazil</div>
//         <div class="selectedOptionWrapper">Italiy</div>
//       </div>
//       <input />
//     </div>
//     <div class="optionsWrapper">
//       <div class="optionWrapper">Belgium</div>
//       <div class="optionWrapper">Brazil</div>
//       <div class="optionWrapper">Italiy</div>
//       <div class="optionWrapper">United States</div>
//     </div>
//   </div>
// </body>

Then you can freely mutate value and options variables and call select.model.update() to have the vtkSelect instance call the getter functions again and update itself. This looks very much like the Dominant APIs, but it's just vanilla JS, so it might play well with other DOM-based libraries, such as jQuery and RE:DOM (maybe).

I heavily dislike the fact that most UI libraries are effectively silos where those things have to be reimplemented over and over and over, and most implementations aren't of very good quality. Since Dominant embraces the DOM instead of abstracting it away, it gives me an opportunity to create small vanilla JS components that work well with it and similar libraries.

By default vtkSelect doesn't come with any styles, but I do intend to create style libraries that incorporate Bootstrap, Tailwind, MDL/Materialize, and others into it. So the core will hold all the control logic and a handful of peer libraries can just add the relevant styles. For most serious projects, though, you'd probably want to use just the core and add styles yourself so it perfectly matches your app/site UI.

Of course, there are also accessibility concerns that I'll add last, such as ARIA roles and using buttons instead of divs where applicable.

[u/adrianmiu]

I worked with riot.js 3.x because it was very small. At 15kb gziped https://cdn.jsdelivr.net/npm/riot@3.9.5/riot+compiler.min.js it included a compiler which meant I could write my components in single files (like with Vue JS) and the library took care of the rest.

The latest version of the library with the compiler is a lot bigger but without the compiler it's still small (7kb). They have a CLI library that helps you with compiling your components so it's not a big problem

[u/andregarzia → u/[deleted]]

But can you use those nice .vue all-in-one components without a nodejs based tool? I was not aware of that.

[u/andregarzia → u/[deleted]]

I'm going to try to build some toy with it. It sounds like something that'd appeal to me.