4 ms·
It's a bad thing in terms of openness but a good thing in terms of performance and making web applications more like real desktop applications. A lot of DOM wor
by sgt 6y ago
It's a bad thing in terms of openness but a good thing in terms of performance and making web applications more like real desktop applications. A lot of DOM work is a nightmare, so I sort of welcome to the Canvas based approach.
- zozbot234 6y agoDOM is just HTML/CSS. It's not a 'nightmare', it's actually a pretty good fit for the semantics of most UI's.
- kaliszad 6y agoYes, DOM is "just" HTML and CSS with a JS API. All of that is quite broken in various places, the APIs usually rather bad, mutability everywhere and performance suffers as soon as you e.g. switch the cursor from an arrow to hand/ finger, there can be a complete re-render. Google especially is in a position to fix most of these things if they wanted to. They even have the best test-data of any company. But they choose to side-step some of these problems by introducing another, completely new technology and then a small team of people goes on to hack something useable using this technology as if they were a small startup. The problem is, Google is basically a collection of teams with very different focus points. Some are paid to develop new technology no matter if they want it for a specific product. Other people are paid to "improve" an existing product, e.g. Google Docs and have to use what is available. Any kind of exchange of information between teams is a friction and blocks things from being improved. At OrgPad, 10% of CPU time is the maximum we can use if we want a smooth experience. The rest is eaten by the browser and inefficiencies there. I don't think we are alone in stepping over bugs, idiotic APIs and implementation differences everywhere all the time. The fix is not to delegate most of the work to the web developer but for the browser and web standards people to step up and do a thorough job with existing stuff.
- hnedeotes 6y agoI'm one of those persons that really want browsers to be viable options to building fully fledged applications but I sincerely like the core concepts of HTML and CSS. I think the biggest issue is that things kept on being tacked on the primitive specification to solve ever evolving needs. The browsers themselves are written in languages that are meant to go fast - which is important for drawing of elements, rebuilding trees, etc - but not good for doing concerted async operations in a structured fashion. Just looking at those codebases makes you want to stab your eyes with a fork up to your brain. In my, very valuable, opinion, a re-assessment of what HTML is (ignoring the name, and treating it as the language of the browser instead of hyper text) and what at web page can be - along with a browser designed to be multi-tabbed, async by nature, supporting advanced non-tree based layouts (maybe still trees, but trees that could be part of zindexed layers? detached layers that allowed for interaction handlers separate from the visual elements?) in a language that has tools to model those behaviours, could probably re-use all the lessons from HTML, CSS and JS apps. Of course, it would still be like building everything again - but I'm not sure wasm/canvas blobs is a better solution long-term.
- simiones 6y agoIf you've ever used a real UI framework, HTML/CSS is absolutely a nightmare. It is missing almost entirely in any kind of useful controls, which is why there are so many myriads of control libraries. Edit: however, replacing HTML+CSS with a canvas is absolutely a step in the wrong direction. I'm advocating for a richer Web, not a stream of pixels controlled by Google.
- gentleman11 6y agoCare to elaborate what “real ui frameworks” do better? What frameworks do you have in mind when you say that?
- simiones 6y agoSure! I'm thinking of things like QT, WPF, WinForms, Java Swing. What these have in common that is missing from HTML/CSS/DOM is a significant library of controls and layouts.
- tengbretson 6y agoWe're just one more concession away from getting the performance we had 20 years ago with native applications. Edit: The path we're on just seems so obvious I kind of just want to skip ahead and get it over with. - Developers and content publishers love the ergonomics and control of just shipping WASM binaries that paint to a canvas and it becomes the de facto standard. - After 2-3 years of everyone's computer being used to surreptitiously mine crypto everywhere they go we re-learn the lessons of Java applets. - In comes browsers that require signed WASM binaries for your protection. The world is an app store. Curtains.
- goalieca 6y agoCareful here, these are more like thin clients with high network latencies.
- EvanAnderson 6y agoThere's local processing and peripherals. I think you're looking for the term "smart terminals". Something like these for the "modern era": https://www.curiousmarc.com/computing/hp-264x-terminals https://www.curiousmarc.com/computing/hp-264x-terminals
- tshaddox 6y agoBrowsers still support arcane HMTL features from decades ago (and thus can display most web sites from decades ago). Other than things that were already decidedly not part of web standards (like Flash), I’m aware of very little if any backwards-incompatible changes made by popular browsers. So I'm having trouble seeing this slippery slope you’re describing.
- sgt 6y agoFunny. And then at some point someone will rediscover native apps.
- OscarTheGrinch 6y agoI, for one, welcome our new canvas based overlords.
- dukeofdoom 6y agoCouldn't agree more. Developer Lives Matter. Lifetimes have been lost to simple things like trying to get a modal popup to work.
- zozbot234 6y agoIsn't that what <dialog> is for? That's just HTML plus minimal JS.
- dukeofdoom 6y agoNo, I wasn't talking about that. Before getting censored. I meant a dialog with a form on it.
- pleasedonot 6y agoPlease don't riff on the Black Lives Matter movement with things that are more trivial than civil rights. I doubt your intentions were to delegitimize the movement, but still.
- dahfizz 6y ago> making web applications more like real desktop applications. Web developers are the only people who actually want this. Its not something that would benefit society / users.
- gentleman11 6y ago“As a user, I want my apps developers to have a good experience” - a scrum task
- switch007 6y ago> but a good thing in terms of performance Performance is a poison chalice. Many, many people were won over by Chrome's blistering speed. Now they won't have proper ad blocking.
- Sunspark 6y agoI offer Firefox as the solution.
- switch007 6y agoAbsolutely, Quantum was a big leap. But many people are devoted to chrome and so are developers. Many sites are still worse on Firefox than Chrome.
- Sunspark 6y agoAh, but this is in the eye of the beholder. For example, Firefox has an option to allow one to deselect the option "Allow pages to choose their own fonts, instead of your selections above". I usually browse the web in aliased legible Verdana as a result. It also allows you to choose the colours of the background, links, etc. Chromium browsers do not allow you this choice. There, the philosophy seems to be that the web is a designer-driven layout medium and that the viewer should not have accessibility choices. Btw, some of the "sites worse", if you're referring to Google, that's them just breaking things intentionally. You can sometimes work around it by specifying a different useragent and then things are fast again until they change things again. As a browser, Firefox is standards compliant. I agree there are many applications that use a web interface as the GUI and a bunch were coded for IE6 or IE6 with ActiveX and don't display well (or at all) in Chrome. It really depends, but the problem isn't that Firefox follows standards, but that the developers did not follow standards.
- nine_k 6y ago> making web applications more like real desktop applications You mean, abandoning web applications and migrating to network-delivered desktop applications? Because nothing 'web' remains about them: no HTML, no links, no open standards.