Hacker News Reader

Comment by JimDabell | Hacker News Reader

The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. They treated the web browser like it was just a way to run executables in a window.

Nothing worked right. Bookmarks, search engines, command-line tools, user preferences for font size, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links… you name it. The more conscientious developers tried to reinvent some of this stuff on top of their own system, but it never worked quite right.

One of the main strengths of the architecture of the WWW is that it isn’t merely a mechanism to ship executable code. It uses the Principle of Least Power, which ensures that you don’t have to execute code to understand what’s on the page. And a huge proportion of the utility of the web is derived from that principle.

https://www.w3.org/DesignIssues/Principles.html#PLP

If you only see the web as a way to ship no-install executables to people, you’re missing out on basically everything that makes the web what it is.

View on HN

This is exactly how Flutter (now) works on web - the browser loads a JS/WASM blob, and your app renders everything to a canvas - and you're right, almost everything you mention is problematic.

There is a time and a place for that paradigm, but it's niche. The lack of SEO alone is usually enough to stop it in its tracks.

Flutter even had a DOM renderer which should in theory have fixed approximately all the issues (I don’t know for sure, I never knowingly encountered anything using it), but they’ve killed it off fairly recently, doubling down on the fundamentally unfixable direction that is the pure-canvas approach.

They still seem to have something, from this page: https://docs.flutter.dev/ui/accessibility-and-internationali...

* Inspect the HTML tree containing the ARIA attributes generated by Flutter.

Wouldn't that help with SEO as well?

That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it: you can’t poll if it’s needed. All you can do in that case is to present screen reader users with a “this page is currently empty, press this button to unbreak it” button. (Aside: I’ve seen that done once. And the button was broken.)

But the problems we’re talking about are far broader than “does my screen reader work”. Do my links work properly—Ctrl+Click, middle-click, long press, hover? (This one is fixable with only mild compromise. Those that follow are not.) Does my text render correctly? Can I select it and use my browser’s context menu or other similar tools? Does content scroll properly, at correct rates, with correct inertia, without jank or at least a frame’s latency? It’s these sorts of things that Flutter’s pure-canvas approach cannot fix, and they affect, in smaller ways, a lot more people.

I’ve written more specifically about the problems here on HN quite a few times. Search and you’ll find ’em. I really should get down to writing a detailed article about it all at some point… it’s been quite a few years.

No, performance and fidelity are definitely better with the canvas renderers, especially skwasm. Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm. The issue is that this doesn't map well to the DOM. You can't rebuild cheaply on the DOM because you'd be constantly updating the DOM. And you don't profit from your simpler layout, because you have to implement it in JavaScript and use absolute positioning on all DOM Elements to lay them out.

I do agree that this all absolutely sucks for websites, but if you're building an App that is supposed to run in the browser like Rive or Figma, where you're going to override all click handlers anyways, or where where what you're rendering would be too much for the DOM, Flutter Web is pretty ok.

I'm sure this is tried (I've done it myself), but a hybrid approach would take best of both worlds; heavy rendering on a canvas, the rest as SVG/DOM elements.

Even this relation can be inverted: to speed up SVG interactions, I pre-render complex path and text elements at a sufficient resolution, which are shown during transitions/user interactions, but replaced with the SVG original elements once the render loop settles down again.

I went and loaded up the flutter web demo on my iPhone 15 Pro https://flutter.github.io/samples/web/material_3_demo/

In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.

Wow, you weren't kidding: same phone and it feels like I'm using a 15-year-old Android. That's rough.

> unable to select text

Because of this alone I would not use.

It's just not the default. As the developer, it's trivial to make text selectable.

I meant it as an user.

Fair. If that's the deciding factor on whether you use a computer program, that's your prerogative. I assume, then, that every app on your phone allows you to select every bit of text in it?

Cool. Was hoping to discuss the different expectations we have for a program obtained through a web browser than one obtained through an app store, but I guess downvoting is easier. ¯\_(ツ)_/¯

If the developer has decided you are not allowed to, then you can’t really blame the tool he’s using…

I do not blame the tool, but I will avoid using it as long as I am unable to select text.

