221–230 of 234 posts
Earlier quoted context omitted.
You can still do this if you want, table element still exists and works the same way.
Well yeah but no self-respecting developer has done this for 15 - 20 years... it's kind of a red flag these days!
Earlier quoted context omitted.
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…
Implement the UI framework at an OS level. The default OS-specific design should live on top of that. If you were to build an OS of the future, there shouldn't be this need for this distinction between web and desktop.
Earlier quoted context omitted.
> 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.
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.
They’ve made a solution looking for a problem while the problem is staring them right in the face. It is a frankly ridiculous situation.
Earlier quoted context omitted.
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'…
That is not correct in practice. Some operations are primarily CPU bound, some are primarily GPU bound, and some are primarily memory bound. You can absolutely see the difference when benchmarking things on different hardware. It provides real insight into how these operations actually work.
When you conduct your own measurements we can have an adult conversation about this later. Until then it’s all just wild guessing from your imagination.
Earlier quoted context omitted.
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.
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.
And that’s why it’s ten years old and just getting traction now. Until it has DOM access nobody working on the front end will be particularly enthused about its utility. They’ve made a solution looking for a problem while the problem is staring them right in the face. It is a frankly ridiculous situation.
There’s not any particularly meaningful change in its traction. It has specialised situations where it’s very desirable, and it has been used in those specialised situations extensively for quite a few years; and for more general use, it’s trudging along as it ever has been, because it’s not compelling.
> Until it has DOM access nobody working on the front end will be particularly enthused about its utility.
This is also false. Shipping WebAssembly or shipping Web Workers each add complexity, compared with just using main-thread JavaScript, and most people simply can’t justify that—that’s why they’re not interested. But as for DOM access transforming things, I’ll say that Rust is one of the main languages used for targeting WebAssembly (because most languages aren’t suitable), and native DOM bindings is going to change approximately nothing. It will allow/require a slight change in the build process, and slightly change the way you write your own bindings, but that’s all.
I don’t entirely understand why people keep on thinking giving WASM direct access to DOM objects will be transformative. In truth, it’s very minor.
This is satire, right? I mean, it has to be. The author critiques a ~50-year-old set of tech that has been developed piecemeal over those ~50 years to cope with a vast array of different goals and priorities. And proposes their own toy tech as a replacement, with apparently no sense of irony. HTML was never designed for web apps, but it powers billions of them. CSS was never designed for complex dynamic UIs, but it d…
> every single part of all of this tech was debated for weeks by a large room full of very, very, smart people I bet that room never smelled of sunk cost fallacy
This is why "referer" is still mis-spelled in HTTP. To correct it without causing problems, you'd need to alter the code on every router on the planet, simultaneously. It would literally be easier to change the dictionary and every document with the word "referrer" in it.
So, yeah, there's no sunk cost here. It's more like sunk foundations - you're building on top of what has gone before, and you can only build up.
Earlier quoted context omitted.
Visual Basic is significantly less featureful.
Any examples of what the web does better? I can't think of any, esp with activex controls where you could plug in any third party component.
Earlier quoted context omitted.
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'…
I have experienced numerous conversations about performance with people who invent theories while never actually measuring things. Typically this comes from students. That is not correct in practice. Some operations are primarily CPU bound, some are primarily GPU bound, and some are primarily memory bound. You can absolutely see the difference when benchmarking things on different hardware. It provides real insight i…
The whole topic of this conversation is a measurement in which it was claimed that "a billion DOM operations per second" were being done in 2015. That's a concrete number. Show me the actual DOM operation that can be done a billion times per second, in 2015.
The burden of proof here is on you, not me. I'm making the perfectly sensible claim that all you can do in a low-single-digit number of cycles is run a loop. I have, in fact, shown in other languages down at the assembler level that things that claim to be running in .6ns are in fact just empty loops, so I'm as satisfied on that front as I need to be. It's not exactly hard to see that when you look at the assembler. You don't even need to know assembler to know that you aren't doing any real work with just 3 or 4 opcodes.
I don't know how you expect to just Measure Harder and get a billion operations per second done on any DOM structure but I expect you're going to be disappointed. Heck, I won't even make you find a 2015 machine. Show it to me in 2025, that's fine. Raw GHz haven't improved much and pipelining won't be the difference.
Earlier quoted context omitted.
While the web has grown complex in line with increasingly complex applications, the platform is also undeniably bloated, precisely because every new feature (like HTML in Canvas proposal) has to be shoehorned into an already very fragmented puzzle. Backwards compatibility has become an idealistic badge of honor rather than a technical feat. I believe the article does a good job at getting into the technical parts tha…
It’s frustrating to me that we don’t have more directives. I’m simply spitballing however, here’s some examples: We have but why not add other doc types as time goes on? Instead of shoehorning features you could have a which would opt a web page into the ability to use newer features like newer elements or cleaner APIs There is also the “use strict” directive in JS (which any script tag with type=“module” runs in now…
We do have older ones!
Have we collectively learned the lesson? If so maybe we could have a new doctype for [X]HTML 6. I won't be holding my breath for it.