[HN Gopher] VanillaJSX.com
___________________________________________________________________
VanillaJSX.com
Author : novocantico
Score : 71 points
Date : 2024-08-16 19:01 UTC (3 hours ago)
(HTM) web link (vanillajsx.com)
(TXT) w3m dump (vanillajsx.com)
| arjvik wrote:
| What benefit does the virtual DOM add?
| spoiler wrote:
| DOM interactions (read, writes) are synchronous, they're very
| slow, and it must happen on the main thread. This can cause the
| browser tab to freezing if access and updates aren't carefully
| "curated" (ie you don't want to read-check-then-write in a
| tight loop; or even write too often, even if it's the same
| value).
|
| It can also simplify some stuff surrounding event handling (but
| that's not it's main goal I think)
|
| So people wrote various ways to defer/batch/denounce updates.
|
| Virtual DOM is a general solution/implementation. It's not the
| only one, but I think you always need at least a tiny runtime
| to avoid too much DOM access (ie Svelte, Solid JS are fairly
| minimal)
| samwillis wrote:
| The virtual dom makes implementing a declarative templating
| system easer, and declarative templates are easer for a
| developer to reason about, and less error prone, than having to
| mutate the dom directly.
|
| People often mistakingly describe the vdom as faster than the
| dom, this is incorrect. It would be faster than throwing away
| the whole components dom and rebuilding, so the same templating
| code building a new dom, rather than a vdom that's then diffed.
| Hand crafter mutations will be faster than a vdom diff, simply
| because the computer is doing les work, however much more error
| prone.
| edflsafoiewq wrote:
| It enabled a style of view library where you write immediate-
| mode type code that always recreates a whole component from
| scratch, versus having to write finicky code that both creates
| and then updates pieces of the page as state changes (dirty
| tracking, etc). Behind the scenes, you're creating the vDOM
| from scratch, which is diffed against the actual retained-mode
| DOM, and then only the pieces that are different are updated.
| ProofHouse wrote:
| Slows down your app too, sometimes. Depends how well you can
| work with and mutate a DOM, but if all things equal no VDOM is
| always faster cause no diffing.
| ProofHouse wrote:
| A lot of people can benefit from offsetting mutations with
| rAF and dbl rAF and batching reads/writes (FastDOM), before
| needing or considering a VDOM. VDOM came to prominence
| because of REACT and then started becoming used even when it
| wasn't needed. It does serve a purpose and scenario when
| needed, tho
| config_yml wrote:
| Reminds me of Action Script 3 which had XML at the core of the
| language. It was a fun language to work with, but famously failed
| to become ES4. Oh well, took us 10+ years to arrive close to that
| with Typescript and JSX.
| quink wrote:
| https://en.wikipedia.org/wiki/ECMAScript_for_XML - Firefox had
| it too, but people at large just didn't want it, so it got
| removed. It got disabled for web pages with the release of
| Firefox 17, 6 months prior to the first release of React.
| sltkr wrote:
| Personally I never heard about it. So it might not be that
| people didn't want it, but that it wasn't promoted much.
|
| Also, it sounds like the only browser to ever support it was
| Firefox? That was probably much more of a limiting factor for
| adoption.
| shove wrote:
| I don't recall being able to construct XML inline like this
| unless maybe that was a Flex server thing?
| waynenilsen wrote:
| This plays very nicely with the locality of behavior model of
| htmx
| sophiebits wrote:
| These examples are cool but I think it's important to note that
| none of them show components whose props can change over time,
| since that ability doesn't seem to be modeled at all. Clever if
| you don't need that but I'm having trouble seeing how it would
| scale to more complex apps.
| ibash wrote:
| People forget what problem the virtual dom and react is supposed
| to solve.
|
| No better article than this:
| https://blog.vjeux.com/2013/javascript/react-performance.htm...
| Spivak wrote:
| And then Svelte showed that you could avoid all that with a
| compilation step and live update the dom efficiently.
|
| https://svelte.dev/blog/virtual-dom-is-pure-overhead
|
| React is also at the point where re-rendering the whole app is
| a fiction the library maintains for you while being smarter and
| doing less, why not go the whole way?
| cribbles wrote:
| These "what ifs" are kinda funny because the origins of JSX can
| be traced back to Facebook's XHP[1], which took explicit
| inspiration from E4X[2], an early JS standard that looked and
| behaved similar to the library described here.
|
| [1] https://engineering.fb.com/2010/02/09/developer-
| tools/xhp-a-...
|
| [2] https://en.m.wikipedia.org/wiki/ECMAScript_for_XML
| spullara wrote:
| I was bummed when they removed E4X from the browser
| implementations.
| novocantico wrote:
| Thanks for taking some interest in my project. It came from being
| frustrated with the state of SSGs over the past 10 years. I
| mostly just make static websites, and I wanted something that was
| simple and intuitive to me, and JSX seemed like a great fit. But
| I got very tired of the disproportionately scaled complexity of
| JSX frameworks like React. Long story short, I made an SSG that
| just renders JSX as strings. It was natural to extend that to the
| browser to just render JSX as DOM elements. And in a few cases
| (mostly layout) it lends well to shared components. Overall I'm
| happy with what I came up with, although some of it is admittedly
| a little hacky, and IDE support isn't as good as it could be.
| nashashmi wrote:
| [delayed]
___________________________________________________________________
(page generated 2024-08-16 23:00 UTC)