Hacker News Reader

Comment by pdkl95 | Hacker News Reader

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 TV.

I didn't expect the first move towards canvas-only rendering to be traditional wordprocessors. As usual, this is merely the first step. Once the tech has been normalized by developers, transitioning regular webpages will be a fait accompli.

[1] https://news.ycombinator.com/item?id=10294187

[2] https://news.ycombinator.com/item?id=26351771

View on HN

Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks. Some of them work well despite this, but, it’s a horrible set of code to maintain and very, very hard to make a good user experience. One of the very hardest things to do well in the browser, actually.

Thus I wouldn’t necessarily interpret Google Docs making this move as the start of an inescapable trend. It may be, or it may just be that certain kinds of applications (like Docs and Games) can work a lot better by providing their own rendering engine.

Furthermore, actually implementing your own text renderer and input engine in WASM is a different horrible nightmare, because you've now forfitted any chance of supporting IMEs (e.g. touch keyboards, pinyin/romaji/kanji input, iPadOS Scribble), you need to implement your own text selection inputs, your text won't show up in the accessibility tree, and you can't copy-paste without additional, browser-specific tweaks. The only reason to actually do this is if you can't use HTML.

Source: I am a Ruffle developer and have had to do exactly this to support text input in old Flash games.

> you can't copy-paste without additional, browser-specific tweaks

Expect an AI-based OCR browser extension to copy text to the system clipboard. Possibly by sending screenshots to some centralized service ;-)

This would be more funny if it was less prescient.

A million times this - having worked in this space, nobody wants to do this. I understand the cynicism, but the affordances provided by the browser for things like accessibility are very painful to give up. This isn't some dark pattern attempt to cut out whatever "openness" remains on the web, or to convert the browser into a display-streaming client for some sinister DRM reason.

In my past job, we rewrote our spreadsheet rendering to use canvas and gained massively in simplicity and maintainability. And there was no obfuscation angle to it - we even shipped source maps! Handling accessibility and text input was hard (we ended up adopting a hybrid-DOM model where some things like input fields were still native ones, or shadowed by native ones), and even then it was still easier than dealing with browser rendering.

This is simply a reasonable way to work around the DOM being trash. The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.

Once the trail has been blazed by pioneers, expect a gold rush.

What would a good API look like, I wonder?

The dom isn't trash. Its good enough. We just need to stop making it do things it wasn't supposed to. That's why things like electron make sense a little bit. Not perfect but sensible.

Isn't Electron rendering to an embedded Chromium and therefore the DOM as well?

Yes

I'd agree. I think the DOM is fantastic, *unless* you are doing advanced document manipulation, in which case it is trash (for that use case only). This is what I'm assuming the author meant.

I spent many years working on that sort of thing, a decade ago.

> We just need to stop making it do things it wasn't supposed to

This is a thread about Google Docs. Your suggestion to the Docs team is to ... stop? Just shut down their product?

Oh no. They're google. They make a godforsaken browser. They can pay people to do nothing more than think about code. By all means. They can launch a satellite with css if they want.

But the rest of us plebs...

Btw for NASA css is shorthand for Control Stick Steering, which is something you did at later stages of landing with a space shuttle.

I read this as sometimes you need to use an exit hatch like Canvas instead of a bunch of hacks to make a WYSIWYG editor strictly with the DOM. Google seemed to come to the same realization and that is why they are using Canvas

Just send LibreOffice files as attachments via your personal email server, what’s the problem?

Well, to be fair Libre Office online exists[0]. However, I believe EtherCalc[1] is faster.

[0] https://www.libreoffice.org/download/libreoffice-online/

[1] https://ethercalc.net/

Yes? Most of the web really ought to be shut down. It's just providing negative utility to society.

Alternatively: return to monke.

People are trying to make DOM be a WYSWIG text editor. You're point is dead on.

The response is to write an opaque, vendor-specific "DOM". Which is the complete opposite of what HTML was supposed to be. But the browser is now a platform and not a browser, so the metaphors are horribly mixed to the point where I'm not even sure what a DOM is supposed to be anymore.

The DOM was always a WYSIWYG editor – albeit, for HTML, not text. Though, back in the day, HTML was a subset of text with image and table support; none of this fancy `line-height: 1.5em;`…

I wish the web had evolved in a more documenty way.

Hmmm... maybe I should have chosen a different acronym.

What you expected to see isn't alwasy what you got.

WYETSIAWYG

Rendering across browsers and operating systems was a trainwreck until maybe 5 years ago (over a decade of polyfill is finally gone). And even with an ecosystem like ElectronJS + Bootstrap, Win10 MacOS and Linux all look slightly different.

So yes and no to "DOM was always...", but more "No."

That's the entire point. DOM is meant for structured web pages, not web apps. If you want to build complex web apps it is better to use your own renderer..which is exactly what Google is doing with Docs.

We should just port wine to webassembly and be done with it

http://www.boxedwine.org/

The problem is that the escape hatch from document to application is completely broken. The DOM is fine for documents, but it's completely awful for applications. Admittedly, some things on the web that should be documents insist on being applications instead, but many things on the web aren't documents.

For these things, using the DOM is painful. When the pain becomes great enough, the biggest available escape hatch is pure native 2D rendering (canvas), which is a nightmare for accessibility and affordance to end-users. It would be awesome to have something else to escape to.

> The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.

