11 ms·
RE:DOM – Tiny turboboosted JavaScript library for creating user interfaces
- royjacobs 8y agoI can't comment on the quality of the library, but I did get a quick chuckle from the term "close to the metal" being used to describe a Javascript browser library.
- codeflo 8y agoI think very soon, "low-level programming" will mean writing JavaScript directly without a transpiler.
- jayflux 8y agoSoon? I’ve already seen that described as low level JS
- EGreg 8y agoObligatory XKCD (albeit about editors) https://www.xkcd.com/378 https://www.xkcd.com/378
- bdcravens 8y agoIt has been referred to as the "Assembly Language of the Web" https://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebSematicMarkupIsDeadCleanVsMachinecodedHTML.aspx https://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageF...
- JustSomeNobody 8y agoWhy Not? They appropriated “real time” already.
- pkstn 8y agoIt’s a bit of a joke, really ;) As well as ”turboboosted”. Don’t take them too seriously :D
- anonytrary 8y agoNo, it isn't. It's completely intentional marketing. That diction was specifically used to get people to think the library is better than other libraries.
- pkstn 8y agoBelieve me, I wrote the library ;)
- anonytrary 8y agoI'm aware of that, but the two aren't mutually exclusive. When your "jokes" make your library sound better than it is, it becomes marketing. Don't brush off your attempts to sell your library as a "joke".
- pkstn 8y agoFair enough, of course it’s marketing as well. But it’s so common to say ”blazing fast”. Even FB developers argued React being fast even though it used to be really slow.
- Vinnl 8y agoIt was fast compared to the primary framework in vogue back then (Angular.js v1).
- pkstn 8y agoIt actually wasn’t, they didn’t use key with ng-repeat in benchmarks. Even Angular 1 was actually faster back then when used correctly: https://500tech.com/blog/all/is-reactjs-fast https://500tech.com/blog/all/is-reactjs-fast
- Vinnl 8y agoThat post only invalidates* a specific measurement, but doesn't provide counter-measurements, especially not ones that say Angular.js was faster than React. Although I don't have alternative numbers, and will agree that VDOM comes with a performance penalty, Angular.js's method of change detection was pretty inefficient and required a lot of hand-holding. Still, I think either were sufficient for most use cases, and performance definitely isn't the main selling point for React (nor Angular.js). *Well, somewhat - it was still easier to shoot yourself in the foot, performance-wise, in Angular.js, but that's not really the point here, and React has its own issues there (e.g. `key`).
- fold_left 8y ago> I did get a quick chuckle from the term "close to the metal" being used to describe a Javascript browser library. This and "blazing fast" make me cringe every time.
- entelechy 8y agoFor better or worse, we are not far from "bare metal javascript" There is wasmjit [1] a kernel module that enables execution of webassembly via the linux kernel. Furthermore there is AssemblyScript [2] that allows to transpile typed javascript to WebAssembly [1] https://github.com/rianhunter/wasmjit https://github.com/rianhunter/wasmjit [2] https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript
- tengbretson 8y agoGood grief we've reached the point of a JS interpreter running in ring 0? Gary Bernhardt was a prophet. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- warent 8y agoWell, strictly speaking, WASM and JS are two different things, but basically yeah.
- megaremote 8y agoAll you need is a full operating system and a >100mb full compliant browser. Doesn't get much closer than that./s
- bigiain 8y agoYeah - I think the term "close to the metal Javascript" belongs to things like this: https://esp32.com/viewtopic.php?t=497 https://esp32.com/viewtopic.php?t=497
- lopatin 8y agoIt looks like the Element.update function is more or less the equivalent of setState in React. So the UI does seem to be declarative (you may want to emphasize this, at first it looked like a jQuery-like library). How does the declarative aspect of this work without a virtual dom?
- lopatin 8y agoAnswering my own question here: It's not the equivalent of setState as it doesn't set in memory state, but edits the dom directly when called.
- baybal2 8y ago> Because RE:DOM is so close to the metal and doesn't use virtual dom, it's actually faster and uses less memory than almost all virtual dom based libraries, including React (benchmark). Very well said. Author of "one very popular library" is plainly lying claiming that "Virtual DOM" was somehow faster than real DOM. That was never the case, even back in IE6 era, aside from very few and well known edge cases. Switch to Virtual DOM led to one of the biggest slowdowns in website performance.
- burlesona 8y agoIIRC the performance gain is when doing things like updating the state of a deep component tree, where react and others diff on the vdom to see what elements need to be re-rendered and then only so actual dom manipulation on those, rather than clear and re-render the entire tree. I’ll be honest, though, it feels to me like a solution to a hard problem you inflict on yourself by first committing to have the giant component tree rather than questioning if that was a great idea.
- baybal2 8y agoYes, you do not need to re-render the whole element tree, but you do not need that "Virtual DOM" to do that. It's truly is an "anti-solution" for the problem. Even back in "medieval" era when YUI was the king, the practice of making getter-setter pairs with direct control over DOM elements was recognised as a preferred practice over any kind of state machine controlled page re-rendering system. There of course was Angular.js - the prime target for React authors, against which all their claims held true.
- pitaj 8y agoYou have to have some ideas of what the state was before the change, and what changes need to be done to transfer states. In complex UIs, writing custom update logic for every change results in an unmaintainable mess and a large payload to the client.
- 8y ago
- aaaaaaaaaab 8y ago>closer to the metal Lol. Sure! Just like how I get closer to the Earth’s core if I’m sitting on the floor instead of my chair.
- pkstn 8y agoIt’s a bit of a joke.. ;)
- kowdermeister 8y agoThis idea of creating DOM with some API is not new and never really understood it. Just look at the login class, it's way more complex than plain HTML, hard to read and messes with .this. If you want DOM in your code, JSX is the way to go.
- pkstn 8y agoWith more complex project there’s benefits of having purely updatable components, the support of just native JS without quirks and knowing exactly what’s happening and when without black magic. But if course it always depends on the project which way is better.
- anonytrary 8y agoWith more complex projects, anything that isn't a declarative becomes painful to manage. In complex web-apps, the benefits of using a VDOM over imperative libraries like this far outweigh the extra O(N) memory consumption.
- pkstn 8y agoYou can make pure updates in RE:DOM. It’s developed for our digital signage system, and it’s really performant in a real world situations. It’s different than React though, that’s by design, since we needed more precise DOM handling.
- localvoid 8y ago> this far outweigh the extra O(N) memory consumption. Calculating memory overhead for vdom is actually pretty hard. With imperative code there will be several different code paths for initial rendering, updates and removal, and depending on the ratio of component instances per component type in the application, vdom can consume less memory because there will be less code and less code means that there will be less internal data for JIT. Also, if it is a highly dynamic application with high ratio of dynamic bindings per DOM element, and imperative library will wire all dependencies with direct DOM bindings in a huge dependency graph, it is much more likely that this graph will consume more memory, especially in use cases like filtering large lists.
- jtms 8y agoTry my new lib... here it is right here! document.createElement("div");
- kuroguro 8y agohttp://vanilla-js.com/ http://vanilla-js.com/
- oh_sigh 8y agoWhat's your library licensed as?
- bigiain 8y agoSurely you'd have to pick SSPL, to avoid the risk of Amazon getting rich off this innovative technology without contributing back to the community???
- minieggs 8y agoI've been using plain JavaScript more and more lately. Luckily Element.protoype has this nice property where if you attempt to read some setter functions it will throw, making it cake to implement a chainable createElement. Fun stuff, https://github.com/mini-eggs/ogle-tr-122b https://github.com/mini-eggs/ogle-tr-122b
- mr_toad 8y agoMost people get tired of the verbosity of createElement + appendChild + createTextNode, so they whip up a utility function, something like element(‘h1’, {class: “foo”}, “Chapter 1”) Then they add method chaining, support for event listeners, and various other bells and whistles. And that’s how new Javascript frameworks are born.
- anonytrary 8y agoNot having a VDOM is only a pro if your library maintains feature parity with libraries that have a VOM. Otherwise, you just lack whatever it is that VDOMs enable. This library seems to forget why view libraries use a VDOM. In this library, you have to write imperative update logic, which the VDOM specifically allows you to avoid. The VDOM is a slight performance hit most people accept in order to be able to write declarative code. In this case, I find it a bit misleading to pass off not having a VDOM as a pro. It's a bit like building a social media site with no users and claiming everyone should join because it doesn't have spam.
- giornogiovanna 8y agoIn my opinion the benefits of declarative GUI are vastly overstated for the average web app. Given that your application is appropriately componentized, it rarely makes things much clearer.
- pkstn 8y agoAgreed!
- guscost 8y agoThis sounds kinda like my little DOM component library: https://github.com/guscost/protozoa https://github.com/guscost/protozoa It’s a cool approach, and this one looks more fleshed out. But I’d still think in 2018 it’s almost always a premature/inappropriate optimization to forgo a virtual DOM, unless you’re doing something pretty far out there.
- JustSomeNobody 8y agoThat just sounds so... backwards to me.
- buremba 8y agoSeems similar to Backbone.js which was popular a looong time ago. Well, in fact, it's probably 4 to 6 years but it's a really long time for the front-end world. :)
- pkstn 8y agoNot much, really..
- Eli_P 8y agoHuh, one day I forked a part of RE:DOM called nodom[1], to use it in my library for rendering D3 charts in the background worker. I'd been extending nodom, and finally got working D3 in worker[2], sorry the pun. As I recall, nodom was pretty straightforwardly coded w/o magic and easy to extend, a nice library if you need to play with lightweight vdom. [1] https://github.com/ptytb/nodom https://github.com/ptytb/nodom [2] https://github.com/ptytb/d3-worker https://github.com/ptytb/d3-worker
- xtagon 8y agoIf manipulating the DOM directly is so much faster than using a virtual DOM, then why do libraries like React or Ember use a virtual DOM in the first place? I honestly though it was for speed.
- gpmcadam 8y agoIt depends what you mean by "faster". In some cases you'll be better off with something lighter and accessing the DOM directly. If you need to do something at scale, then you may choose React. The benefit here isn't from just something as simple as changing the items in a list or the text in a header, but when you need to have large amounts of state in an app that is represented by a complex DOM tree. The benefits of React here are that the virtual DOM can prevent unnecessary updates to the rest of the tree when your state change should only affect a nested element, for example.
- xtagon 8y agoThat makes sense. Thanks for explaining :-)
- localvoid 8y agoFull disclosure: I wrote a vdom library ivi[1]. Being fast is not just about micro updates, I think that most vdom authors don't care too much about micro updates performance because it isn't a bottleneck. For example, Virtual DOM with a powerful composition model can significantly reduce code size because composition gives you code reusability, and virtual dom is one of the most compact output formats to render/update DOM. 1. https://github.com/localvoid/ivi https://github.com/localvoid/ivi
- ng12 8y agoThe problem is it's very easy to write non-performant JS code if you're adding/removing/modifying lots of DOM elements, and attempting to do it performantly by-hand tends to lead to a lot of bugs. VDOM isn't performant in the sense that it modifies the DOM faster but in the sense that it allows you to write code that wouldn't be performant and have it execute efficiently. In React you worry about your data flow and component structure without needing to worry about DOM performance.
- ziont 8y agoi dont want to convert HTML into any other format...its like coffeescript. somebody is gonna pick up your code and they see all these el('h1','OMFG HN SUX'); instead of normal sane HTML. don't reinvent the wheel man.
- cpfohl 8y agoThis..._isn't_ converting HTML into any other format. It's providing an ergonomic way to generate elements in javascript. The alternative is directly using `myEl = document.createElement(...)` and `myEl.appendChild(...)`. and `myEl.src = 'whatever'`. You're comparing apples and dumptrucks here.
- ziont 8y agothats pretty much converting javascript into html and vice versa
- cfv 8y agoLoving it, built something similar a long time ago. Can you use it the other way around tho? Like, take an HTML string and return its RE:DOM representation.
- Zelphyr 8y agoCan anyone explain why you’d use this over just writing the HTML? This reminds me of the days when there were similar libraries in PHP and I could never find a use for them. It was easier and faster to just write the HTML.
- kreetx 8y agoFor those in the know on the internals of the topic library: is this like hyperHTML or lit-html in the way that it remembers the "holes" in the html so every update is just the update of live DOM at the right place?
- pkstn 8y agoCheck out my talk if you're interested in internals: https://www.youtube.com/watch?v=0nh2EK1xveg&t=410s https://www.youtube.com/watch?v=0nh2EK1xveg&t=410s ;)
- kreetx 8y agoHi and thanks for the link! I will definitely watch it, but may I ask if you know how the lit-html or hyper work? Reason I was asking was that all the vdom libraries maintain a virtual dom (behind the live dom) that they always recreate when the data changes (but this is cheap, since it's only a data structure), then they compare reconstructed virtual dom to the live dom and swap out only the new parts. And this way the browser only needs to re-render the new parts -- since the old ones didn't change. But the two other libraries I mentioned remember the "holes" in the html templates directly. So when the component gets new data, then the updated content is simply set as the value of these direct references into the live dom. This way (1) only the new parts are updated and thus re-rendered, but also (2) no virtual dom needs to be reconstructed. And this is why they are faster than the vdom libraries. So my question basically was, do you reconstruct the entire component tree too or not. But I guess I need to watch the video and read some code :)
- jillesvangurp 8y agoWe're actually using this. Re-dom is a very thin layer on top of the DOM. Basically all it does is hide some of the weirdness of that. The best way of using it is simply emulating what you would do in react (without jsx) in terms of design patterns. So you have component classes, with state, and a render method. Half of the success is just using good patterns like that. All redom does is allow you to create trees of elements and manage those. It has a few simple primitives for that. The main thing is a an el method that takes 3 parametes (maximum). The first is the element name, classes and id as a string. ".foo.bar" means a div with class foo and bar. "span.foo" means a span with class foo, and so on. The second (optional) one is an object with attributes. So if you have an a tag, you might want to pass in an object with an href, title, target, etc. The last parameter is either a string for text nodes, another element, or a list of elements. There are setAttr, setChildren, etc. methods you can call on elements. There are mount/unmount methods and there is some syntactic sugar for managing lists. That's about it. You can shoot yourself in the foot (just like with other frameworks) but otherwise this works as advertised. Mostly there is not a lot of magic happening in terms of expensive stuff.