Live data from Hacker News

Alternative lightweight UI library to modern day frameworks

mithril.js.org

31–40 of 73 posts

Re: Alternative lightweight UI library to modern day frameworks

#31

I’d like to use a simple front end library that doesn’t use a vdom, doesn’t require a special state system, doesn’t require special compilation, is performant, and largely gets out of my way. I currently use Preact and am pretty happy with it, even though it doesn’t check most of those boxes. Is there something that does? Anyway, Mithril looks nice. I’ve kicked the tires a few times, but comments like the ones here i…

There's Svelte, that matches most of your requirements, but unfortunately does require a compilation step. Since I'm a backend dev, I've been looking for a straight-forward library to use for my next project and found this. I haven't yet used it on a project though https://svelte.dev/

How long does compilation typically take?

Re: Alternative lightweight UI library to modern day frameworks

#32
post #18

Earlier quoted context omitted.

"Alpine.js offers you the reactive and declarative nature of big frameworks like Vue or React at a much lower cost. You get to keep your DOM, and sprinkle in behavior as you see fit... Alpine doesn't use a virtual DOM. This implementation allows Alpine to stay rugged and use the real DOM to work its magic" https://github.com/alpinejs/alpine

I’ve seen Alpine, and it is interesting, but another bullet point in my wish list is vanilla JS; no new template language. JSX is just a small bit of sugar on top of vanilla JS, in my mind, so it is acceptable.

From the brief glance I've taken at Alpine I didn't think it did have a template language - unless you refer to it's use of custom html attributes?

Re: Alternative lightweight UI library to modern day frameworks

#33

I’d like to use a simple front end library that doesn’t use a vdom, doesn’t require a special state system, doesn’t require special compilation, is performant, and largely gets out of my way. I currently use Preact and am pretty happy with it, even though it doesn’t check most of those boxes. Is there something that does? Anyway, Mithril looks nice. I’ve kicked the tires a few times, but comments like the ones here i…

There's Svelte, that matches most of your requirements, but unfortunately does require a compilation step. Since I'm a backend dev, I've been looking for a straight-forward library to use for my next project and found this. I haven't yet used it on a project though https://svelte.dev/

Svelte with Snowpack does compilation in milliseconds.

Re: Alternative lightweight UI library to modern day frameworks

#34
post #24

Right now Next.js might be the hottest front end framework but I'm looking for something simpler to build SPA's. I'm not interested in SSR or SSG at all. Mithril.js looks very promising as it provides you with everything you might need to build a simple web app out of the box. The only other frameworks that do that is Angular and Ember, but they're both declining in popularity especially Ember. On the other hand Reac…

Vue and Svelte are both good. I'm not sure why create-react-app is a problem, but Vue can run without any scaffolding. I think it's worth just accepting that some scaffolding is needed for bundling, transpilation, etc. There are dozens of alternatives like mithril - small in size, scope and community. You might miss a system for managing state in Mithril, as well as pre-built component libraries like Vuetify or react…

I tried out Svelte recently. I really like the idea of a 'compiler first' framework which offers useful features that compile away to plain old lightweight JavaScript. I got on ok with the bare-bones Svelte compiler, but I found the surrounding ecosystem to be lacking.

There are two different material design libraries for Svelte. [0][1] I wasn't able to get either of them to behave. It looked like they weren't being kept up to date with Svelte, or else the documentation was inadequate.

I then gave Angular a go, and encountered no such issues. Angular has the added bonus that its material design library [2] is very mature and well polished.

[0] https://smeltejs.com/

[1] https://sveltematerialui.com/

[2] https://material.angular.io/

Re: Alternative lightweight UI library to modern day frameworks

#35
post #17

Earlier quoted context omitted.

Humongous DOMs eventually stop scaling even without any javascript on the page (e.g. look at how long it takes to load the ecmascript spec), so it's definitely important to account for DOM size early in design. With that said, for mithril specifically, there are a few different techniques that I've heard people use to avoid overly slow diff times: - design changes (search, filtering, pagination, etc) - occlusion cull…

Agreed. Charts and large SVGs, etc are generally best rendered independent of the vdom. I’ve seen React and Preact both crawl under similar setups, so this isn’t a knock on Mithril, albeit it does appear that Mithril is a bit slower than Preact with large diffs.

For large immutable DOM trees like CSS-stylable SVG graphics, I've seen people use m.trust, which makes the diff of the entire SVG tree as cheap as a single string comparison.

For complex charts, I think deferring to something like d3 might make more sense than a vdom based implementation since d3 provides better domain-specific APIs.

Re: Alternative lightweight UI library to modern day frameworks

#36
I used to use mithril for almost every new project I'd start, but I've switched over to using React w/ Hooks for just about everything for two main reasons:

- toolchain support is a lot less finicky and better supported (you can use parcel and it "just works") - should I need to bring in a obnoxious third party library, it's far more likely to exist in a react world than mithril

If you're just building something small / on your own, mithril is definitely worth a shot though, it's relatively pleasant to use and packs in some very handy XHR related helpers

Re: Alternative lightweight UI library to modern day frameworks

#38
post #17
post #8

Earlier quoted context omitted.

It was a master-detail “form”, rich-formatted financial records in the left pane and svg-heavy graphs for attributing records to edges on the right. Already heavily filtered on both sides, and required to be navigatable without constantly changing subfilters. Estimating, every left row could consist of 15-20 vnodes and every graph of around 50+ min. I think I’ve seen 12-15k vnodes on average day, depending on how muc…

Humongous DOMs eventually stop scaling even without any javascript on the page (e.g. look at how long it takes to load the ecmascript spec), so it's definitely important to account for DOM size early in design. With that said, for mithril specifically, there are a few different techniques that I've heard people use to avoid overly slow diff times: - design changes (search, filtering, pagination, etc) - occlusion cull…

occlusion culling

Yes, good old model-(controller implements datasource)-view-cellview from any native toolkit. Sadly, to implement that in html, which doesn't have any primitives for it, means that you have to combat both NSScrollView/GtkScrolledWindow from scratch and html/css complexity. That alone is a project much bigger than some enterprise fintech toy I'll ever dare to approach. Maybe some day web will reinvent native cells and cell-rendering containers, who knows.

islands

Hmm, this sounds interesting, thanks for the cue!

Re: Alternative lightweight UI library to modern day frameworks

#39

Does Mithril include state management? I see it’s being compared to Vue + VueX but I didn’t see other mentions of state management on the linked page.

It’s left up to you. POJOs work just fine in Mithril, but you can use any of the existing libraries (Redux, Mobx, etc) too if you want.

Re: Alternative lightweight UI library to modern day frameworks

#40
I’ve never used Mithril but in looking over this it seems very similar to a small library I wrote myself, especially with regards to routing and the use of # in the URI. I think solutions to certain problems are universal and the way we implement those solutions is the interesting part. Of course my library was never optimized for large-scale DOM mutations or other such real-world issues, but it’s always fascinating to see someone develop similar solutions. So why did I even write my own library? It was more out of curiosity than need. I also like to understand how “magical” things work, and for me, the best way to understand something is to try to do it myself, even if I don’t end up fully completing whatever “it” is. Discovery is a powerful benefit that I feel modern software engineering doesn’t provide as much as it used to.
Post reply on HN