About a decade ago I had the start of a Eureka moment on how to do this (back then — https://medium.com/space-net/spacenet-51aca95d49a2, nowadays https://treenotation.org/). It seems to me we've missed a sort of fundamental universal notation of the universe, which you can think of as "two-dimensional binary". I predict we will soon see a Cambrian Explosion of new formats and languages that are simpler and more interoperable with each other, and some will have the opportunity to build new great languages for rendering stacks.

Wow that tree notation looks super interesting!

Bookmarked for a later in-depth read but my interest is piqued!

How is this not just S-expressions with indentation instead of parentheses? What makes it different from say Sweet Expressions?

Common question. You cannot do column and matrix operations natively against S-Expressions (You need to parse the whole thing). This turns out to be very important and useful. S-Expressions need to be transversed in 1-D linear order.

When you two-dimensionalize S-Expressions and remove the parens, you get Tree Notation.

Hey, nice! I have a notes file experimenting with a similar tree-style minimalist data notation; it's definitely an area that needs more exploration.

I like what you've done with it, I'll need to take a closer look.

While I was thinking about it, I also decided to take a look into prior art, which took me all the way back to Landin's "The Next 700 Programming Languages" from 1966 which introduced the hypothetical language ISWIM, which was the first to introduce indentation based syntax and inspired the ML and Haskell family of languages (https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf)

It wasn't exactly what I was looking for, but it's fascinating to see how long we've been thinking about these kinds of issues.

Yes, and surprisingly there are not too many that use any indentation based syntax (about 1 in 50). However, of the ones that do (abc, aldor, boo, buddyscript, cobra, coffeescript, csl, curry, elixir, f-sharp, genie, haml, haskell, inform, iswim, literate-coffeescript, livescript, madcap-vi, madcap, makefile, markdown, miranda, nemerle, net-format, nim, occam, org, promal, python, restructuredtext, sass, scss, spin, stylus, xl-programming-language, yaml) there are some real gems.

Some more interesting read's in this space:

2003 - Egil Möller's I-expressions - https://srfi.schemers.org/srfi-49/srfi-49.html

1984 - Alan Kay's 3-D spreadsheet - http://worrydream.com/refs/Kay%20-%20Computer%20Software%20-...

1972 - Mark Wells' A Review of Two-Dimensional Programming Languages - http://sci-hub.cc/10.1145/942576.807009

Cool! Thanks for some more reading and inspiration.

Here's what I have in my notes buffer; I hadn't gotten much further than this.

  Ssn: /([0-9]{9})|([0-9]{3})-([0-9]{2})-([0-9]{4})/\1\2\3/
  People: Table
      first: String
      last: String
      dob: Date
      ssn: SSN

  Csv
      headings: True
      load people.csv
          as: People
      select first last dob
      filter dob.age > 21

Well, I had some discussion, alternate forms of the syntax, links to prior art, etc, but not much else worth sharing.

Will have to add your TreeNotation and Ohayo to that list, as well as these other links you've shared.

Very nice! The nice thing about these kinds of notations is that they last. Simplicity is timeless. I can immediately grok exactly what you are doing here. :)

Do you have a more formal documentation for treenotation? The idea is intriguing but I couldn’t find the actual rules specified on the site.

The rules for the basic notation are really simple. It's just basically a grid (visualize a spreadsheet), where each line is a row and each word is a cell. Indent a line to indicate a child node/row.

An updated spec: https://faq.treenotation.org/spec/

Thanks - that’s what I was looking for! Looks like a potential improvement on s-expressions to me in terms of a readable syntactic kernel.

For what it’s worth, I have been interested in the concept of 2d languages for quite some time, and I’m not sure what your definition is.

To me this seems to have a 1d topology - I.e. it’s still left to right top to bottom, and there are no loops or semantics that require reading in other directions.

I contrast this with something like a circuit diagram or labview program.

I may be missing something though.

This is a dark pattern. Webassembly is binaries with no source. There is nothing to deny that. It closes the web and it isn't free software. It is moving back to proprietary. For reasons that all the googlers or other webasm devs here can't admit.

I had this instinct as well but I think this is about rendering, not necessarily editing. The document link is not to something editable. Granted, perhaps these will merge.

> The APIs for text manipulation in the DOM are abysmal

I develop an NLP labelling interface (which is similarly document-focused) in JS all day and can attest to this.

Here's some specific examples:

- To work out where some text is being being laid out, eg to display some UI around it, the Selection/Range/Rect APIs will help but Rects are always viewport-relative, so you'll need to convert them to element-relative to position your UI, which sucks.

- Firefox supports multiple DOM Ranges per Selection (ie allows non continguous text selection), but nearly all other browsers support a single range.

- You can't truncate text across multiple lines (the CSS line clamp spec is an experimental fix)

- If you want to pop up an interface while some text is selected, you'll need to capture and reimplement selection because as soon as another item is focused the selection will no longer display.

If you're into JS and building anything document related, I've written a bunch about the some of the issues at https://humanloop.com/blog/how-to-build-an-ml-labelling-inte...

teach markdown in schools. who needs word processors anyway? need something fancier than headings, lists, block-quotes etc? learn LaTeX. Text rendering can be fantastic in the browser. I'm half joking, but I think the world would be a better place if folks had fewer, more precise ways of making words look the way they want

I love markdown, all my blog posts, TILs, book notes are in it. Even my presentations are written in markdown. But this comment is so obtuse and user hostile. Millions of people know how to use word processors. Let's not take that away from them or even imply that they're doing it wrong. They're fine. Software can always be improved, like the Docs team is attempting here. But we can't overnight tell people that their skills are obsolete because some developers somewhere like Markdown and Latex.

To me this is like saying that because we are no longer able to make good bicycles people should walk everywhere.

Shouldn’t software serve people rather than the other way around?

This comes across as a ‘you’re holding it wrong’ type argument.

> every in-browser WYSIWYG text editor is a steaming pile of hacks.

Xforms 2.0, and other opportunities to have rich text in browser not suck were there for the browser maker to take in the last 15 years.

Instead they tried almost everything instead of choosing the most obvious solution, and fixing it.

> Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks.

If that's the case, it probably would have been better to standardize some better APIs.

You assume the developers of Google Docs are the developers of Chrome and WHATWG

Whether or not it’s a trend will come down only to the commonality of skills in the marketplace for a given rate of pay.

This is what Flutter on the web is, by the way. You can try it out here:

https://gallery.flutter.dev/#/

and marvel at the impossible to select text, one of the many affordances violently excised here.

If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.

A dystopia. You can't control-F in the page. Can't copy and paste a word you don't know into a translator or dictionary. Can't share text unofficially - like copy a sentence into a email, etc.

Also, you know, accessibility. This could be a real serious problem for people with disabilities.

I'm hoping for a revamped EU accessibility act https://ec.europa.eu/social/main.jsp?catId=1202 that also covers document and office applications, and with GDPR sized fines.

We have to be careful not to throw the baby out with the bathwater here, though. Obviously accessibility is an important issue for both commercial and ethical reasons, but if you're talking about writing laws and severe penalties for breaking them then you will always have to choose what minimum standards you will always require and then accept that it might be unreasonable for a software developer to go further.

For example, suppose the entire purpose of a certain office application is to draw some clever visualisation that helps the office workers to understand complex relationships in their business data. Maybe that presentation style has been chosen based on years of experience and saves a lot of time and avoids a lot of mistakes compared to a simple text report or table of figures. However, maybe it also doesn't work for someone whose vision is too limited to usefully see or interact with the visualisation.

Perhaps you could present the same data and relationships in a different way, a format that would be more amenable to sound- or touch-based interfaces for those with severely limited or no vision. In reality, that might mean writing a second entirely separate application, one that might cost more than the original to implement and support, for an audience that will usually be very small and often empty.

