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

201–210 of 234 posts

Re: Rethinking DOM from first principles

#201

Post by cosmic_cheese »

BrenBarn wrote: post #199
cosmic_cheese wrote: post #141

Earlier quoted context omitted.

Much of this complexity comes down to primitives being too primitive for the use case of web apps. They’re fine for documents, but for web apps it’s like trying to build a building from grains of sand instead of concrete blocks. Rube Goldberg machines are unavoidable when you’re doing that. The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that req…

> The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. Well, I'd prefer if it provided widgets that can't be skinned. :-) The theming should be the user's choice, not the app designer's. > That alone would wipe out an incredible amount of complexity and if done right would make…

For the record, I’d prefer native unstyled widgets in sites too, but that ship has already sailed so I figure it’s best if web devs can do things like have a custom styled popup menu with proper keyboard navigation, accessibility, etc without having to pull in a mountain of wheel reinventing JS.

Re: Rethinking DOM from first principles

#202

Post by wolvesechoes »

joquarky wrote: post #194
wolvesechoes wrote: post #57

Earlier quoted context omitted.

"Web apps" should have been standard desktop apps with a network connection. You don't need a browser to use network protocols (and protocols died when HTTP stopped sending hypertext and started to send JSONs) or call APIs. Your OS manages the network stack. We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.

Desktop apps run the risk of installing malware.

Life runs the risk of dying.

Re: Rethinking DOM from first principles

#203

Post by otabdeveloper4 »

strogonoff wrote: post #29

People often lament how DOM, HTML and CSS are becoming more and more complicated: the difficulty with simple and/or common tasks like vertical centering or virtualization, 600+ CSS properties, so many JavaScript methods, leaky abstractions, { contain: size }. I agree on many issues, but equally I struggle to imagine how it could realistically be not complex. If it was a result of a single very well thought through vi…

> However, it is a product designed by committee (in fact, by multitudes of various committees)

Not really. The Web is owned and operated by Google. They can literally do whatever the fuck they want with it. (Any "standardization" process is less then a formality at this point.)

Re: Rethinking DOM from first principles

#204

Post by wolpoli »

rr808 wrote: post #178
strogonoff wrote: post #29

People often lament how DOM, HTML and CSS are becoming more and more complicated: the difficulty with simple and/or common tasks like vertical centering or virtualization, 600+ CSS properties, so many JavaScript methods, leaky abstractions, { contain: size }. I agree on many issues, but equally I struggle to imagine how it could realistically be not complex. If it was a result of a single very well thought through vi…

Visual Basic was a much simpler dev environment 30 years ago already. I was hoping with WASM we'd get something similar, but I'm still waiting.

The market seems incapable of producing a modern VB like development environment for the web. I have theories, but still unsure why it is like that. However, we do have a bunch of zero code tools companies that locks your logic into their ecosystem and charges quite a bit of money every month.

Re: Rethinking DOM from first principles

#205

Post by dontlaugh »

jazzypants wrote: post #180
dontlaugh wrote: post #135

Earlier quoted context omitted.

The UX is nowhere near close to native apps, particularly on platforms that take UX seriously like macOS, iOS or Gnome.

Can you give some examples, please? I can't think of a single thing that cannot be overcome by good design.

They never look and feel exactly like native apps, even the ones that try a bit.

Some widget will be rendered wrong, they'll use the wrong font (or even hinting!), right click may not work as expected, they won't use multiple windows correctly, etc.

Even React Native gets some of this wrong, although few use that on desktop.

If you're a user that appreciates consistency on your OS, all of this will stick out and annoy you. And you'll end up using Apple's Mail.app over GMail's UI.

Re: Rethinking DOM from first principles

#206

Post by worthless-trash »

afiori wrote: post #43
worthless-trash wrote: post #20

Earlier quoted context omitted.

> Browser makers have refused to do that for clear security reasons. Because only javascript should be allowed to screw up that badly.

some of the worst dom api were designed with java compatibilty in mind

So its the java prefix that matters ;)

Re: Rethinking DOM from first principles

#207

Post by strogonoff »

rr808 wrote: post #178
strogonoff wrote: post #29

People often lament how DOM, HTML and CSS are becoming more and more complicated: the difficulty with simple and/or common tasks like vertical centering or virtualization, 600+ CSS properties, so many JavaScript methods, leaky abstractions, { contain: size }. I agree on many issues, but equally I struggle to imagine how it could realistically be not complex. If it was a result of a single very well thought through vi…

Visual Basic was a much simpler dev environment 30 years ago already. I was hoping with WASM we'd get something similar, but I'm still waiting.

Visual Basic is significantly less featureful.

Re: Rethinking DOM from first principles

#208

Post by austin-cheney »

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

Earlier quoted context omitted.

This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors. DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow. Chrome has always been much slower.…

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

Re: Rethinking DOM from first principles

#209

Post by austin-cheney »

troupo wrote: post #197
joquarky wrote: post #188

Earlier quoted context omitted.

> when you so much as change an element border (which may trigger a full re-layout of the entire page) This is easily avoided: use 'outline' instead of 'border', or just keep the border width fixed and change the border color to/from transparent.

> 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 very fast regardless of the DOM size.

Even still modern visual rendering is pretty fast. I have a personal project that is an OS GUI, including file system display, written in TypeScript that displays in a browser. It took close to 10000 DOM visual on the page at one for drag and drop to become slower and laggy. I wouldn’t build a AAA 3D game engine in that, but it’s also not the intended use case.

Re: Rethinking DOM from first principles

#210

Post by phantomathkg »

andoando wrote: post #181
phantomathkg wrote: post #176

Earlier quoted context omitted.

> There should be a singlular framework for creating desktop apps. Why?

Well why have two completely different ecosystems for the wbe and desktop/mobile applications, especially in terms of UI? Both can network

But we have more than one OS in the world, how would you think your one framework approach is going to fit in all platform?

We have seen all these framework claimed to be cross platforms and none of them are not able to make it to the top framework being used.

Web is the only "platforms" with some kind of success by abstract everything away so most of the browser display roughly the same things to all users on all OS.

Post reply on HN