Alternative lightweight UI library to modern day frameworks
1–10 of 73 posts
Re: Alternative lightweight UI library to modern day frameworks
#2We shipped a very major product (300 person company) on Mithril.js a few years back when React was young and Angular was the go-to in this space.
We had a fairly positive experience, but ran into enough problems here and there with vdom rendering bugs that we eventually decided to rewrite the entire product 4 years later in React.
Certainly, it did was it was supposed to very well, until we really pushed it to its limits with vdoms that were complex and mutating in real time. Then we broke it non deterministically and couldn't reliably reproduce the issues that we were having each time for a solid bug report. Couldn't really even reproduce them consistently in production, they would just happen in random places.
Re: Alternative lightweight UI library to modern day frameworks
#3We shipped a very major product (300 person company) on Mithril.js a few years back when React was young and Angular was the go-to in this space. We had a fairly positive experience, but ran into enough problems here and there with vdom rendering bugs that we eventually decided to rewrite the entire product 4 years later in React. Certainly, it did was it was supposed to very well, until we really pushed it to its li…
Any chance you remember what those bugs resulted in? I’m dealing with the same scenario for work where I’m using Mithril and have been wondering if what I’m seeing is due to my usage or the library itself. I do love the library and its community but I’ve run into some crazy ui issues, especially when using keyed nodes, that I’ve never seen with the more mainstream vdom options I’ve worked with.
Re: Alternative lightweight UI library to modern day frameworks
#4We shipped a very major product (300 person company) on Mithril.js a few years back when React was young and Angular was the go-to in this space. We had a fairly positive experience, but ran into enough problems here and there with vdom rendering bugs that we eventually decided to rewrite the entire product 4 years later in React. Certainly, it did was it was supposed to very well, until we really pushed it to its li…
I have been using Mithril.js for a while and never ran into problems, but admittedly I only used it for small, personal project.
What I liked about Mithril was its simplicity: a clean API with a handful of methods but batteries-included at the same time, and very easy to learn, too!
Eventually I decided to write my own micro framework which borrows heavily from Mithril in terms of api design and approach (https://h3.js.org) -- basically, like Mithril, it comes with its own Virtual DOM implementation, hyperscript syntax (imho the best way to write a view, once you get used to it), a minimal router but also more obvious ways to manage local and global state.
Yeah, I am not even thinking about competing with React or other frameworks, as long as it works for me. I have learnt more building a micro framework from scratch about how single page application work than from using React or Angular and constantly checking stack overflow and other docs to make sure I was doing stuff "in the right way".
I would however be curious at what are the limits of such frameworks. Real-time dom updates... depends how complex I guess, and how fast. It would be nice to have a way to benchmark this properly...
Re: Alternative lightweight UI library to modern day frameworks
#5If you want to try mithril in a mid-sized project, sure do it, cause it is a nice, free as in freedom library to render vdoms without imposed opinion on how to manage state. But be aware that it has no error handling around view() method and any error thrown from there will irreversibly break mithril internals everywhere on the page, this is by design. Second thing, I didn’t push it to the limit as another commenter, but massive vdoms (many tens of thousands of vnodes) are slow to even rebuild and compare, so you’ll have to use lazy techniques described in docs. It is not exclusive to mithril, but worth knowing. Otherwise, mithril is basically a core vdom tech similar to vue and/or react, wish these two had their render cycles as separate packages. Also, if someone knows a cheap way to turn react into mithril’s spirit, e.g. via light setState-detaching layer, please share.
Re: Alternative lightweight UI library to modern day frameworks
#6If you want to try mithril in a mid-sized project, sure do it, cause it is a nice, free as in freedom library to render vdoms without imposed opinion on how to manage state. But be aware that it has no error handling around view() method and any error thrown from there will irreversibly break mithril internals everywhere on the page, this is by design. Second thing, I didn’t push it to the limit as another commenter,…
> but massive vdoms (many tens of thousands of vnodes) are slow to even rebuild and compare
Sounds like a terrible user experiance? Would you mind educating me on an appropriate scenario where you may need tens of thousands of vnodes?
Maybe large unpaginated tables? A chat panel where you have scrolled through a large history?
Even if a framework like React can handle that many nodes, surely there must be better ways of handling the requirement. I'm not sure a user can actually consume tens of thousands of dom nodes.
Re: Alternative lightweight UI library to modern day frameworks
#7We shipped a very major product (300 person company) on Mithril.js a few years back when React was young and Angular was the go-to in this space. We had a fairly positive experience, but ran into enough problems here and there with vdom rendering bugs that we eventually decided to rewrite the entire product 4 years later in React. Certainly, it did was it was supposed to very well, until we really pushed it to its li…
I would realy love to know what problems you faced?
Maybe they've been fixed, or are there are genuine scalability problems?
Re: Alternative lightweight UI library to modern day frameworks
#8If you want to try mithril in a mid-sized project, sure do it, cause it is a nice, free as in freedom library to render vdoms without imposed opinion on how to manage state. But be aware that it has no error handling around view() method and any error thrown from there will irreversibly break mithril internals everywhere on the page, this is by design. Second thing, I didn’t push it to the limit as another commenter,…
> but massive vdoms (many tens of thousands of vnodes) are slow to even rebuild and compare Sounds like a terrible user experiance? Would you mind educating me on an appropriate scenario where you may need tens of thousands of vnodes? Maybe large unpaginated tables? A chat panel where you have scrolled through a large history? Even if a framework like React can handle that many nodes, surely there must be better ways…
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 much data remained unmanaged and how structured the right side was in the middle of experiments.
surely there must be better ways of handling the requirement. I'm not sure a user can actually consume tens of thousands of dom nodes.
We tried windowing the data, but that simply moved delays to operators. They don’t consume it all at once, but they have to detect groups by using “natural intelligence”. The fixed process that spans multiple entities and liabilities wouldn’t allow to automate it further. Sometimes it’s what it is, welcome to real world business complications. As I said, it’s not mithril’s fault at all, but something to consider if you have to.
Re: Alternative lightweight UI library to modern day frameworks
#9If you want to try mithril in a mid-sized project, sure do it, cause it is a nice, free as in freedom library to render vdoms without imposed opinion on how to manage state. But be aware that it has no error handling around view() method and any error thrown from there will irreversibly break mithril internals everywhere on the page, this is by design. Second thing, I didn’t push it to the limit as another commenter,…
> but massive vdoms (many tens of thousands of vnodes) are slow to even rebuild and compare Sounds like a terrible user experiance? Would you mind educating me on an appropriate scenario where you may need tens of thousands of vnodes? Maybe large unpaginated tables? A chat panel where you have scrolled through a large history? Even if a framework like React can handle that many nodes, surely there must be better ways…
I work on such doms regularly. A virtually paginated tablewould render around 100 rows. 20 columns means rendering 2K vnodes for the plainest of cells. If a few of those columns render small charts it can easily add upto 100k.
Re: Alternative lightweight UI library to modern day frameworks
#10We shipped a very major product (300 person company) on Mithril.js a few years back when React was young and Angular was the go-to in this space. We had a fairly positive experience, but ran into enough problems here and there with vdom rendering bugs that we eventually decided to rewrite the entire product 4 years later in React. Certainly, it did was it was supposed to very well, until we really pushed it to its li…
Any chance you remember what those bugs resulted in? I’m dealing with the same scenario for work where I’m using Mithril and have been wondering if what I’m seeing is due to my usage or the library itself. I do love the library and its community but I’ve run into some crazy ui issues, especially when using keyed nodes, that I’ve never seen with the more mainstream vdom options I’ve worked with.
Mithril contributor here (former maintainer).
I've been out of the loop for a while, I'm getting back to it, and if you've discovered a keyed diff bug I'd love to hear about it.
Feel free to hop into the gitter chat (https://gitter.im/mithriljs/mithril.js) to explore the problem, or to file an issue if you're sure the bug is ours.