
RE:DOM – Tiny DOM library - pkstn
https://redom.js.org
======
ams6110
Honest question, how is:

    
    
      el.email = input(props({ type: 'email' }))
    

better or easier than:

    
    
      <input type="email">
    

I think the example needs to be more compelling.

~~~
zachrose
I assume you mean to compare it to:

    
    
        el.email = (function(){
            var input = document.createElement('input');
            input.type = "email";
            return input;
        })();
    

...or something similar. Your could also use createContextualFragement or a
little function that uses innerHTML, both of which parse a string into HTML
(which is problematic). Or you could use a templating library, of which there
are many and this is one.

~~~
ars
Why compare it to that? There is no reason to avoid innerHTML anymore - it's
not slow at all.

There is rarely a reason to build HTML using createElement, it's only
sometimes needed. The majority of the time just write HTML - it's much easier.

> Or you could use a templating library

Or just use the built in <template> tag.

~~~
exomancer
Not slow compared to what? Creating elements with the DOM API is faster than
innerHTML roughly by a factor of 4 on Chrome Canary last I benchmarked it, DOM
mutations with bindings are even faster. There is a reason why React switched
from innerHTML to generating DOM.

~~~
localvoid
>Creating elements with the DOM API is faster than innerHTML roughly by a
factor of 4 on Chrome Canary last I benchmarked it

yes, almost by a factor of 4 :D

check out "render" test cases:

[https://cdn.rawgit.com/localvoid/dd96890b82f1d1268df34330b14...](https://cdn.rawgit.com/localvoid/dd96890b82f1d1268df34330b14c82a3/raw/aa03b789315a84dba047c642e7ab63fc04017692/uibench_chrome.html)

------
outsidetheparty
Let's see: website consists in its entirety of two not-very-illuminating code
samples. The documentation on github consists of the phrase "Documentation is
a bit lacking yet, please check out the source for now."

I feel like at this point, when there are so many, so so many, javascript
frameworks to choose from, if you're going to build yet another one you need
to take the time to explain why it exists. What are the advantages of this
approach over the many existing alternatives? What problem does it solve? What
does it do that others don't? What motivated its creation? Why should someone
use this instead of riot or vue or knockout or transparency or $dom or snack
or xui or or domtastic or crel or DOMinate or shaven or scriber or zepto or
react or jquery or good old vanilla?

Maybe I'm just getting old and cranky (ok definitely I am that) but if someone
can't be bothered to document their own code and expects others to dig through
the source to figure out what it's for and how to use it, my default
assumption is that the code itself is going to be similarly slipshod.

~~~
pkstn
To be honest, I just wanted feedback about the experimental approach.. It's
only version 0.0.x

------
tjallingt
I've never seen this before:

    
    
        children(el => [
          el.email = input(props({ type: 'email' })),
          el.pass = input(props({ type: 'pass' })),
          el.submit = button(text('Sign in'))
        ])
    

Can someone explains what this does and why it is used here? As i understand
it this function both modifies the `el` object (whatever that is) and returns
an array containing the input elements, but why would you want to do both
those things at the same time?

~~~
emilsedgh
That is an arrow function.

children() is supposed to take a function as argument and that function is
supposed to return the list of children.

So basically:

children( function(el) {

    
    
      return [
    
        el.email = input(props({ type: 'email' })),
    
        el.pass = input(props({ type: 'pass' })),
    
        el.submit = button(text('Sign in'))
    
      ]
    

} )

Also,

[

    
    
       el.email = input(props({ type: 'email' }))
    
       ,
    
       ...
    

]

is a neat idea. In one (expressive) line he is assigning the value to the
array and also giving the child (in this case, email) a name and reference in
its parent, so later he can just call el.email (in the onsubmit function).

~~~
pkstn
Yeah, I'm using similar technique with FRZR as well
([https://frzr.js.org](https://frzr.js.org)), but with RE:DOM I wanted to
experiment with ES2015 and also break the API to smaller parts, which you can
replace with your own if you like..

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

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

~~~
flukus
Why not use one of the dozens of templating libraries?

~~~
emn13
Because templating languages are without exception bug-breeding grounds that
no human being can actually use without producing errors, which the browser
then sometimes proceeds to auto-correct (html being html), which leads to a
kind of "approximate" programming style, aka nirvana for security holes and
other bugs. Oh, and composition is terrible pain too, encouraging over-complex
UI components that do it all. And learning whatever flavor cleverly-
insufficient control-flow and looping constructs this templating library uses
is a pointless waste of time (and source of bugs) too.

Why in the heavens would you _ever_ choose to use a templating library and
blur the lines between content (user input) and UI structure? Why reinvent the
control-flow wheel?

Templating represents programmers realizing that this newfangled browser thing
can already parse HTML, and hey, can't we do something clever with that -
sure, if we unnecessarily serialize to a string first, yes! No thank you.

~~~
akst
I straight up prefer templating for ergonomic reasons, especially when I see
someone inlining higher order functions & JS control flow structures in a HTML
DSL.

But I can sympathise with where you're coming from, as I have not so fond
memories of backbone + [insert templating library]. A lot the problems can be
addressed through better tools & a pre compilation stage where the templates
are transformed into JS & data input are escaped for security reasons. One
example of this is Ember.js's HTMLbars which address basically all of what you
just listed there.

edit: That said if for whatever reason I couldn't use Ember, I'd probably
choose some flavour of JSX over most other templating libraries, lol

------
rajangdavis
Reminds me little bit like Mithril...

Edit: Not sure why I got downvoted, but if you look at the Mithril API (sample
code on [http://mithril.js.org/](http://mithril.js.org/)), it's very similar
to this RE:DOM library with the major difference being that there is a
controller function in the Mithril example and that Mithril is more of a
functional language.

------
lexicality
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 side project.

~~~
jonahx
If you're looking for a very small (~10K), dependency-free alternative to
react, check out [http://mithril.js.org/](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).

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

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

~~~
tribby
>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 :)

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

------
awalGarg
There is hyperscript which is a bit more "mature":
[https://github.com/dominictarr/hyperscript#example](https://github.com/dominictarr/hyperscript#example)

There is virtual-hyperscript which ports the above to virtual-dom:
[https://github.com/Matt-Esch/virtual-
dom/tree/master/virtual...](https://github.com/Matt-Esch/virtual-
dom/tree/master/virtual-hyperscript)

I made a similar-ish "library" about an year ago:
[https://gist.github.com/awalGarg/8a0e18c6fe87456d885f](https://gist.github.com/awalGarg/8a0e18c6fe87456d885f)

And there are all sorts of similar DSLs you can find on npm/github for JS. In
a bit less time, you can write your own. In even lesser time, you can just do
what you used to do prior to all this. This does however seem like a pretty
popular idea in the JS community which keeps getting "discovered" every now
and then.

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

~~~
pkstn
Check out FRZR: [https://frzr.js.org](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.. ;)

------
TazeTSchnitzel
I've made a similar sort of DOM DSL:
[https://github.com/TazeTSchnitzel/jInsert](https://github.com/TazeTSchnitzel/jInsert)

e.g.

    
    
      document.body.appendChild($('form', {action: '/submit', method: 'POST'}, [
          $('input', {type: 'text', name: 'username'}),
          $('br'),
          $('input', {type: 'password', name: 'password'}),
          $('br'),
          $('input', {type: 'submit'})
      ]));
    

RE:DOM looks cool too.

Since using Haskell's Blaze, I've wanted something close in other languages.

------
chuangbo
Good try. Although jQuery chaining api seems better for me.

------
RubyPinch
is there any compile-to-javascript languages which would be termed as
"disgusting" and "impure"?

[https://github.com/dropbox/pyxl](https://github.com/dropbox/pyxl) for python
comes to mind as something more enjoyable than manually doing tree-shaped OOP

    
    
        login = : //"read variable from indented block" symbol of magicness
            <form>
                <input type=email>
                <input type=pass>
                <button>{_("Sign in")}<button> //gotta have an excuse to inline code!
            </form>
        login.events({
            onsubmit (whatever, i dunno) {
                blap
            }
        });
    

seems a lot more fun!

------
snehesht
the website's UI looks great. simple and to the point.

------
amelius
Why the indirection creating types using el()? Why not create the nodes
directly with el()?

~~~
pkstn
check out frzr.js.org - I'm using that aproach there..

------
tasnimreza
Still i don't understand why people writing simple HTML in complex way!

~~~
pkstn
When you're writing a large application, things can get quite complicated with
just HTML..

------
korynunn
Shameless plug:
[https://www.npmjs.com/package/crel](https://www.npmjs.com/package/crel)

~~~
tasnimreza
From the page >Writing HTML is stupid. It's slow, messy, and should not be
done in JavaScript.

What a bold statement !

------
ingenter
I had a similar attempt.

[http://m1el.github.io/jsonht.htm](http://m1el.github.io/jsonht.htm)

------
aurelianito
Why is this better than working with d3 selections?

------
daviddahl
Nice! reminds me of hyperscript-helpers

------
codedokode
Unreadable.

~~~
pkstn
Try my other project, FRZR: [https://frzr.js.org](https://frzr.js.org) –
RE:DOM is more of an experiment in this point..