Additionally, see: https://news.ycombinator.com/item?id=43215065

You can make text selectable, but it still won’t behave at all like normal text. Selection word boundary things won’t match the local platform behaviour, touch behaviour cannot possibly work properly, things like context menus won’t work properly, and more.

The only way you can get the proper behaviour for these things on the web is to use actual DOM text. Some parts of it could in theory be made possible, but I doubt that anything meaningful will ever change—it’s too antithetical to the nature of the web.

"Proper behavior"... You've defined this term as the precise behavior of the technology that Flutter aims to supplant.

Indeed, Flutter will never do everything "properly". But that's not its selling point. It doesn't need to, as long as the number of users reached from a multi-platform release outweighs the users lost because they were offended by a missing native feature. (Assuming you're not some massive company developing a parallel app for each platform)

You should not blame your lack of knowledge on the tool.

> But the problems we’re talking about are far broader

No. You're fundamentally misunderstanding the broadness of the web platform.

On a broad platform even niche use cases are common. If I'm developing an application that will be used by 50 users then none of your concerns are relevant. I know my user base and I know what I need to achieve.

If compiling to WebAssembly and using canvas makes the most sense then that's what I'm going to do, especially if it means I can make use of existing business logic.

It is precisely the broadness of the web platform that makes this possible.

Yeah, the strategic direction of flutter feels like the famous "embrace, extend, extinguish" approach. All the big companies prefer walled gardens.

Flutter is 109% open source

Flutter is unique because it is a cross platform canvas renderer with huge number of components built on top. Sort of, there are libs like QT but nobody wants to deal with C++ for GUI apps, and even the bindings leak C++isms last time I checked.

Rendering Flutter to DOM sounds like a huge effort bound to fail on some level - just use React and React native if you are leaning in that direction. Im sure Flutter can add some shims to get basic stuff like navigation working to be more web like.

Hasn't SEO been dead for like 10 years? It's not as if there's a search engine you can get to the first page on without paying, so why waste ad dollars on stuffing SEO garbage in your page and chasing the algorithm when you can just buy ads, if that's what you need? And does anyone find anything anymore by doing generic web searches anyway?

It sucks if you are non-profit working on subjects like drug abuse. Or anything that is considered "difficult" for our ad-overlords and thus all the relevant keywords are against ToS.

Not sure what nonprofits you're referring to, but most drug searches are SEO spammed with godawful websites that contain tons of misinformation while reputable sources that actually promote harm reduction like erowid are pushed down.

I was excited about Compose Multiplatform Web too, until I realized it also does this : everything in a canvas

I'm ignorant on this - but are there browser APIs that make it possible for the dev to integrate testing and accessibility tools, such as screen readers?

If not, this sounds like a major oversight, and basically kills accessibility dead in these software and makes testing pretty painful.

Yes, browsers expose APIs to accessibility tools

Wow, they still render to canvas? That's terrible. Just looked at this website: https://payamzahedi.com/toastification/

Feels janky just when scrolling. This is supposed to be the future?

Last time I used a flutter app they didn't even update the url for different screens.

The goal isn't the wholesale replacement of html webpages. I have a traditional website for SEO and such that links to my Flutter game app on the same domain. It's exactly what the parent described: a way to ship executable code. A lot of features supported for websites don't work, sure. But that's not the point. It's a single build that practically any user on the planet can execute without needing to install something.

The idea that an app distribution method needs to natively support every feature and analysis method that works for a website is nonsense. You don't expect all that from every app on the play store, for instance. The browser isn't just for visiting html websites anymore. It's also the app distribution method with the widest reach.

On your specific complaints: it's easy to make your screens have different urls. An app that doesn't is built by a novice or lazy developer.

Skipping frames while scrolling is a fair complaint. In my experience, flutter is performant enough but always just a little short of the performance I'd like. Definitely an area that could use improvement.

It's using a Flutter web build that's over 2 years old. We've gotten a LOT better.

Context: I'm a product manager on the team.

I'm shocked every time I use a Flutter web app. Not even one of the highest-end desktop GPUs on the market is enough to animate a dark mode toggle at more than a choppy 2fps. In one app with a login page, my password manager fills out the password into the username field, though I'm surprised it's able to fill anything at all. You'll be lucky if you can even select text on the screen or copy a link, though I know some websites would love if they can prevent you from doing that at a technical level. Text editing feels sluggish and doesn't behave the same way as standard web text fields when using advanced keyboard controls. I'm thankful that technologies like Flutter never took off on the web, and I hope they never will.

Coopting the web as a low level platform, to be bent into blast utterly non web stuff feels like a gross misdeed to me, that directly violated rfc8890 "the internet is for end users".

Flutter or somethint similar maybe possibly perhaps might some day conceivably eventually rebuild enough platform that the major gaps and faults and chasms of it might be less terribly ruinous, but users will never have anywhere near as much agency. User scripting will always be at the extent the developer's enable it. Its terrible to think of the web denigrated to being as closed foreign and black box as regular apps are, would set back human conputing's one little tenous bridge of progress back immeasurably.

None the less, theres folks who believe the developer experience trumps all other concerns, and are still full steam ahead on canvas based systems. One of those people is Ian Hixie, former editor of the HTML specification, who authored what is sort of the manifesto of the canvas-based effort, Towards a Modern Stack,

https://news.ycombinator.com/item?id=34612696 https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...

Plz plz no.

Sounds like his viewpoint is someone burned out by all of his prior work coming to seeming naught

https://news.ycombinator.com/item?id=34622514

We have this back, thanks to WebGL/WebGPU/WebAssembly I can have all my beloved plugins back.

https://opensilver.net

https://cheerpj.com/

https://cheerpj.com/cheerpj-applet-runner/

https://leaningtech.com/cheerpx-for-flash/

And on top,

https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

https://flutter.dev/multi-platform/web

https://unity.com/solutions/web

https://playcanvas.com/

This is the only place where I am actually happy about WebAssembly's existence.

The difference between now and then is that people back then wanted bookmarks, search engines, CLIs, user preferences, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links and so forth. While some of us still do, the great mass of web users now just want TV on their smartphones: they want an attention-consumption device to distract them from real life.

Flash never took over because a lot of us then wanted our computers to work for us; Javascript and the read-only web are succeeding because so many now don’t mind being farmed for their attention.

People still want all those things.

I launch Chrome with a bunch of flags to disable security and have a bunch of client scripts to override websites. I'm this close from creating my own browser based on Chromium

Can you share more about your setup?

Ajax, not even once

This is the same tale from technologists about how all the other Web users are just drooling morons who want to connect their brain stem directly to the Matrix. With the only relevance being the rose colored glasses of when the Web wasn’t (apparently) used by the Untouchables.

Web technology: made either by and for tech. enthusiasts or techies who hate your guts.

I'm not sure why it can't be both. Given the current walled environment of app stores, web pages are a much better way to ship apps across platforms. That doesn't have to detract from the native function of www. Should you make your client's website an inaccessible blob of interpreted bytecode in 2025? Probably not. But can you embed an awesome game inside it with some weird custom UI? Why not!

www should be split in documents and apps it is horrible that we mutilate html, css and js to make a document language work for application.

And I bet competent developers can create a GUI framework that is more accessible then the div soup that the SPAs use today.

> Nothing worked right.

One thing worked right: the app looked the same and acted the same everywhere where it could run.

WHich was... only windows computers since Flash barely worked on Macs or Linux, and never properly made it to mobile, where it was also a complete battery drain when it did in fact do things... sometimes.

Eh.. lots of projects targeted mobile app stores by authoring in Flash and using the GPU accelerated stuff. Starling was a semi-blessed framework. Worked perfectly well, no battery drain. Lots of "native" apps were authored that way (and still are, you see the same approach with Unity etc.)

Browser plugins could have been fixed to catch up, the VM itself wasn't the problem in terms of drain

Not my recollection at all. Adobe invested almost 0 effort in getting their runtime working on non-x86 platforms. It was pathetic, honestly, how many years passed before they had any kind of passable implementation there.

Adobe Flex was interesting and not awful. The problem was the runtime.

And the company behind it. Who remains awful.

Do you remember Angry Birds? https://villekoskela.org/2012/02/15/angry-birds-facebook-rel...

I have different memories from before 2012. Flex apps I built were used on all 3 and worked flawlessly in AIR. Looked and behaved exactly the same everywhere. Indeed, though, barely made to mobile. But Nokia N95 was pretty cool.

What was the process of installing AIR like on Linux?

I really don’t know. Back in 2009 I was contracting for this company in Worthing. They have a US location in Florida, and are selling aircraft spare parts. I have built an application in Flex for them which was used for taking all sales orders, place purchase orders, manage clients, suppliers, stock, and invoice by people on a call floor. It was great, it worked in every browser where Flash Player could be installed. When AIR came out, in became a standalone application with a wrapper loading the swf file generated for the web app. It worked on Windows and Mac, Snow Leopard back then. It was great, app could be updated by making the new swf available for download on the local network, and waiting for users to restart the app. They did that twice a day: when going to lunch, and when going home. The app remembered everything they were working on. It was great.

It took us good three years, it was eventually feature complete and used by 120 people on two local installations synchronised back then with Dropbox (hey, I didn’t know any better and it actually worked great over a hurricane m). We have replaced a home-grown COBOL app.

No, that definitely wasn’t the case. Things that worked fine as Flash on a Windows machine could render weird on a Mac or Linux. They definitely claimed this though.

Adobe Flex and AIR were two of the best technologies I ever worked with.

That’s a bug, not a feature. Apps should match the OS they’re running on.

It was a feature for me. Especially in the Flex 3 era, and when AIR came out. That was truly magical period of time.

It's 2025 and most apps do not match the OS they run on. What would you even want apps to match on Windows? There are different styles depending on what you build with (Win32/Forms, WPF, UWP, etc).

I'm painfully aware. Modern apps are mostly terrible.

I don't know or care what apps would match on Windows. I don't use Windows. On the systems I do use, I want apps to look like they fit in.

I've never understood this "every program on my device should look like the same company designed it" mentality.

Nothing against using the pre-built ui components provided by the OS, but looking down on a developer that decides to use something else? Just weird to me. A checkbox is a checkbox, it really doesn't matter whether App A's checkboxes look identical to App B.

Now, if App A's checkboxes look different than App A's other checkboxes, then I'll complain.

It's mental overhead; if App A's checkboxs look different than the ones in App B, then I have to switch that mental context every time I switch windows. If everything uses the same controls, then that consistency means users don't have to think about the controls.

Having things look the same makes everything easier to use. I know exactly what's clickable and what happens when I click them, instead of having to figure it out each time.

I don't understand why you'd be annoyed at different checkboxes within an app but not at different checkboxes between apps. Do you only ever use a single app? I constantly switch between many apps.

More importantly, having things behave the same makes everything much easier to use. If your checkboxes don't work the same way as the standard ones (and yes, this is a thing that happens) then that's a problem.

In addition to intentional behavior differences, you also have bugs. For an example close to my heart, Slack often loses its mind and destroys my input when I try to use the Undo functionality. This sort of bug would be impossible if they just used the standard UI widgets built into the OS, because the OS's widgets have competently implemented undo.

I love it when someone's example makes it clear that they have no idea what they're talking about.

OS Widgets don't implement undo. Undo is inherently tied to app state and the developer is responsible for managing it. At most, the OS will give you an undo button/icon and you can use it to fit in visually.

Frankly, building a separate version of my app per platform to conform to your nativist standards is a huge waste of time. My UI will work across all target platforms. If you can't figure out interfaces that aren't straight out of an Apple/Microsoft design document, that's on you.

Bullshit. Undo in a macOS text entry box is part of the widget’s implementation and you get it for free. It doesn’t need to be tied to the app’s state, since it’s just working on the text you put into the box.

Have you actually built any native macOS apps? I have.

Ah, my apologies. I thought you were talking about something like an undo button, rather than cmd+z within a particular text box.

Sure, point taken. Native widgets might work differently than cross-platform ones. That said, there's no reason a cross-platform widget couldn't work identically to the native one.

Indeed, a platform's native widgets an effective way to give users a consistent style and functionality across apps from many developers.

Yet, as a one-man dev team, the cost of building a separate version for each platform is prohibitive. The choice is to disregard most platforms or disregard a small corner of the expectations each user has for apps on a given platform.

The choice was pretty obvious to me.

Sure, I won’t dispute that it saves time to build apps this way, and that may be the right choice. But the results still suck and I still don’t like them.

Ironically, out of the apps I use regularly, the ugly, misbehaving apps built with cross-platform frameworks are from big companies that could easily afford to do it right, like Slack. The apps I use that come from small indie developers are all native. I suppose this is down to competition. I tend to have a choice for those apps, so I can choose ones that work the way I like. For Slack, my choices are to use the app, use it on the web (same as using the app, more or less), or find a new job at a company that uses something else.

> The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash.

WebAssembly is different. WebAssembly brings every language to the web. Flash didn't.

WebAssembly can render to canvas and enable applications that compile to desktop, mobile, and the web. UI libraries like Avalonia do this: https://avaloniaui.net/

For example, here's C# implementation of Visual Basic 6 compiled to WebAssembly https://bandysc.github.io/AvaloniaVisualBasic6/ and source https://github.com/BAndysc/AvaloniaVisualBasic6

And a Solitaire demo https://solitaire.xaml.live/ and source https://github.com/AvaloniaUI/Solitaire

But WebAssembly applications can also manipulate the DOM like JavaScript. Example frameworks that do this:

- https://www.leptos.dev/

- https://dioxuslabs.com/

- https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

DOM access goes via JavaScript glue code for now. Eventually WebAssembly will get direct DOM access.

You can decide if you're making more of an application or more of a webpage. If you're making more of an application then why not just render to canvas with WebAssembly? And if you're making more of a webpage then why not have WebAssembly manipulate the DOM instead of JavaScript?

And for non-web uses, WebAssembly can be used in a plugin framework such as Extism:

https://extism.org/

…and yet we still do not have the streamlined authoring experience we had with Flash. The stuff you show is just a crappier way to write boring GUIs with some other language for which you need to download the runtime. Flash let many more people create far more fun stuff than any Web standard ever did.

People forget that Flash also brought C/C++ to the web at some point, but besides some flashy demos, nobody really cared.

The problem is that all this choice creates fragmentation, you have dozens of platforms within a platform on top of another platform. Web APIs and Javascript may suck in many ways, but at least the are a common denominator.

> and yet we still do not have the streamlined authoring experience we had with Flash.

Uno for example has a visual designer: https://platform.uno/hot-design/

> The problem is that all this choice creates fragmentation

That's not a problem. Build things the way you want in the language you want.

This is a great point... the fragmentation and the steep learning curves for each stack (and constantly needing to be on top of breaking changes deeper in the stack) all amplify each other and make it much more difficult for amateur designers to build and ship something. Back in flash days, I knew lots of cartoonists and graphic artists who could build interactive experiences on their own that they wanted to put out there. That basically does not happen at all now.

I'm pretty sure Flash (Stage3D) was also the first way to leverage a GPU on the web... for those of us who wanted to go a bit deeper...

Second try:

Hi noduerme, I'm the guy who wrote the original 'Kaos'. I stumbled upon the discussion about it, and have no idea how to contact you besides commenting here...

Any way I can message you?

Hi! I've temporarily put my email contact in my profile here...

Got it!

> WebAssembly is different. WebAssembly brings every language to the web. Flash didn't.

The problem with Flash was not that it only supported a single language. The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.

> But WebAssembly applications can also manipulate the DOM like JavaScript.

Flash could do that too. Virtually nobody bothered.

> The problem with Flash is that it opted out of the web architecture

WebAssembly doesn't. WebAssembly is part of the web's architecture. It has been for 8 years. You've doubtless run WebAssembly without even realizing it.

Google Sheets for example uses WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc

Amazon Prime Video uses WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-...

> Flash could do that too. Virtually nobody bothered.

But virtually somebody is bothering with WebAssembly.

I know how WebAssembly works. You don’t need to explain it to me.

Take a look at the article. It’s specifically advocating for:

> So throw out all the web standards. Make a browser that just runs WASM blobs, and gives them a surface to use

And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `<canvas>` the executable code draws into.

This is exactly what I was complaining about:

> The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.

> And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `<canvas>` the executable code draws into.

What does that have to do with running the application? What user is going to inspect the elements of a web page? No end user will. Developers will, but that's got nothing to do with running the application.

You can always go ahead and disassemble the .wasm file just like any other executable format. Here are some tools: https://github.com/WebAssembly/wabt

If you're worried about understanding how an application works, remember that most of it is on the server side anyway. You won't have access to that. And if anything, WebAssembly puts more of it on the client side.

> WebAssembly is part of the web's architecture.

It’s formally part of the web’s architecture, but it is bolted on and violates the fundamental principles underlying the web’s architecture. It’s much like a worse JavaScript in that way.

> it is bolted on

WebAssembly is no more bolted on than JavaScript is and JavaScript has been part of the web for 29 years.

> violates the fundamental principles underlying the web’s architecture.

Which ones?

The issue isn't the scripting language, it's having a common interface for users, especially for those who can't use standard browsers. Rendering the application yourself will break every accessibility tool that relies on being able to interact with a programmatic view of the website.

Wrong, Flash was in the process of doing exactly that.

https://adobe-flash.github.io/crossbridge/

Before asm2js was even an idea, Unreal compiled to Flash via CrossBridge.

https://www.youtube.com/watch?v=xzyCTt5KLKU

https://www.youtube.com/watch?v=ZmZS7B1pLWg

To this day, with exception of maybe PlayCanvas, there are hardly any tools that can match the same developer experience for WebGL, almost 15 years later.

> Wrong, Flash was in the process of doing exactly that.

Except it didn't succeed at it. And Flash is long dead now.

WebAssembly is here today and supports more languages than Flash ever did.

Because of Steve Jobs, followed by Chrome NaCL, superseded by PNaCL, that Mozzilla refused to adopt pushing asmjs instead, and having everyone to agree with WebAssembly, still a shadow of Flash developer tooling experience today.

And for what, now that Firefox is mostly irrelevant and is Google for all practical purposes calling the shots on the Web and related standards.

Don't mistake technical capabilities with political games.

> Because of Steve Jobs

If one man, on a whim, could destroy Flash then Flash deserved to die.

> And for what

For a royalty free platform that everyone is free to implement. No one wanted to be beholden to a proprietary platform they'd have to license from Adobe.

That man closed the Apple ecosystem doors on Flash, naturally he was not alone, he had an horde of followers.

It remains to be seen how much royalty free Chrome remains, Web is now ChromeOS, with exception of a little Gaulish village called iOS.

> That man closed the Apple ecosystem doors on Flash

Which is exactly the point, isn't it. Adobe's business model around Flash was so fragile that he could do it.

He couldn't do it to the web.

Ever heard about all those ChromeOS features that Safari is not supporting and how PWAs are a failure?

How is that WebGL 2.0 experience going on iOS?

Ever wondered why after a decade there is hardly any WebGL game that can match any serious game done with OpenGL ES.3.0 on mobile phones, starting with the famous Infinity Blade?

And this explains why Flash is dead? WebAssembly lives on. Embrace him.

WebGPU will make you happier.

Provided I am using Chrome.....

Thing is - it’s even worse when people sit down and create actual real alternatives to desktop apps in a document distribution system.

For apps, Canvas is the solution. For pages - DOM.

While some of this is true, some of it is not (deep links worked fine, there was a brief time where hidden html was encouraged and worked just as well for search engines to pick up, etc.)

More to the point though- Flash didn't shine as a regular website thing (Adobe people used Dreamweaver for that, if anything). It was a game/application development tool. Most of the time you didn't need any of these web-friendly things, same way you'd expect every game to have a different menu system.

It was an awesome time for innovation and creative thinking. Not everything is a flex box. I miss those days

I agree with everything you said but at the back of my mind is the knowledge that the previous Flash ecosystem was capable of an experience we still don’t see today, despite its many downsides.

I don’t want public facing web sites to use stuff like this, or Flutter. But some intranet internal tool… eh, fine.

Reply on news.ycombinator.com