161–170 of 953 posts
I would like to know which ui library they use.
They want faster performance and more accuracy for typography and layout of the user's document on the screen.
Earlier quoted context omitted.
I am in complete agreement. When I've brought this up on HN in the past it's always been dismissed with "But accessibility!". A big company like Google can handle that just fine. Presumably they'll eventually port Chrome to WASM. Then they can completely control the browsing experience. To exert any control over our browsing experience we'll be single-stepping thru machine code. I had fun cracking Apple II and PC sof…
> Presumably they'll eventually port Chrome to WASM. Then they can completely control the browsing experience. ...what? As opposed to shipping binary executables for an OS/arch combo, they'll ship a binary executable for WASM, and then a second binary executable for the OS? If they want to take Chrome closed source and make it fully obfuscated, they can do that already, with or without WASM. Chrome is already closed-…
I expect there will be a WASM-based browser embedded within some (most?) websites, eventually. The public-facing webserver will serve-up the WASM-based "inner browser" and nothing else. Content will only be accessible via the "inner browser". Determined attackers will be able to extract the keys used by the "inner browser", for sure, but the average person won't be able to.
It'll be packaged as a product, probably targeted at "traditional media" sites: Use this on your website and nobody can block your ads or bypass your paywall. You can use all your existing development tools, servers, etc, and it'll "Just Work".
Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…
Breaking away from hypertext, pushing images in people's faces: it's not the web. It's an assault, a great step backwards. It's an attack on the internet.
Absolutely people are definitely starting to treat the web as a big canvas. Those people are doing great injustice & cruelty to one of the only pro-user pro-agency information technologies ever created.
Earlier quoted context omitted.
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.
Couldn't agree more. Developer Lives Matter. Lifetimes have been lost to simple things like trying to get a modal popup to work.
Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…
If they're going to make the leap of switching the render layer, I'm surprised the leap isn't to flutter (which is supposedly stable/ready for production web apps?).
Earlier quoted context omitted.
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.
DOM is just HTML/CSS. It's not a 'nightmare', it's actually a pretty good fit for the semantics of most UI's.
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.
Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…
Is ad blocking Google Docs really a concern though?
Earlier quoted context omitted.
> What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. Ok, but it's not trivial to build complex web-based applications that don't do exactly that. This is why there are so many frameworks out there that take care of that problem for you. React isn't the only one. Angular, Vue, and Svelte also handle this for the developer, using various different approaches. It's n…
I would agree that companies have mostly settled on paying 20% as much for development, at the cost of 5-10x the memory footprint and 5-10x the input latency in the finished program. I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX, so they'll be prone to make even more trade-offs…
Or it could be they're choosing a ubiquitous, open, cross platform distribution model for their app?
Earlier quoted context omitted.
We'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…
Careful here, these are more like thin clients with high network latencies.