221–230 of 953 posts
This reminds me a lot of those websites that used to be implemented in Flash. It's just one giant opaque blob that gets downloaded and can do whatever it wants. When this stuff inevitably starts being used by every news and shopping website I wonder how search engines will be able to index it.
Feels to me like this could _partly_ be a line of attack. The fight for advertising and tracking on the open web is being lost, which is detrimental to Google. If you have your own ecosystem, what does it matter?
Earlier quoted context omitted.
Couldn't agree more. Developer Lives Matter. Lifetimes have been lost to simple things like trying to get a modal popup to work.
Isn't that what is for? That's just HTML plus minimal JS.
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-…
Does it? I thought they have pretty much identical performance.
Earlier quoted context omitted.
Looking at the DOM in isolation, its pretty quick. The primary reason web apps are slow is because the business logic is typically un-optimized. I've encountered a web app that persisted its state by stringifying it and putting it into localStorage with every UI change. The resulting string was ~5MB and took 200-300ms each time (freezing the UI) on my tablet. I've encountered an app that used an in-house built chart…
> The primary reason web apps are slow is because the business logic is typically un-optimized. This crops up a lot, shifting the blame from the web technologies to the developers who target those technologies, but where are the exceptions? What's the best example of a large, complex, efficient and responsive web-based application? It's easy to give examples of tragically inefficient and unresponsive web-based applic…
But their technical leadership contains some of the (arguably) most accomplished folks working in the Javascript world these days, they might be an outlier in this area.
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…
Yet another reason to use Pi-hole. The web browser is the wrong place to try and fight against this sort of thing. Secure your home network once instead of fighting an arms race on each device you have.
Earlier quoted context omitted.
I am also wondering about this. Having recently built a production app in Flutter Web used by millions of people, I am very eager to hear about other people's experiences with Flutter Web in real life applications.
I've been coding Flutter mobile apps for a couple of years, but have only toyed around with the web target. In my experience it seemed kinda off . Scrolling lists ignored my native scroll speed and janked, text manipulation felt laggy, etc. It reminded me of the good old horrible days when Flash-based websites was widespread. I tested it right after the 2.0 release, so perhaps they've fixed it since. EDIT: Also IIRC…
Earlier quoted context omitted.
> Kind of surprised I'd assume a significant cost-benefit tradeoff. For all its flaws, the DOM rendering algorithm is at least "document-like," so there's a lot of wheel-reinventing to do going from just using the DOM to a custom document layout implementation underpinning a canvas-targeted rendering algorithm.
Look at the Google docs generated html markup some time. It’s not making nice neat ’s and ’s.
Earlier quoted context omitted.
Well it also breaks all context menu functionality. No more right click -> copy text unless the website specifically implements it. Any custom context menu you use is now useless. Personally I always use 'Right click -> Search..'
I think we can assume that Google Docs will implement right click -> copy text.
I don't build extensions or work on much front end web lately but this reads like Google wants more control over their stuff. The web is becoming less open. > By moving away from HTML-based rendering to a canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated. > If you are building your own integrations with Google Docs, we recommend using Google Work…
It's not about the web being more or less open, it's about the browser playing the role of a distributed application run time. I'd argue that Google Docs is basically not a part of the web, it just incidentally happens to run in the same browser as the web does for logistic reasons.
Not everything a browser displays has to fit in the "page" paradigm.