So where should the line be drawn? In an ideal world we want to be as inclusive as possible regardless of anyone's individual limitations, but we also want to provide the most effective presentation possible to those who don't have the same limitations. In general doing both might be prohibitively expensive, so how do you make realistic, ethical decisions in this space, and given that every software application is different, how do you codify the standards you want to make mandatory for the accessibility reasons?

The website says:

    Cannot read property 'match' of undefined

    TypeError: Cannot read property 'match' of undefined
    at /var/app/current/routes/avs.js:44:29
    at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
    at next (/var/app/current/node_modules/express/lib/router/route.js:137:13)
    at Route.dispatch (/var/app/current/node_modules/express/lib/router/route.js:112:3)
    at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
    at /var/app/current/node_modules/express/lib/router/index.js:281:22
    at param (/var/app/current/node_modules/express/lib/router/index.js:354:14)
    at param (/var/app/current/node_modules/express/lib/router/index.js:365:14)
    at param (/var/app/current/node_modules/express/lib/router/index.js:365:14)
    at Function.process_params (/var/app/current/node_modules/express/lib/router/index.js:410:3)

This is 100% the reason why I decided not to use Flutter back when I was shopping.

It probably would have reduced my developer effort considerably compared to basically every other option that made it to my short list, but I can't in good conscience build something that isn't accessible.

Flutter claims to be fully accessible: https://flutter.dev/docs/development/accessibility-and-local...

Did you actually try it?

No, I just looked at the documentation and saw that it isn't supported on all the platforms I'd be targeting.

For example, that page you link is specific to iOS and Android targets. Nary a mention of what to do when you're targeting the Web. But it's also, at least as of when I did my comparison, explicitly not supported on at least some desktop targets.

Thank you for saying "claims to". Copy pasting a response I made elsewhere:

This is making a mockery of accessibility.

It's the equivalent of having a company that actively discriminates against everyone not passing a internally developed test to check whether you are a "neurotypical" and then respond to criticism by pointing at the wheelchair ramp you installed on one of your entrances.

If I can't copy paste words from your websites to put them into a translator, if I can only use your website when I use one of the two corporate-affiliate-selected screen readers (not even platform-agnostic ones), when I can't look at your website from anything that does not have 4+ cores and a 4G or better connection...saying accessiblity is a "first class citizen" or even citizen at all is laughable at best.

I said "claims to" because I don't know how I can verify if it is. The other person responding to me correctly mention how they suggest tools to scan for accessibility issues on iOS and Android, but they don't say how to do that on the web... have you managed to somehow figure out what is not currently working, exactly?

Regarding performance: Chrome uses Skia to render the DOM, why do you think rendering Flutter, also based on Skia, should be so much worse?

The thing is, when you're shopping for GUI toolkits, "try it and find out" isn't a great decisionmaking rubric. Partially because there are a zillion of them and you simply can't try them all, and partially because learning one is expensive and time-consuming, so, unless you genuinely enjoy that kind of thing, you kind of want to pick one in one shot.

Meaning that, in a slate of options where one of them can definitely do something you need, and another one where the official story seems to be ¯\_(ツ)_/¯ and the examples you've seen seem to indicate that it's at least something you need to go out of your way to accomplish, there really isn't any injustice in deciding to expend no further mental energy on the latter.

That said, if you want spend your own time digging in and finding out, be my guest.

Flutter is not competing with general GUI toolkits, it's competing with fully crossplatform toolkits, of which there's only a couple of real contenders for real-world apps: React Native and maybe Sciter.

Nothing else is production-ready and can run on the web, iOS, Android and desktop OSs (Linux, Windows, MacOS).

It's not competing with pure web frameworks. For this reason, yes, I think that if you're going to criticize it, you absolutely need to know what you're talking about... if Flutter claims it can handle accessibility, it's on you to prove it can't if you make this argument so eloquently on the Internet without actually knowing it.

BTW if you know of any other good UI Toolkits that really can run anywhere like Flutter, using the same code base, please let me know.

Accessibility is a first class citizen in flutter. https://flutter.dev/docs/development/accessibility-and-local...

I wish that page mentioned how accessibility works for Flutter websites. Seems to only mention Android and iOS.

This is making a mockery of accessibility.

If I can't copy paste words from your websites to put them into a translator, if I can only use your website when I use one of the two corporate-affiliate-selected screen readers (not even platform-agnostic ones), when I can't look at your website from anything that does not have 4+ cores and a 4G or better connection...saying accessiblity is a "first class citizen" or even citizen at all is laughable at best.

You're talking about very different issues of accessibility, one of which is the financial accessibility of client technology and reliable web connection.

That is attacked through very different means. For example, FB being free and ad funded addresses that issue; but this is a business model and not a technological standard. Society subsidizing technology is another possibility. But these very serious issues of access and the solutions to negotiate with them are very different from purely technical solutions to access.

HyperText Markup Language is accessible, doesn't require a powerful computer, and can be copy-pasted into a translator.

If your website is unreadable in view-source:, it's probably inaccessible in some way. It's not hard to make an accessible website. If it's hard to make that accessible website look the way you want? Tough luck; hire a competent web designer, or scale back your artistic vision, because you sure ain't sacrificing the ability for people to actually use your website for some pretty colours, are you now?

That's only for iOS and Android apps. (Desktop?) screen readers do not work at all on gallery.flutter.dev, because they can't detect text in a canvas.

Due to Section 508, this sounds like it would make Google Docs unsuitable for government work.

The copy and paste problem is sidestepped in android by the os native ocr, it might become common elsewhere too.

I can’t tell if you’re being facetious. Text is rendered to a canvas frame buffer and then the solution to text selection involves OCR?

Amusingly, the Amiga lacked cut&paste support in most applications, so someone developed a tool that did precisely that.

Leading to questions like this: http://forum.amiga.org/index.php?topic=10580.0

Cab I be facetious and factually describe the current state of affairs simultaneously?

I mean, that's how MacPaint was going to work. (They eventually ditched “edit text once it's written” entirely, for fear that people would use MacPaint for word processing, but the code was all written.)

So basically they are recreating the problems from Flash in 2021, but now using web standards ;-) ?

Here's me almost hoping that ADA lawyers will have many field days with this tech. Edit: since this time there is no good excuse for it.

One step up, two step down.

Progress

"Poor boy shuffle"

Add to that, a11y as a 2nd class citizen.

Do you honestly believe they won’t implement copying a sentence.

I honestly believe they WILL implement copy paste...

... along with tracking exactly what you copied, when, where you hovered your mouse, inserting all sorts of features into your copied piece of “plain text”

