Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking DOM from first principles

acko.net

Post reply on HN
Print view View original

211–220 of 234 posts

Re: Rethinking DOM from first principles

#211

Post by austin-cheney »

skydhash wrote: post #164
austin-cheney wrote: post #138

Earlier quoted context omitted.

Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.

State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.

What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.

Re: Rethinking DOM from first principles

#212

Post by austin-cheney »

skydhash wrote: post #160
austin-cheney wrote: post #156

Earlier quoted context omitted.

The point of WASM is a universal compile target that executes a sandbox. That is all. The idea is that any application can be compiled to WASM and delivered via webpage instead needing to be installed to an OS desktop. Developers see something radically different because they want it to solve a different problem, but let’s remember it’s not about developers but portability and user experience for end users.

I always think of WASM as being like a C FFI. Something you reach out when your module is too slow by being JavaScript. Kinda how Python bind to almost every library in C and C++. Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.

Modern JS executes at about the same speed as Java or about 25% C language speed. A JavaScript application is often faster to initialize into memory than a C language application, largely because less overhead is required for application initialization, but otherwise slower because JS is garbage collected.

These distinctions are crucial when hardware performance really matters, like gaming or scientific data analysis. Otherwise these performance differences just aren’t noticeable to a common user.

Before WASM was a thing 3D gaming engines were ported into Emscripten demos to show case the potential. The output was too slow to play heavy 3D games in a portable browser container but far beyond what you could get away with using JS alone. All that misses the point that you could now run this giant game engine in a web page without installing anything.

Re: Rethinking DOM from first principles

#213

Post by dannye »

The article isn't complete/correct. Something did change with HTML. Since 2018 every browser interprets ANY with a dash as a valid HTMLElement, not HTMLUnknownElement. Absolutly NO JavaScript required to turn the DIV-soup into and CSS

Re: Rethinking DOM from first principles

#215

Post by skydhash »

austin-cheney wrote: post #211
skydhash wrote: post #164

Earlier quoted context omitted.

State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.

What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.

Reactivity is just one pattern to help manage state. We have observable (which is just reactivity in another cloth), Entity-Component, View-Model (also Presenter), etc,…

Re: Rethinking DOM from first principles

#216

Post by jerf »

austin-cheney wrote: post #208
jerf wrote: post #161

Earlier quoted context omitted.

"In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory." When you profile something and you get "a billion per second" what you've got there is a loop where the body has been entirely optimized away. Presumably the JIT noticed you were doing nothing and making no changes and optimized it away. I don't think there's a single real DOM operation you can d…

Or, more likely, it’s a traversal of a data structure already in memory. If so, then it is a very real operation executing as fast as reported, at near memory speed.

You can't even "traverse" a data structure at that speed. We're talking low-single-digit cycles here. A compiled for loop tends to require two cycles just to loop (you need to increment, compare, and jump back but the CPU can speculate the loop will in fact jump back so the three operations can take two cycles), and I don't know what the minimum for a JS-engine JIT'd loop is but needing 4 or 5 wouldn't stun me. That's literally the "compiled loop do-nothing speed".

I mention this and underline it because this is really an honorary "latency value every programmer should know"; I've encountered this multiple times online where someone thought they were benchmarking something but they didn't think about the fact that .6 nanoseconds per iteration comes out to about 2-3 cycles (depending on CPU speed) and there's no way what they thought was benchmarking could be done that quickly, and I've now encountered it twice at work. It's a think worth knowing.

Re: Rethinking DOM from first principles

#217

Post by n4te »

andoando wrote: post #179
n4te wrote: post #146

Earlier quoted context omitted.

Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned. You'd never design from t…

Regarding security: I think this is already managed in the iOS/Android ecosystem. It shouldn't be too difficult to restrict permissions from sites, and has the advantage of possibly allowing accesses for sites you trust. Regardling difficulty: HTML/CSS is essentially already cross platform UI toolkit. Yes its hard, but Im saying if one were to make it, I dont see why the same UI framework shouldnt work for a desktop…

