151–160 of 226 posts
Earlier quoted context omitted.
> Nothing worked right. One thing worked right: the app looked the same and acted the same everywhere where it could run.
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.
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
> 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 WebAs…
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.
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.
Earlier quoted context omitted.
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 t…
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
Earlier quoted context omitted.
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
Adobe Flex was interesting and not awful. The problem was the runtime.
And the company behind it. Who remains awful.
Earlier quoted context omitted.
…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 ca…
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…
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?
Earlier quoted context omitted.
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.
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 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.
We seem to be on track for the 2035 timeline in https://www.destroyallsoftware.com/talks/the-birth-and-death....
Earlier quoted context omitted.
> Nothing worked right. One thing worked right: the app looked the same and acted the same everywhere where it could run.
That’s a bug, not a feature. Apps should match the OS they’re running on.
Earlier quoted context omitted.
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:…
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.