... along with the ability to force-turn off copying from server side whenever it benefits them.

You WILL use ChromeOS (by another name) and you WILL like it

All of this is done without canvas. Maybe less drama would help.

> All of this is done without canvas.

Currently it’s pretty easy to get around such blocks. Compare with how hard it is to get around modern, proper DRM.

I have faith this implementation will be modern and proper, as the fate of the ad industry and those who rely on it, rely on it.

Flutter for web is not ready and flutter devs seriously should remove those demos because it's ruining reputation of Flutter for Android, iOS and Desktop which is absolutely a delight to work with. I never developed apps for mobile being a backend developer but now I have developed few in record time. Flutter for mobile is amazing and it's going to change the game.

I am not really sure about Flutter for web though.

It's basically Flash [1]. What's old is new again.

[1] https://en.wikipedia.org/wiki/Adobe_Flash

They have played us for absolute fools.

That is absolutely horrible. I am only waiting for the day when people start making desktop apps using electron + Flutter on the web.

Right now probably some people seeing this on HN will be thinking about it.

Flutter for web I don't know where it will be in 5 years but flutter for desktop is going to eat electron apps for sure.

Oh boy, I can't even scroll smoothly through these pages...

It`s not slow on an old intel i3 laptop and on a motorola one phone. I keep seeing these comments about flutter web with different examples, they are never slow on my old devices. Also you can make the text selectable if you want to.

Which is itself a commentary on the immaturity of the technology. I certainly wouldn't run it in production if I can't trust that all devices of a certain performance level can run it. Random performance issues on top-tier hardware is going to be a non-starter.

As a user or as a developer?

Developer. Texts aren't selectable on mobile by default and they want the web version to act the same.

Just loaded it and it ran awfully. We all have anecdotal experiences and it doesn’t make yours any less valid than mine but it does point out that they don’t show much besides what you personally experienced.

wdym by awfully? This makes me crazy, the gallery loaded instanltly, every item I click loads instantly, no problem with scrolling. There is a five second loading delay on the phone when the app loads, the items after that open just as fast as on the laptop.

The only thing I saw that didn'r run smoothly on my weak phone is the flutter plasma demo[0], but it runs without any tearing on the laptop.

[0] https://flutterplasma.dev/

That doesn’t even load on my iPhone 12

I clicked the "Shrine" app on a 6-core MBP, it took about 3 seconds to render the main gallery page and I got an entire 4 frames rendered during that time.

there is an option for flutter to compile for both canvaskit and html - and then on mobile might select the latter (for reasons being smaller) - it might be that (not sure).

I have two stupid flutter apps that are canvas only - https://malkia.github.io/game_of_life/ and https://malkia.github.io/tictactoe (but haven't rebuilt them with latest & greatest)

Unselectable text, and links that are actually javascript so you can't preview them, or open them in new tabs.

But who are we kidding, the web is javascript all the way down now.

It refreshes dormant memories of what Flash used to feel like.

For me the balance is still the same. Fine for highly interactive things such as games. For everything else, ugh...

I had these exact complaints about web apps many years ago, and I was dead wrong. Nobody cared that web apps were slow, had/has horrible UX compared to native apps, and feel janky by comparison. These demos elicit similar feelings. Now, they're not as fast as I like, but they feel better than most webapps already. (It reminds me of Flash, actually.)

If the Flutter dev experience is good enough, this will eat traditional web apps slowly. In a way, the web was designed for this sort of scenario: a delivery mechanism agnostic of the client implementation. We've gone from pushing server-generated HTML to megabytes of JS + SPAs, and now a WASM/Canvas hybrid seems inevitable.

It all comes down to how well these perform on mobile devices, what the dev experience is like, and how the end product feels. There's still a lot up in the air, but, I'm honestly impressed with the progress shown by Flutter here. There's still a host of considerations unaddressed (including accessibility) that I hope they have an approach for.

Despite their shortcomings webapps won because they had a number of advantages that native lacked, most of all software distribution.

What has flutter to offer that a regular webapp lacks? (not performance, it seems)

Resume lines.

This is correct, I am afraid.

The fact that it (the same code base with minor changes) runs on desktop and mobile platforms?

Great point. It is striking to me how similar many of the modern languages are for various platforms (thinking of Rust, Kotlin, and Swift here), but it is still quite difficult to share business logic among web, Android, and iOS devices because of language differences.

If Dart/Flutter is good enough for all of those platforms, that is quite the value proposition.

SPAs to Flutter is a much smaller step conceptually than native to Web. Most of the world is using a Blink-based browser of some sort already. Updates are pushed aggressively.

> What has flutter to offer that a regular webapp lacks?

Google branding, novelty, more sane dev UX. I'm not saying those are good reasons to choose it, I'm just extrapolating from how the industry works.

Let's be honest: end users basically just put up with whatever devs release at this point. It doesn't matter if the end product murders battery life, doesn't fit the target platform, and steals their data. It's not like switching to some less-than-web-native framework is somehow a bridge too far for end users.

Your last point made me think: for all the flak the gamer demographic gets for being over entitled and toxic, they seem to actually ultimately end up with nice things like programs that run at a performance you'd expect from a modern computer and don't swamp you with creepily-targeted ads

It's Flash websites all over again!

Wow, that’s truly a masterpiece in awful. Are they also rendering everything to canvas and then reinventing layouts, controls, etc. to get it so laggy?

The demo doesn't have it, but they did fix the selectable text issue, just need to wrap your text in a SelectableText widget.

But this means the default is for text to be unselectable.

Which clearly says all I need to know about it :-/

Yep, I agree. Even though it's normal on mobile devices, it's weird behavior for the web. Given the way flutter is designed (sharable code base, eVeRyThInG iS a WiDgEt), I don't see an easy and obvious solution here.

Yikes. How does the inability to select or search text pass even the most basic of UI/UX and accessibility guidelines?

Web UIs are already an incredibly cut-down implementation of a real OS GUI. I'm not looking forward to something even worse than that.

And I thought Gemini was not polished enough. It might be a beacon in this potential darkness

As a former angularjs user, I’m not keen to learn another framework that will get abandoned or replaced in a few years

I have to agree, it runs really slowly (really struggles on scrolling) on my Macbook Air from last year, which normally runs heavy JS sites just fine.

EDIT: to be fair, it runs quite smoothly on Safari and Google Chrome... only Firefox seems to have trouble with Flutter on the Web for some reason.

I didn't believe you at first, but then I gave it a try.

Yes, they actually built an email client from which you cannot copy text: https://gallery.flutter.dev/#/reply

That's a demo for a gallery, not an e-mail client.

Or we could take a look at the example Google Doc linked in TFA - https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...

Seems like it's fast (on my machine at least), can select text and Ctrl+F works. I totally understand the urge to complain and doom say, but could we at least stick to the example at hand? I'm sure if you went through this doc you'd find things to complain about. That would be more relevant to the discussion.

After trying it for a few seconds, noticed X select-to-copy was broken, as well as the browser spellcheck feature that my daughter relies on heavily in Google Docs (where a text area can be spellchecked in french or english depending on the active spellcheck).

I didn't spend more than a few seconds on it, but those were the features I immediately noticed. This is going to be a painful transition for us since she uses both of those a great deal with her schoolwork. Since the doc was read-only, I couldn't test IME/XCompose - hopefully those work at least.

And they speak about plugins being broken in TFA. I'm not surprised that your daughter's plugin doesn't work today, because they announced the change today. Presumably, those plugins can be rewritten to adapt to canvas. Just give them time.

Well, I was referring to the built-in browser spellcheck and the X windows copy/paste. Both of those probably rely more heavily on normal native widgets. Not saying it is impossible of course. The X windows copy/paste could be done using the invisible text approach firefox uses in PDF.js. That would also help with accessibility somewhat.

But I'm not sure how they could integrate with browser spellcheck without basically going back to a less canvas-y approach. Invisible text areas surely would have layout problems aligning with the rendered font. But, I guess we'll see. I'm guessing Linux users are not a major factor in their decisions though. Firefox users probably even less so.

And all the problems solved by HTML and CSS will be new again, there will be many new incompatible frameworks for handling layout and styling, a blinking cursor will again take 200x the CPU it should to implement. Ugh.

I for one would welcome the death of HTML and CSS. Unfortunately I suspect they will merely be re-used for this.

HTML and CSS are fantastic; when used what they were designed for. Document markup and display. I blame webapp developers for the scope creep and subsequent denigration of a perfectly reasonable set of standards.

HTML and CSS were never denigrated. There's not one superficial feature which doesn't make sense. Most of it is barebones. If I had to pick one feature the blows the scope out of proportion, it would be the `is` selector, but that's the only one I can think of

Denigrated ~= put down.

And there's plenty of examples within the comments of this article where people - webapp developers - harp on how bad HTML and CSS are, because HTML and CSS weren't designed for webapps.

CSS is the worst layout language, except for all the others.

HTML and css are great for making application GUIs. I used a bunch of frameworks like qt and Java <some kind of verb> and wpf and they were all worse than php, css and HTML.

I would argue that Tk is even better for making GUIs.

Here is a simple Tcl/Tk application: https://rkeene.org/viewer/projects/tkweb/test1.tk.htm

And here's what that application looks like (in a web browser, as well as natively, bear in mind that this from 2003): https://rkeene.org/viewer/projects/tkweb/tkweb-test1-2.png.h...

Can you describe the resulting layout as well as interactions as well in HTML ?

CSS has absolutely never been good at what it was designed for.

It is meant to display a document. It took TWENTY YEARS before it got support for showing text in columns, the most basic of basic things in how text is often displayed.

It is only now, after twenty-five years, getting a way to specify the aspect ratio of an element.

It's an awful, awful joke.

CSS was originally intended to consolidate document style information, so you didn't have to repeat "24 point bold, blue" for all your section titles. It's pretty good for that, but then we somehow decided that it should also handle the entirely separate job of page layout. Which led to years of standards people yelling at us to use CSS and not tables, and then plugging their ears when asked how to implement complex designs like vertically centered text.

I find it really hard to rationalise this thought with the thread...

- WebAssembly + Canvas rendering is bad because it turns the web into a bunch of opaque blobs and removes user freedoms and abilities

- The web should only be for documents, not applications

- So it follows that... all the applications which are currently "open" websites should be opaque native app executables where you can't have extensions or adblockers or anything?

To be clear, I agree with the first point. Websites moving to opaquely rendered canvases is terrible. They should remain "normal" DOM/HTML.

I'm not a web developer, so keep this in mind as I clarify.

Application development for browsers is, in a way, a stack of huge hacks on the top of huge hacks. Developers are using HTML and CSS for purposes they were never intended (e.g. a WYSIWYG word processor), and doing some really gnarly hacks to make it all work.

Those gnarly hacks required to make their applications work prejudice web application developers against HTML and CSS, since they don't work worth a damned for those developers.

But HTML and CSS work remarkably well for what they were designed for: Documents.

Applications have, historically, usually been distributed in a different format than documents. Perhaps they should resume that trend; targeting the browser just being the OS, and leaving the document standards for documents.

My knee jerk response to the original article was, "this is making the web less free," but a bit of thought raises the question, "I can't interact this way with Microsoft Word, so why do I expect to interact this way with Google Docs?"

I don't, we are going to have hundreds of different accessibility and IME implementations, all with different quirks and bugs and many websites won't care at all so even writing letters with accents will be a hassle (if possible at all). Or think about websites assuming your keyboard layout is US QWERTY. Or websites not properly handling subpixel rendering or retina displays (and looking upscaled and blurry). Those are all solved problems with HTML and CSS that will have to be solved again, this time not by 3 rendering engine dev teams but by each web dev for each website.

It’s not like the w3c provides us all with rendering engines. We still use browsers which do it for us. If these canvas techs spread, everyone will rely on canvas framework toolkits that do it for them. Still not great for user power

Input methods are managed by the OS, the browser delegates control. It can't do that over a simulated input control rendered on a canvas. Also what I mean is that all these are problems already solved by browsers that follow w3c recommendations, custom rendering solutions will have to reimplement everything without access to OS APIs that make many of those things possible in a unified way.

Why? They are the best layouting tools we have to this day. Or do you want to go back to

  TextElement textElement = new TextElement(); 
  textElement.position(100, 100);
  textElement.color(Colors.RED);
  textElement.alignment(Alignment.CENTER);
  ...

and the likes? These kind of descriptional ui tools are horrible in my opinion.

We had layout managers by the early 90s, and Java was not the only choice. Delphi, wxPython, and Qt were/are pretty good. Do not use pixel positioning or hardcode colors was right in the docs.

I find those tools much easier to get a decent GUI layout with. Getting the same layouts with HTML and CSS seems to involve a pile of hacks, because they were designed as document markup, not button and panel layout tools. (that said, a markup system for constraint based layout would probably be better, and CSS does seem to be growing some of the features, it still just seems to be hard to get something that works as consistently as e.g. Qt).

...and yet we still have these things, like Gtk, Tk, ImGUI, some parts of Qt, etc, and they work reasonably well. I just spent time building a new widget set for small LCD screens (~160x40) and built the set in as simple a way as I could, and this was the easiest method to do so. Sure, it's not great from a designer perspective, but it gets the job done -- more or less what HTML + CSS do now, but (frankly) in a far less verbose way.

What would you replace it with? Keeping in mind that web pages are supposed to be accessible to people in the sense that anyone with an interest to do so can put up a marked document for display because it's displaying material, not programming an interactive environment. If you take away the accessibility of HTML from people, then you're also taking away a significant portion of the "open" Internet and moving toward a more closed corporate-curated model due to the higher barriers to entry if you want to publish something.

Let's not forget DRM. Now that framebuffer can be delivered via an encrypted EME module, thereby killing the open web permanently for the purposes of scraping.

Thanks a bunch, W3C!

I've watched a weird mix of "I don't like javascript" that usually actually translates to "I don't like what some people do with javascript." along side some cheer leading for webassembly...

Now those obviously aren't entirely connected arguments, but whatever "I don't like what some people do with javascript" is supposed to mean, it has nothing to do with javascript. It's just what people do with it.

Here we go now, we've got rando blobs you've got no idea what they're doing... this is not better.

Reminds me of the pain with Java & flash on the web.

What’s old is new again eh.

Not like you know what that obfuscated minimized javascript was doing anyway.

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 software back in the late 80s and early 90s but I'm not necessarily looking forward to doing that again.

> 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-source, only Chromium is open -- and we know Chrome has secret sauce in it not from the repos.

I didn't express that very eloquently.

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".

Wow, this is plausible and disgusting.

> and we know Chrome has secret sauce in it not from the repos

Does it? I thought they have pretty much identical performance.

It's minimal, not much beyond widevine and a set of hard coded API keys for things such as sync. The code that uses the API keys is all open source, only the keys themselves aren't.

Secret spyware sauce.

> "But accessibility!". A big company like Google can handle that just fine.

Given the problems Material Design has had, I wouldn’t make that assumption. And that’s a front-of-the-front-end part of the org.

Not Chrome. Chromium.

Chromium bundled with an option to run everything through Google/Alphabet infrastructure will make sure that the adds DO get through.

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.

Yes, 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.

I'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.

If 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.

Care to elaborate what “real ui frameworks” do better? What frameworks do you have in mind when you say that?

Sure! 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.

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 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.

Careful here, these are more like thin clients with high network latencies.

There'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

Browsers 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.

Funny. And then at some point someone will rediscover native apps.

I, for one, welcome our new canvas based overlords.

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 <dialog> is for? That's just HTML plus minimal JS.

No, I wasn't talking about that. Before getting censored. I meant a dialog with a form on it.

> 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.

“As a user, I want my apps developers to have a good experience” - a scrum task

> 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.

I offer Firefox as the solution.

Absolutely, 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.

Ah, 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.

> 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.

Is this canvas actually rendered with WASM? I don't see WASM in dev tools on their sample doc.

https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...

You're right, there seems to be only JS code running in this example... and it performs very well for me, actually.

Everything people were complaining about seems to work just fine, including text selection and Ctrl+F!

User preference and configurability of hyperTEXT display has been totally thrown under the bus, increasingly throughout the web's existence. I remember when it was straightforward to have your own text color and font preference, and web sites didn't try to override them. You could even configure a brick wall GIF background for sites if you wanted to. Now, these preferences are buried and easy for a developer to ignore using CSS and JavaScript. And as you say, it'll get even worse. The user agent (who, by the way, you're writing your web site for) now has very little say in how a web page is rendered.

Unpopular opinion on HN full of web devs, but I don't want my browser to be a "canvas" for some developer. I don't want it to be a "stable ABI" for some opaque binary app. I already have a platform for binary applications: It's called a desktop operating system. I wish more developers would go back to developing for that and leave the web alone. I want my web browser to display hyperTEXT documents, with links out to other hyperTEXT documents, and occasionally accept input from me via a FORM. And that's it. I understand that opinion makes me a minority nowadays, though. Maybe we should revitalize gopher or something--something to get back to the roots of fetching, displaying, and navigating information.

Ad blockers could still "scroll" through a website, run an AI model on it to discover the ad sections, and cut them out. Even a simple model that filters out visual animations and replaces them with a static would be useful as a large annoying component of online ads is the movement and blinking etc. that make it hard to focus on the content.

Dark mode etc can, too, be implemented to work in terms of framebuffers only.

But yes, unless there is a serious need, canvas rendering is a severe regression.

>run an AI model

what exactly would this AI model be trained on?

Ads? The suggested approach is "from pixels" so any rendered ad is a source of training pixels.

I've seen some rather atrocious techniques employed to bake ads into source but that can still be done without any performance impact. Making that work in WASM would require dynamic recompilation, doable perhaps for smaller apps but for behemoths like Gmail and Docs I couldn't see even Google getting that to scale. I think we'll still have browsers performing additional HTTP requests for that stuff, at least in the short to medium term. So traditional adblocking techniques will still be viable.

It will be like cutting out the ads in a newspaper. Lots of holes, everywhere.

The difference from a physical newspaper is that on a computer we don't have to leave holes, we can replace them with beautiful artwork or our favorite cat pictures. That's still a hell of a lot better than ads.

I'm ok with ads in a newspaper. I can ignore them safely and blend them out. Many online ads nowaday blink or do other dark patterns to make ignoring them harder though. I hate that.

Is there any ad blocker that blocks ads rendered within videos?

It's possible doesn't mean it's viable.

SponsorBlock does a surprisingly good job: https://sponsor.ajay.app/

That still defeats the purpose. I want the ads to be blocked from loading for performance reasons more than anything else.

WASM plus encryption will mean it could be illegal to decrypt/alter website code just like a Netflix video stream.

Adblock criminalization is close.

Adblock / pihole technical impossibility, too.

Maybe they could bypass it in Chrome, but it wouldn't make it impossible to use for anyone smart enough to set up a pihole.

The WASM code will eventually implement its own DNS analog (or use DoH with a pinned certificate). It'll all be completely opaque TLS to your Pi Hole.

Your Pi Hole is the same thing, functionally, as the tools a nation state hostile to human rights uses to filter the Internet. You'll get the same treatment that they do.

That’s when you install squid and have it do the terminating TLS. They won’t pin the certs, too many corps do this already and not to mention certificate lifetime is in the realm of leaving a browser open for weeks.

Deploying squid is not simple as deploying a PiHole.

DNS blocking is way more trivial to bypass than client-side blocking.

Have no fear, for the ads ARE already here.

* Want to watch YouTube ad-free on an iPhone? We've blocked every possible way unless you want to pay us - and we're still gonna spy on you.

* Not a fan of ads while watching TV? Well, tough luck. They're injected by the TV manufacturer.

* Want to pay for your content? Feel free to subscribe to Hulu, just don't expect ads to go away.

* Tired of seeing ads in Twitch? Well, Amazon sent legal takedowns to every successful ad blocker for Twitch - hope you're keen to write your own.

Sure sure sure: the techies here can workaround some of these. But your above-average person cannot, this has been normalized and is now _expected_.

I stopped watching twitch after Amazon took over. They changed it, it’s so aggressive and full of little dark patterns and micro rewards now to try and hook people

> 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.

Google is also a search company, the product from which the majority of their ad revenue comes. Blobifying the web indiscriminately breaks search, so it is not in their interest to push this to reap some x% revenue loss from ad blockers.

Incidentally, or not, a traditional wordprocessor itself is not an interesting search result and makes a perfect candidate for this type of rendering. There already exists compatibility layers with search for published documents. So absolutely nothing is lost for anyone, and I think it is an overgeneralization to take this as a sign of obvious doom to come.

Treating the web browser like a VNC terminal, a way to push pixels, is just a vile degredation of the web. The web is not applications. People view the web via a user-agent, a tool that let's them navigate & view hypertext as they want.

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.

> The web is not applications

Unfortunately, all the people who work on the web disagree. They need what could be a simple, text based site into a full blown "application" to justify their own job.

The web can do programmatic, interactive systems very well. In my opinion, it does it much much better than applications. And it should be doing it. (Alas, a huge huge huge amount of web applications don't espouse the virtues of the web, don't use url based routing, don't have good service worker caching, & countless other horrific faults. I continue to see that as not the web's fault but I think there's a lot of room for opinions on this, at least.)

But interactive web systems shouldn't regress to the hostile, anti-user, anti-extensibility stance of an application. It should continue to offer the upsides of being the web.

Google de-facto controls the browser but it doesn't control the OS, its motivation is absolutely transparent here: make the browser the OS. It even auto-updates transparently by default so Google can push its code almost live to its users.

As someone who always fought against the bloat of the web and reimplementing everything on top of HTTP and JS I feel a bit like an anti-atomic weapon activist who, upon seeing the mushroom cloud in the distance, can utter a final "see, I told you so!" before being demapped by a G-shapped shockwave.

The open web was fun while it lasted, but ads are more important.

Man, this is a very dramatic interpretation of their intent. Docs doesn't even have ads. They actually do have issues rendering consistently across browsers (I ran into this just like 2 days ago where something that had been carefully laid out on Chrome looked different in Safari).

My bigger criticism of this is that I imagine it was a very large refactor at a time when docs has barely evolved for years and still remains far behind desktop counterparts in many ways (although still slowly taking over because of vastly superior online collaboration).

Ahh yes because Google, an ad company, will never implement this where they do have ads.

I never said they would never do this. I just said it was over dramatic and making big assumptions that this action by google was part of some nefarious plot to turn the internet back into corporate tv, especially given that there are very good reasons in this case to make this change without those assumptions.

>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

As opposed to a world where huge, unintelligible minified JavaScript blobs are sent to the browser?

This is the endgame of putting JS/programmability (rather than just markup) in browsers at all. HTML and CSS are great for formatting documents. But, in spite of years of jQueries, Angulars, Reacts, Vues, and 10M other frameworks being implemented, HTML+CSS+JS is frankly awful for developing applications. Business needs have made us push them to be okay for enough form entry to collect credit card numbers and do billing stuff, but even then every step forward comes with a few steps back.

An optimistic take is that this should mean we get better web apps and less JS garbage on web pages where we just want to read something and there’s no justification for having code execute when you visit the document. That’s the intent of WebAssembly and it makes sense.

The reality is that the NYTs of the world will continue to put JS garbage all over pages that have no business executing any code. But WebAssembly doesn’t really have any bearing on that. It offers the opportunity to make things better. The organizations who seek to profit off the web and make it worse for the rest of us will still do so, with or without WebAssembly.

I hear this take a lot. Why is HTML + JS awful for developing applications?

It wasn't designed to, it grew bit by bit with new features gradually being tacked on, so the APIs are inconsistent (For example,NodeList, HTMLCollection, and Array all have different methods and naming conventions) and poorly designed.

I literally had the same thought when I first heard of WebAssembly. Adblockers blocking your tracking JS/Cookies? Why not pass it via a binary blob though WASM and track the users? I know WASM is a boon to performance sensitive websites, but there are always players who would like to take advantage of the situation.

You could do that years ago when canvas was introduced. Wasm is more readable than obfuscated JS. You can compile C to JS.

Web scrapping. Companies will just push their data to the giants. I did not read that sequence when I first heard about wasm. You made me sad.

Of course there will be scrapping, using machine learning and GPUs and whatnot but it's... maybe I'm just old.

Do you mean scraping? If you meant scrapping, I certainly don't think the web should be scrapped.

JS minification is old hat, and welcome to shrink binaries.

Google for security reasons should probably release the source. Most security types welcome web-assembly over JS since there will be more Rust etc.

> I didn't expect the first move towards canvas-only rendering to be traditional wordprocessors.

Google Maps moved to Canvas/WebGL years ago. It's not the first move.

We've come full circle. This could've been done decades ago, with Java applets.

> turns the web back into cable TV.

You mean turns the web back into Flash. Which is somehow worse.

How are they going to make this accessible? I doubt any screen readers would be able to recognize text drawn that way.

Agree on all points but

> Font rendering and layout can all easily be accomplished by embedding libraries like freetype.

Whoooah no. This stuff is way, way, way harder than dropping in freetype.

I don't blame them, considering how damn hard it is to center something with CSS. With a canvas you just tell it where to display it and to hell with CSS.

> Font rendering and layout can all easily be accomplished by embedding libraries like freetype.

Perhaps it's not so simple if you want the GPU to do the rendering.

> I didn't expect the first move towards canvas-only rendering to be traditional wordprocessors.

It makes sense. Rich text editing on the web is a disaster.

You are completely correct. The end goal of people who introduced WASM was an ActiveX 2.0.

I don't like this change, but it's not being done to "control to web".

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.

How does it help here? They can trivially include ads server-side, pi-hole would see nothing at all.

You can do it, but it’s not done commonly. The most common way ads get onto the page is by including a third party script which is easily blocked.

Today, but this entire discussion is about how things will work tomorrow.

It would be easy to implement server-side rendering, but it carries significant cost in processing time and networking. If they can block all adblocking browser extensions by abusing WASM, the cost of server-side rendering will outweigh the 0.0001% of people that have a pihole set up.

Can you target "opaque binary blobs of code" with a pie-hole?

DNS over HTTPS and, eventually, certificate pinning in the WASM-based DoH client running inside your browser will render your Pi Hole useless. It'll all just be opaque TLS to your network gear. Network operators who legitimately need to control traffic on their networks are lumped in with human rights-violating nation states. That includes you on your network.

Can you substantiate any of that? DoH is a feature of the browser that can be configured or disabled. Firefox even disabled DoH automatically if it detects you are using a custom DNS server which blocks "potentially malicious content"[1].

[1] https://support.mozilla.org/en-US/kb/firefox-dns-over-https

I'm not talking about the browser doing the name resolution. I'm talking about the opaque binary running inside the browser doing name resolution (either by way of DoH with a pinned certificate, or a custom name resolution protocol running over TLS). You won't get a say in what that opaque binary does (w/o modifying it).

Is anybody doing this now? I doubt it. Will somebody do it? Yeah. Definitely.

When the "browser" is an embedded device (like Google Chromecast devices hard-coded to use 8.8.8.8 for DNS) you'll have no configurability there either.

There’s a place for DNS based ad blocking like Pi-hole or NextDNS and a place for first party ad blocking and element blocking (and even script blocking) using uBlock Origin, NoScript, etc. They’re complementary in certain ways.

Pi-hole wont protect you here, they will send the entire page, ads and all as an encrypted binary blob. Decrypting it is illegal, and since the data is coming from a single source Pi-hole can't block it.

Pi-hole (and ad-blocking) days are numbered. Hopefully that day is further out than I dread.

Decryption is illegal? Lol what?

I think they're implying DRM laws associated with the data-streaming.

I have faith that that's only a matter of time before somebody makes a patch that just does the decryption without fuss.

Wait, how is decrypting the WASM blob illegal?

I should have chosen my words more carefully, but the blobs with ads will have some sort of DRM on them, which is technically illegal to decrypt and cut out.

Removing DRM on something you own for personal use is perfectly legal.

You don't own the Google Docs service, nor will you own any webpage you are served.

> Removing DRM on something you own for personal use is perfectly legal.

Perhaps some places. In the US, it is perfectly legal to "violate" copyright restrictions for purposes like fair use. But if the data is protected by any kind of security, it is a felony to bypass that security (even for fully legal purposes).[1]

[1] https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_A...

What does security mean when there is no ad unless it is shepherded out of the blob? Once it's out of the blob, there is no security to bypass.

I fail to see how DRM is related to WASM

Seems the choice would be not to execute the DRM-protected blobs at all.

When ad blocking on web becomes impossible/nonviable, I will retreat from using it, as I have retreated from using most popular sites, unless absolutely.

I already don't have a TV, don't have any news apps on my phone, don't have any newspaper subscription, and I find that all the important news find their way to me no problem. I will add large degree of WWW to it and be mostly fine.

Its already possible to have server side rendering bake in ads on web pages, but just about nobody does it. I think the percent of people who know about pi-Hole vs the cost of server side rendering will always make client-side rendering the optimal choice for the people running the websites. They can block adblocking browser extensions, and that will be enough for them.

That's because the ad networks require a level of validation of their views that they prefer to have control over with javascript snippets or pixels.

But it's technically a bit different, since an ad-blocker could still block those baked in advertisements while it's traditional web technology. If it's a binary blob rendered with canvas, that won't be true anymore, which I think was what the parent comment was getting at.

> If it's a binary blob rendered with canvas, that won't be true anymore.

The request for the ads will either happen server side or client side. If it happens client side, it can be blocked at the network level by the pihole regardless of whether a blob or js script is making the request. The request happening server side is unlikely per my previous comment.

Your previous comment doesn't explain a reason why it would be unlikely, just that it isn't. The reason it's currently unlikely is because ad-networks need to validate their views. Because you can ad-block on HTML alone, it isn't worth it to risk webmasters falsifying serverside views in order to try and get around ad-blockers because it wouldn't work. But add the ability to get around ad-blockers entirely and it becomes worth it to solve for server-side view validation.

This is the landscape as I see it:

HTML, ads loaded by user network: Can be blocked at network or in HTML.

Binary blob, ads loaded by user network: Can be blocked at network level

Serverside ads, HTML : Can be blocked by removing the ads in the HTML, and ad-networks don't like it because their views can't be validated and they could be scammed by webmasters.

Serverside ads, binary blob: Can not be blocked by network or by hiding things in the HTML, ad-networks and webmasters would want this because they can get around ad-blockers, but will need to solve view validation, the tradeoff becomes worth it.

> The reason it's currently unlikely is because ad-networks need to validate their views.

Ad-networks also want to validate views because they don't trust the hosting website. They don't need to trust the hosting website's server when they can receive a direct connection from the client.

However, there is an alternative that fits "serverside ads, binary blob" scenario: the ad-network hosts the website. Obviously the website owner wouldn't want to turn over control to the ad-network, but they don't get a choice when they depend on the ad-network for revenue. Even worse: this isn't a hypothetical concern. Google already tried to implement ad-network hosted websites with "AMP".

It has to be decrypted at some point to be viewable, so if you have system administrator access to the OS and device your browser is running on, someone will figure out how to identify which pixels and which audio bits are ads and block them from making it to the frame buffer (and whatever the equivalent is for a sound card). Where there's a will there's a way. There has just not been a need for that yet.

It's just an arms race, and the makers of uBlock Origin will need to level up and figure out how to do some serious computer vision and heuristic anomaly detection.

A proxy can do very little to actually block ads compared to what a web browser can do. Web browser _is_ the right place, or at least it is the only place where you can actually do something intelligent to block ads. For example, if you are blocking ads at a proxy, it is trivial for site owners to detect it and then your filtering proxy can literally do nothing to compensate. A huge chunk of all the filters in adblocking lists are basically to defeat anti-adblocking functionality...

Is ad blocking Google Docs really a concern though?

No, but how much longer do you think it will take them to bring this to Google and YouTube and AdWords?

Honestly if they did that I think I’d strongly consider paid alternatives to YouTube. Most of the channels I like are on curiosity stream/nebula. I’ve never subscribed because I don’t feel like I have a reason to. But that would definitely give me a reason.

Or you could just pay for Youtube which removed ads.

I’d rather not support a monopoly

i think the worry is more about the next steps, not google docs per se

Reply on news.ycombinator.com