True those platforms have security controls, better than what we've ever seen on desktop. Desktop also needs controls like that: to use the system tray, filesystem, hardware, etc. There's at least a work multiplier of 3 for Windows, Mac, Linux. It's just one of many things needed.

Building the web toolkit took enormous effort and it sucks in many ways (see article). Theoretically a new one could be created and could also work for desktop, but there are lots of reasons why that won't happen.

Re: Rethinking DOM from first principles

#218

Post by n4te »

com2kid wrote: post #183
n4te wrote: post #174

Earlier quoted context omitted.

Hard disagree. Lots exist but none are great. Usually layout isn't sane. Another blunder is components are too complex with too many layers. Customization and creating your own components becomes difficult. Often the event system is terrible. Eg Swing has all those problems, in addition to ugly themes. The uncanny valley resulting from trying to mimic native UI was bad. At least nowadays users don't necessarily expec…

Swings layout stuff was fine, better in 2004 than anything the web had until 2020 at least. Also now nothing resembles native platform UIs, so that isn't a big deal. Swing was very theme-able, which is all anyone cares about now days.

Swing layout was bad then (gridbaglayout!) and is bad now. The framework's approach is bad. Components provide min, pref, max sizes that are very often just ignored. Components need a layout mystery object in order to participate. The mechanisms to measure and constrain components sizes and positions is bad. None of the layouts are sane and it's difficult to add your own. 95% of layouts are nonoverlapping components arranged in row and columns, but provided layouts do other things.

Swing was themeable but good luck if you ever try to do it. Customizing an existing theme is too hard. All components have opaque theme objects that are part of the complexity problem I mentioned and often hide functionality and parts you want to customize.

It's easy to shit on everything, but I really think UI could be done much better and that most or all toolkits make big mistakes that hurt productivity and cause a lot of suffering.

Re: Rethinking DOM from first principles

#219

Post by phailhaus »

joquarky wrote: post #190
phailhaus wrote: post #92

Earlier quoted context omitted.

Conflating presentation and data seems like a classically Bad Idea. Changes to presentation break your business logic.

Your business logic should be behind a server.

The parent comment is talking about storing app state in the DOM. That's conflating data with presentation, which is a bad idea.

Re: Rethinking DOM from first principles

#220

Post by troupo »

austin-cheney wrote: post #209
troupo wrote: post #197

Earlier quoted context omitted.

> This is easily avoided: use 'outline' instead of 'border' Yup. And DOM is full of footguns like this. "Oh, you can't do this primitive thing no UI kit has a problem with, you have to use this workaround".

Well, no. First of all visual rendering is an aside not directly relevant to the DOM, a data structure. Secondly, there are two kinds of visual operations that can occur from a DOM change: a screen repaint or a local change. A repaint occurs because the configuration of an element is modified relative to its dimensions, which includes: size, shape, or location. Everything else is really just a color change and is ver…

> there are two kinds of visual operations that can occur from a DOM change: a screen repaint or a local change.

There's:

- reflow (most expensive)

- repaint (second most expensive)

- composition (least expensive)

The footguns in HTML and CSS are randomly scattered all over the place.

Oh? You changed a single value that wouldn't even register on any performance monitoring tool anywhere else? Oops, the browser now has to reflow the page, re-paint it, and re-compose leading to noticeable CPU and GPU spikes.

Or maybe it won't, you'll never know. Because none of these are documented anywhere and randomly change as browser internals change.

E.g. why would focusing an element reflow the entire document? https://gist.github.com/paulirish/5d52fb081b3570c81e3a Who knows.

Again, a recent article on HN's front page dealt with 60% CPU and 25% GPU while doing the most primitive of all animations on just three rectangles.

> I wouldn’t build a AAA 3D game engine in that, but it’s also not the intended use case.

Yes. Because the use case is displaying static pages.

Post reply on HN