Earlier quoted context omitted.
angle brackets ,we decided long time ago we hate those :)
No we didn't, considering a lot of us write JSX at our jobs.
Both can be true - they certainly are in my case.
RE:DOM – Tiny DOM library
71–80 of 84 posts
Re: RE:DOM – Tiny DOM library
#72Re: RE:DOM – Tiny DOM library
#73Earlier quoted context omitted.
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.
Why did you wrap that in a closure / immediately invoked function expression?
It's a way of hiding local variables. Old "var" variables are function scoped, so you can't even hide them in if-blocks or for-blocks, which makes scope leakage even worse.
If you're a JS programmer you should definitely read Crockford's famous JS book, it explains a lot of JS patterns and the rationale behind them.
Re: RE:DOM – Tiny DOM library
#74Earlier quoted context omitted.
el.email = { document.createElement('input'), ...{ type: 'email' }}
What supports this feature and how is it implemented?
The ... is the spread operator: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: RE:DOM – Tiny DOM library
#75Earlier quoted context omitted.
Why not use one of the dozens of templating libraries?
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 le…
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
Re: RE:DOM – Tiny DOM library
#76Why the indirection creating types using el()? Why not create the nodes directly with el()?
check out frzr.js.org - I'm using that aproach there..
Re: RE:DOM – Tiny DOM library
#77Why 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.
Toggling visibility (and other stuff) is best done by changing classes on the element.
Re: RE:DOM – Tiny DOM library
#78Let'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.
Re: RE:DOM – Tiny DOM library
#79Earlier quoted context omitted.
el.email = { document.createElement('input'), ...{ type: 'email' }}
What supports this feature and how is it implemented?
(Too long to edit my other reply)
Also used was object destructuring: http://odetocode.com/blogs/scott/archive/2014/09/11/features...
Re: RE:DOM – Tiny DOM library
#80Earlier quoted context omitted.
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.
Toggling visibility (and other stuff) is best done by changing classes on the element.
I think you should consider the trade-off.
If you toggle visibility with CSS, you still have to put everything in the DOM. Sometimes, putting things in DOM can be very expensive. Consider a date picker, a fairly complicated thing with many sub-elements. If you have to put thousands of date pickers in the dom, that's going to take a lot of time. Especially if the user only sees one if they click on an event to edit it.