[deleted]
Rethinking DOM from first principles
131–140 of 234 posts
Re: Rethinking DOM from first principles
#132People 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…
Agreed. It would also help if the primitives were correctly thought through to begin with.
HTML5 input and form validation are still a broken nightmare that can barely be patched by adding copious amounts of JavaScript.
Re: Rethinking DOM from first principles
#133The DOM is too large and complex, with so many APIs and concepts.
But you can’t fix that by adding new APIs with plenty of new concepts. You’re just making things larger and more complex. A few things may be able to live entirely inside the new, clean, modern API, but everything else (including practically everything that came before), will either need to ignore the new thing, or incorporate it (and pay the costs of bridging/composing things that weren’t necessarily designed to work together.
I say figure out how to actually remove old, bad stuff before adding a bunch of new stuff.
Re: Rethinking DOM from first principles
#134[deleted]
Re: Rethinking DOM from first principles
#135I've been looking at native development for quite some time now (WPF/WinUI/SwiftUI, starting with Win32 and AppKit), and honestly Web technologies are much better than that. The fact that it is cross-compatible is just a cherry on top. If finally WASM gets a cheap and easy way to manipulate DOM, I think even more stuff will move towards web tech like Electron and hopefully Tauri in the future.
I totally agree. I don't get why people feel so strongly that native apps are better. The web technologies we have are great both from a developer experience perspective and a UX perspective. People hate on electron apps but I think this is mostly due to bloat from electron. I hope Tauri closes the gap it's been great for me so far.
The UX is nowhere near close to native apps, particularly on platforms that take UX seriously like macOS, iOS or Gnome.
Re: Rethinking DOM from first principles
#136Earlier quoted context omitted.
> I struggle to imagine how it could realistically be not complex. Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days. Java and Flash (although very problematic from a security point of view) were probably better bases on which to build…
And how about blind people, bots, accessibility in general? I don't remember java and flash handling different screen resolutions like desktop, tablets, and phones.
Yes, because the author of the comment didn’t explicitly carve out a moment to comment that Java/Flash were not great for accessibility, it must mean that in their hypothetical world where web applications that needed rich interaction and client side processing where based on Java/Flash type runtimes, it would have stayed shit for accessibility.
I’m sure the person you were referring to doesn’t want to make the web shit for the blind. Calm down
Re: Rethinking DOM from first principles
#137Uggghhh, the article states correct facts about the DOM but grossly incorrect conclusions. Most developers have always feared working with the DOM. This irrationality is not new. I have no idea why, but tree models scare the shit out of college educated developers. That’s supremely weird because computer science education spends so much energy on data structures and tree models. It also makes the conversation about W…
> For WASM to become a replacement it would have to gain full DOM access to the containing page. To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around. Givi…
> Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance.
What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.
Re: Rethinking DOM from first principles
#138Uggghhh, the article states correct facts about the DOM but grossly incorrect conclusions. Most developers have always feared working with the DOM. This irrationality is not new. I have no idea why, but tree models scare the shit out of college educated developers. That’s supremely weird because computer science education spends so much energy on data structures and tree models. It also makes the conversation about W…
The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another. The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you. It's not irrational; quite the contrary.
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.
Re: Rethinking DOM from first principles
#139Devs have learned not to keep state in the document, because it's inadequate for it. Web devs have moved the state out of the document into JS variables and have been piling bloated, short-lived crap on top of those variables ever since. If you actually keep state in the document things become rather simple. Scripts themselves become stateless and do not require direct dependencies on one another. Data can be queried…
First Ajax/jquery app I worked on got a lot simpler and a lot less buggy when we started storing state in the DOM. It’s way too easy to miss a state shift in a toggle operation and have the UI be in exactly the opposite state from the api.
Re: Rethinking DOM from first principles
#140Earlier quoted context omitted.
I struggle to see the reason why web pages and apps are even two different things. The browser is really just a cross-platform platform for building applications.
Yes, a terrible one. That's what the article is about.
What I mean is, I dont see why browsers even exist.
There should be a singlular framework for creating desktop apps.