Live data from Hacker News

RE:DOM – Tiny DOM library

redom.js.org

51–60 of 84 posts

Re: RE:DOM – Tiny DOM library

#51

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…

Check out my other project as well: https://frzr.js.org - it's quite similar but with a bit easier syntax :)

Re: RE:DOM – Tiny DOM library

#52
post #47
post #38

RiotJS 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.

>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 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

#53
post #24

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…

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).

[deleted]

Re: RE:DOM – Tiny DOM library

#54
post #52
post #47

Earlier 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…

Vue is great as well! I like to know how things work also under the hood, so debugging/profiling on every level is much easier.

Re: RE:DOM – Tiny DOM library

#57
post #20

There 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.

Check out FRZR: https://frzr.js.org – RE:DOM is all about experimenting with ES2015. And actually the whole core of both projects are ES5 – you don't have to use the new syntax.. ;)

Re: RE:DOM – Tiny DOM library

#59

Why 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 are creating HTML from within Javascript because:

- 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.

Post reply on HN