I'm torn. On the one hand this seems far too clever for it's own good and in the same vein as coffeescript where it's really easy for you to write efficient & compact code which somehow turns into complete garbage when you try to read it two weeks later. On the other hand it looks super neat, has 0 dependencies and looks like React but without requiring any kind of build system. I think I might need to try it in a si…
RE:DOM – Tiny DOM library
51–60 of 84 posts
Re: RE:DOM – Tiny DOM library
#52RiotJS lets you keep the "normal" HTML and just add easily-called functions. Looks much more simple and "normal" to me than all this react stuff and HTML generation from javascript.
Riot is great, I'm one of the contributors also. Just like to experiment with things and created FRZR, RZR and now this. The main issue with Riot is, that it's still rather slow. And complex, if you want to understand 100% how it works under the hood.
Riot is fantastic, especially in anticipation of web components, but personally I don't see performance as the main issue; I'm willing to trade performance for syntax I like, and the areas where Riot tends to choke are generally on tasks I typically wouldn't ask of client-side JS, no matter how fast it was.
It's the lack of certain critical features that kills it for me. The biggest one is that is has no Vue-style transition system for "if" and "show" -- there are plugins that do it strictly for mount and unmount. It's an outstanding question in #1858, though it might be outside the scope of Riot core, TBH.
In any case, I moved to Vue for that reason, and like it a lot, though I'd still prefer a Riot-with-easy-transitions :)
Re: RE:DOM – Tiny DOM library
#53I'm torn. On the one hand this seems far too clever for it's own good and in the same vein as coffeescript where it's really easy for you to write efficient & compact code which somehow turns into complete garbage when you try to read it two weeks later. On the other hand it looks super neat, has 0 dependencies and looks like React but without requiring any kind of build system. I think I might need to try it in a si…
If you're looking for a very small (~10K), dependency-free alternative to react, check out http://mithril.js.org/ , which is far more powerful and from which it seems this project has taken some inspiration (mount, props, and the general syntax are a few of the similarities I see).
Re: RE:DOM – Tiny DOM library
#54Earlier quoted context omitted.
Riot is great, I'm one of the contributors also. Just like to experiment with things and created FRZR, RZR and now this. The main issue with Riot is, that it's still rather slow. And complex, if you want to understand 100% how it works under the hood.
>The main issue with Riot is, that it's still rather slow.. Riot is fantastic, especially in anticipation of web components, but personally I don't see performance as the main issue; I'm willing to trade performance for syntax I like, and the areas where Riot tends to choke are generally on tasks I typically wouldn't ask of client-side JS, no matter how fast it was. It's the lack of certain critical features that kil…
Re: RE:DOM – Tiny DOM library
#55Still i don't understand why people writing simple HTML in complex way!
Re: RE:DOM – Tiny DOM library
#56There is a trend in javascript community to use es2015 for everything and sometimes developers forget to keep a very fragile balance between expressiveness and simplicity.
Re: RE:DOM – Tiny DOM library
#57There is a trend in javascript community to use es2015 for everything and sometimes developers forget to keep a very fragile balance between expressiveness and simplicity.
Re: RE:DOM – Tiny DOM library
#58Unreadable.
Re: RE:DOM – Tiny DOM library
#59Why are we creating HTML from within Javascript? It would be much better to use HTML for that and simply toggle the display/visibility of DOM elements via CSS or JS.
- We want to generate HTML from our data (eg. database) - We want an interactive experience (eg. with toggling visibility)
You could argue that we should generate the HTML on the backend, but then you are still generating HTML, and now you have two systems that interact with the HTML instead of one.