Something is wrong with the web version and also with the website https://dahliaos.io/, links don't open. JS sites that don't work in Firefox, right? That's not a great start.
It does look interesting though. It's an UI for Fuchsia or Linux, with containers for the other system?
To be honest i don't know what i am looking at, it looks like it might be something fairly impressive but sort of could do with a link to a page explaining what it is rather than straight to it
Hmm... on my mid-2014 13" MBP (which is completely fine otherwise) performance is so bad that this doesn't really make me confident that Flutter is "the future". Even just dragging windows around stutters (it feels like somewhere between 5 and 10 FPS). Is "native performance" comparable to the web version or dramatically better?
Flutter... stutter... maybe the Flutter team was trying to tell us something all along ;)
I think this is using the HTML renderer. On any other platform it would be using Skia and should be faster. The author could compile the app using Skia on WebGL potentially giving a speed boost.
My experience with Flutter has been a lot better than what this website demonstrates. I'm not sure how much of the stutter is to be blamed on Flutter and how much is to be blamed on the code architecture of this website.
This website is definitely running at 20-30fps max on my phone, whereas 60fps seems perfectly maintainable on my own Flutter experiments with web apps.
Having said all that, I'm still miffed about the extreme reliance on Javascript modern web applications have. With the ease of use Flutter promises for making web apps, I can only fear the slow, janky mess that websites will become if the platform ever gets taken up as quick as Flutter seems to hope it will.
Why? At this point, the browser is mostly an app runtime, so I don't think avoiding HTML and CSS is necessarily a bad thing. With some tuning it could even be faster, although I don't think any project has gotten to that point yet.
Because of the sheer amount of effort that browsers have put into solving all sorts of tricky problems, such as internationalization and accessibility. Once you try to render your own text inputs, you're committing to replicating a mountain of functionality. HTML is deceptively simple.
HTML, the dom, css and JS in browsers are far from simple. IMHO we’ve been tacking on more and more “application stuff” on top of a document viewer since the mid 90s. The whole reason React and other virtual dom frameworks exist is to wrangle the original document viewer into an application platform.
Yes, after all those years browsers are top notch when it comes to accessibility, but it comes with lots of additional complexity.
I am hopeful that with things like WASM and Canvas we are finally starting to move away from this document-based paradigm towards more app-focused paradigms.
Although there is still lots of work to be done to make approaches like this work with accessibility tools.
Sometimes i think that we are deliberately not adding dom support to wasm in order to not make the same mistakes we did when trying to make html/css/js suitable for apps.
That framing makes sense. I've always thought the document model was poorly suited for modern applications. I'm still not sold on canvas itself being the solution - I'd rather open up the underlying accessibility/i18n tech so that developers don't have to reinvent the wheel. But yes, otherwise agree with you.
My ideal solution would be that we can add accessibility apis to canvas. That means we can write GUI toolkits in any language compiling to wasm using canvas apis. Those toolkits gain accessibility support through canvas.
edit: some toolkits already have wasm/canvas support (like Flutter and Gtk I think). The missing link is the ability to integrate accessibility.
Not just that. There is quite a bunch of thinks you simple can't do (in reasonable high quality) with canvas rendering without it undermining the users privacy.
E.g. you can do a lot to reduce the fingerprint-ability of canvas (Google doesn't care) but doing so will lead to potentially slightly slower rendering and in turn potentially less fluid animations.
You can't have links as in a website without getting access the the whole browser history.
You can't take advantage of the GPU in the same way the browsers can.
You always have quite a bit of size and (potentially) load time overhead (I mean just look a Pangolin UI for a good example for this).
And "everyone" potentially ships their own copy of a whole UI framework (not just some layers on top of it like it's common in the web). So if there is a rendering but normally it get's fixed by you browser but now it needs to be fixed by library authors and then the fix needs to be used by the website which had a problem.
I think a non document based base would be nice, but it needs to be browser native, standardized, not vendor specific and with first class accessibility. At least at the core. And let's be honest flutter is non of this. And given some decisions like making text non selecteable by default I don't see it ever coming to that point tbh.
I can understand you, but IMHO for most websites a document focused paradigm is just the right fit.
I mean e.g. a news site is just a collection of documents in the end, blogs are just documents, so is wikipedia. Search machines are basically like external indices, which fit well as documents and even things like booking sites are in the end just fancy formulars.
Sure there are a lot of more "app" like usage, and for them having a different base is very important.
But I'm not the biggest fan of "turning" document use cases into apps (as many sites already try to do today), as this in my experience adds a lot of overhead and includes a massive bucket of behavioral differences which can make it very hard for some people to use the internet.
If everyone would agree of how roughly apps should behave for the roughly same UX aspect it would be fine. But people don't I mean look at the massive UX divergence which slowly creeped in between Android(Stock) and iOs. Worst this is a very subtitle creep at many places and it often seems as many designer doesn't realize that what they think is innovative (and might be innovative for e.g. a iOs) user isn't necessarily innovative for a lot of other people (e.g. all the Android users). Or in other words the whole concept of what is innovative diverged between different grubs of people even if they belong in the same "culture"/country/etc..
Anyway still for the places where it does make sense having a alternative to HTML/CSS is nice but I believe it must be browser native, non vendor specific, standardized and have first class accessibility support.
Non of which applies to Flutter (web) in the way it currently is.
Yes, we definitely want similar things. Maybe it was not clear from my original reply but I’m not saying the document paradigm is bad and we should move away from it.
The document paradigm has evolved for 25 years and it is the right fit for most “websites”.
The problem is that we’re trying to build apps on the same base as well and that is where the mismatch is.
If you look at cross platform GUI toolkits like Gtk, Qt, Flutter and Druid, what most of them have in common is that they are typically abstractions on top of a graphics rendering library (cairo, skia, canvas) with integration into platform accessibility and window APIs.
That makes them easily portable to Linux, Windows, Android, iOS etc.
The problem with the web browser as a target platform for these toolkits is that the accessibility support is currently coupled too tightly with dom/html/css.
The graphics drawing toolkit is there (canvas) and most of the above toolkits have abstracted over it already. The missing link is standardised accessibility APIs in browsers that can be used with canvas instead of dom.
Yes, it's a lot of work to create a good GUI toolkit. But it's not impossible either, and Flutter developers have already put in a lot of work into getting things just right on mobile, so I think they have a good shot at doing the same on the web.
It is impossible because on web you do not get access to low level UI primitives like input controls as you would on mobile. They cannot e.g. read clipboad, access native context sentive menus and such.
Flutter on web can do Flash applications of 2020, but for most web use cases it is not possible to ”get it right”.
I don't think Flutter uses native UI primitives anywhere, but you're right that web APIs have been designed for HTML documents/apps and will need modification for non-HTML apps. We aren't there yet, but I'm convinced we'll get there at some point.
E.g. I need to change font's/font colors/background colors from time to time because they are extremely exhausting for me to read, I can't do so with Flutter.
Screen readers know how to process HTML, CSS. But how are they supposed to know what some "arbitrary" painted pixel are supposed to mean. And yes they already have to do a awful amount of trick due to people incorrectly (one higher semantic level) use HTML & CSS.
Many of the defaults of Flutter (Web) are horrible, at least the last time I checked. E.g. text is unselectable by default instead of it being an opt in some site which have problems with stolen text content have use (and you still can steal it anyway just screenshot + OCR, duh).
Lastly (some) browsers optimized for good (e.g. fast or battery friendly) HTML/CSS rendering, non of this applies to Flutter. E.g. Firefox has a pretty need parallelization of layout and rendering allowing quite awesome usages of CSS animations, non of this will ever be possible in Flutter without replacing DOM with Flutter natively, at which point we have then a Google web instead of an internet. (Through tbh. replacing HTML+CSS with some proper abstracted API of flutters inner workings is tempting, it has some quite need aspects, that is if Accessibility works by then.)
A lot of work has been put into accessibility on the web, and the "semantic HTML" document model that works so poorly for apps helped too. There's no reason accessibility needs to be bad for anything non-HTML, at least not with supporting screen readers.
I also think text not being selectable by default is an OK default for apps (actual desktop-grade apps, not websites with interactive elements).
Right now, in 2021, it's probably a bad idea to create a web app with Flutter or any other non-DOM-based toolkit, but I don't think that will be the case forever. The native apps I use are all as good as or even better than browsers at being fast and battery-friendly. They might achieve that by being more limited and not supporting all the features and usecases of HTML5, and that's perfectly fine. It's not impossible that we'll see similar high-quality GUI frameworks inside browser runtimes.
The problem is they forcefully replacing HTML in a "inside-out" fashion without there being anything in place to allow browser accessibility tools to reasonably handle it.
Sure there is no reason non HTML can't work at some point in the future if browsers and/or accessibility tools accept a new API as (a) standard for handling accessibility. But the way it currently is it is a accessibility nightmare and often even trivial things like text selection don't work because flutter defaults to not allow text selection if the programmer doesn't go out of the way to explicitly enable it.
IMHO before you push something like flutter web onto people you first need to push a way to handle accessibility with it or you will hurt a bunch of people.
And yes the whole semantic HTML document thing didn't work out well, but that is less so because of technical reasons but more so because:
- companies just not caring, even potentially going as far as intentionally obfuscating HTML
- a lot of the semantic parts not having been there from the get to go but bolted on later on. So a lot of people and material are still used to not using it. A mistake flutter is repeating just now
- and wrt. non-document based applications it just doesn't fit that well, but a lot of web-apps could be done in a document based fashion, if companies and (not affected) people would care more.
> I'm still miffed about the extreme reliance on Javascript modern web applications have.
Flutter is written in Dart, which needs to compile to JS or WASM to run on the web, but can compile to native code. I'm guessing the native app is a lot faster.
> This website is definitely running at 20-30fps max on my phone
And what specs does your phone have? It doesn't even run on mine - a Moto E6 that is probably representative of the phones used by the average American user, and probably better than the average user globally.
>Is "native performance" comparable to the web version or dramatically better?
Tried their latest ISO[0] on QEMU and... no, it's mostly the same. But based on the release notes VM lag is a known issue. Maybe someone can try it baremetal and tell us how it went.
It's probably because they haven't paid attention to software rendering.
Many people don't seem to appreciate how well most popular UI toolkits work if your GPU drivers are incomplete or missing. (or if you just don't have hardware that supports modern OpenGL APIs.)
This, among other more Googly reasons, is why I'm personally not a flutter fan. It's not like there aren't other decent cross platform UI toolkits anyway.
It's also on Chrome (for Mac), latest Big Sur Beta. Firefox and Safari doesn't work at all (white screen). One reason could be overdraw, the Intel GPUs in older MBPs barely have enough fillrate to render one layer of pixels on a Retina display. E.g. many WebGL demos which render at Retina resolution and either use lots of alpha blending or complex pixel shaders are also stuttering on this setup.
Still, an UI framework should never eat away so much performance. Even at full display refresh rate it should only consume a small percentage of available computation power.
On my $200 android phone it is actually rather smooth after the initial download to my browser. Surprisingly so. It performs more fluent than the most apps on my pinephone and so: are there plans to make a native distro? This would make for a nice change as wm.
I really wish app developers would throttle their prototypes. They tend to run overpowered machines, but then they're oblivious to performance problems their apps have. As a consequence, users have to keep playing catchup with developers' computers. I feel strongly about this. I can't say with a straight face that the growth in apps' resource consumption over the last ten years reflects in improvements in their feature-set. Feels a bit like how gold fish get big if you put them in big aquariums.
This 100x. I've always said, developers should get a Pentium 3 500 MHz and 128 MB of RAM to test their software. And yes I am following my own advise, I use an old Dell with a Core 2 Duo T8100 and 2 GB of RAM to test my software on (oldest I could find at work).
I don’t think it’s developers’ devices that are driving the trend as much as economics. Resources get cheaper so people get faster computers and developers can release faster by forgoing optimizations all while delivering the same levels of performance. Of course, this excludes potential customers who can’t afford to update, but those are probably not the folks off of whom app devs are making their money. Of course, this doesn’t legitimize the decision to forego optimizations—I’m only noting that it’s probably not the performance of developer machines in particular.
I've considered that, but I don't have the impression that app development has gotten faster over the last decade. I bet there's people who can chime in here.
If we're not spending the time optimizing, it must be going somewhere. If it's not going into faster, more frequent releases it might be going into improved quality (though I doubt that as well, from experience) or perhaps even just employing cheaper developers (and QA and management and design and etc) such that they produce software of the same performance in the same amount of time.
It certainly has. Frameworks like Rails or Django didn't exist, pre-built component libraries weren't even a dream yet, and everyone was trying to get software to run consistently on each other's machines.
These days there's worlds of abstraction between you and those problems. Those abstractions are in transpilation, libraries, etc which all take more power to get over the problem of time.
You are right, they were around. They didn't exist with the capabilities or simplicity they do today though. Rails is also benefitting from performance improvements to Ruby, most recently.
The development velocity you could get with Rails was never constrained by the interpreter speed. That was part of the point, you could get a perfectly respectable project stood up on ruby 1.8.
Any guides or tools for doing this? Some devs on our teams now now have M1s. I worry they won't feel the pain of slow apps if they develop with such fast computers. Meanwhile we've got a number of customers who use computers that are 5+ years old.
I don't have experience doing this, but I'd experiment with VMs and their performance settings. It would be a pretty ergonomic solution. Rpi or some x86 single board computer might make sense too. I guess what's viable depends on the stack and the software itself.
Software will always outrun hardware, and ginormous software drives the entire existence of the hardware business. It's just how the system works. Are we getting benefits? I can think of lots of software we didn't have 10 years ago that we wouldn't want to give up just so we could keep old, slow boxes.
Have them use their shitty 5MB webpage over a spotty 500kbps on a phone with 1GB RAM. Maybe they'll see what it feels like to have the page load bit by bit over a minute with stuff jumping around all the time. Maybe they'll reconsider if they need 5 megs of js to display text and images then.
If you want to work on something like flutter, which will be optimised for the hardware of the day when it is done, and therefore the hardware of the future when it is being developed, then surely it makes sense to start with a prediction of how future hardware will be (eg gpu more important, possibly more pixels to push, more (not faster) processor cores, possibly higher framerates), and then try to approximate that with a powerful present-day computer.
Though in this case it feels like problems might be due to running in a web browser and not being optimised.
I’m worried about that. I might be starting a medical application. I want a single language to teach to on-devs for front end and backend work. Dart looks good however, I don’t trust Google.
Have you considered Jetpack Compose ? (https://developer.android.com/jetpack/compose) Despite it being a Google project, it also has backing from Jetbrains (https://www.jetbrains.com/lp/compose/). Having access to the full JVM environment of libraries is an infinitely better state than Dart, and Kotlin is also a much more pleasant language. Testing cycle is sliiightly slower, but Compose previews make it easy.
I've been playing with compose and it looks really good. Note that it's still on beta(api should be considered stable) with a release this year. Previews are kinda wonky for now. Sometimes it wouldn't refresh. How hard is it to implement hot reload?
And like I mentioned before, with my low-end laptop its hard to run full Android Studio. Tho Dart's not that pleasant compared to Kotlin, the tooling outside a single IDE was enticing for me.
> I want a single language to teach to on-devs for front end and backend work
if that's what you want then you should support things like kotlin multiplatform, react-native or SwiftUI, dart is a very meh language comparing to those above with established back-end ecosystems.
I think you don’t need to worry about that. They’ve probably invested around fifteen years of time into the language.
They want it because it gives them control over their future in a way that Kotlin or Java and the JVM do not.
The “bundle the whole world in your app” isn’t space efficient, but it’s efficient enough and sidesteps a large part of the outdated Android issue. Meanwhile the react-style components are very popular among devs with UI know-how. The rapid uptake of Flutter also speaks to the hole it is filling.
Then there’s FuschiaOS where they’re seemingly intent on making it the primary dev language.
Lots of good reasons to continue support and not many reasons not to. Sounds like a decent bet to me
Looks like the web desktops that used (are?) to be popular about a decade ago. Otherwise no information is provided or can be found. How does one run this on Linux or Fuchsia? Is this open source or proprietary? Maybe another link should be used instead.
What are we looking at? All I see is a reproduction of an OS with abysmal performance, where everything is fake: the text editor is fake, the terminal is fake, the web browser is fake. The only thing working is the clock...
But that's not even a click-dummy "desktop". Also, form the tech perspective, it seems pre-alpha state. At least the web version renders with maybe 10 fps on a pretty decent machine, and every click has at minimum half a second latency. No clue why someone put up a website marketing this thing to end-users. It looks like 3 to 6 years of hard work form usable, imho.
Currently Flutter is much more suitable for native mobile and desktop than for web. If you have the Flutter dev environment installed, you can check out the repo and run it as a desktop app for a far better experience. The unpolished web support may be doing more harm than good, because people looking at demos like this can understandably end up with a negative impression.
Google, please, leave the Flutter back and create a GUI for GO based on Inferno or an enhanced (dumbed down for the causal user) Plan9 UI with pulldown menus for the user, micking allegro or XAW and a simple file dialog a la TK.
That's just a matter of style. Android could have native widgets, and desktops another exact set. Instead of a hamburger menu, an automatic horizontal one. And so on.
I just inspected the page, and saw that this version does not use canvas (e.g. "canvaskit") but <flt-xxx> elements - e.g. the HTML flutter web output. This may or may not make things slower.
130 comments
[ 1.5 ms ] story [ 202 ms ] threadTheir OS, dahliaOS is using it: https://dahliaos.io/
Honestly, never tried it myself, but it definitely looks cool and I wanted to share the web version ;)
It does look interesting though. It's an UI for Fuchsia or Linux, with containers for the other system?
Edit: It doesn't seem to work really good, but it kinda works.
Flutter... stutter... maybe the Flutter team was trying to tell us something all along ;)
This website is definitely running at 20-30fps max on my phone, whereas 60fps seems perfectly maintainable on my own Flutter experiments with web apps.
Having said all that, I'm still miffed about the extreme reliance on Javascript modern web applications have. With the ease of use Flutter promises for making web apps, I can only fear the slow, janky mess that websites will become if the platform ever gets taken up as quick as Flutter seems to hope it will.
https://vugu.org
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
Yes, after all those years browsers are top notch when it comes to accessibility, but it comes with lots of additional complexity.
I am hopeful that with things like WASM and Canvas we are finally starting to move away from this document-based paradigm towards more app-focused paradigms.
Although there is still lots of work to be done to make approaches like this work with accessibility tools.
Sometimes i think that we are deliberately not adding dom support to wasm in order to not make the same mistakes we did when trying to make html/css/js suitable for apps.
edit: some toolkits already have wasm/canvas support (like Flutter and Gtk I think). The missing link is the ability to integrate accessibility.
E.g. you can do a lot to reduce the fingerprint-ability of canvas (Google doesn't care) but doing so will lead to potentially slightly slower rendering and in turn potentially less fluid animations.
You can't have links as in a website without getting access the the whole browser history.
You can't take advantage of the GPU in the same way the browsers can.
You always have quite a bit of size and (potentially) load time overhead (I mean just look a Pangolin UI for a good example for this).
And "everyone" potentially ships their own copy of a whole UI framework (not just some layers on top of it like it's common in the web). So if there is a rendering but normally it get's fixed by you browser but now it needs to be fixed by library authors and then the fix needs to be used by the website which had a problem.
I think a non document based base would be nice, but it needs to be browser native, standardized, not vendor specific and with first class accessibility. At least at the core. And let's be honest flutter is non of this. And given some decisions like making text non selecteable by default I don't see it ever coming to that point tbh.
I mean e.g. a news site is just a collection of documents in the end, blogs are just documents, so is wikipedia. Search machines are basically like external indices, which fit well as documents and even things like booking sites are in the end just fancy formulars.
Sure there are a lot of more "app" like usage, and for them having a different base is very important.
But I'm not the biggest fan of "turning" document use cases into apps (as many sites already try to do today), as this in my experience adds a lot of overhead and includes a massive bucket of behavioral differences which can make it very hard for some people to use the internet.
If everyone would agree of how roughly apps should behave for the roughly same UX aspect it would be fine. But people don't I mean look at the massive UX divergence which slowly creeped in between Android(Stock) and iOs. Worst this is a very subtitle creep at many places and it often seems as many designer doesn't realize that what they think is innovative (and might be innovative for e.g. a iOs) user isn't necessarily innovative for a lot of other people (e.g. all the Android users). Or in other words the whole concept of what is innovative diverged between different grubs of people even if they belong in the same "culture"/country/etc..
Anyway still for the places where it does make sense having a alternative to HTML/CSS is nice but I believe it must be browser native, non vendor specific, standardized and have first class accessibility support.
Non of which applies to Flutter (web) in the way it currently is.
The document paradigm has evolved for 25 years and it is the right fit for most “websites”.
The problem is that we’re trying to build apps on the same base as well and that is where the mismatch is.
If you look at cross platform GUI toolkits like Gtk, Qt, Flutter and Druid, what most of them have in common is that they are typically abstractions on top of a graphics rendering library (cairo, skia, canvas) with integration into platform accessibility and window APIs.
That makes them easily portable to Linux, Windows, Android, iOS etc.
The problem with the web browser as a target platform for these toolkits is that the accessibility support is currently coupled too tightly with dom/html/css.
The graphics drawing toolkit is there (canvas) and most of the above toolkits have abstracted over it already. The missing link is standardised accessibility APIs in browsers that can be used with canvas instead of dom.
If by "just right" you mean sticking out like a sore thumb on iOS, then sure.
Flutter on web can do Flash applications of 2020, but for most web use cases it is not possible to ”get it right”.
E.g. I need to change font's/font colors/background colors from time to time because they are extremely exhausting for me to read, I can't do so with Flutter.
Screen readers know how to process HTML, CSS. But how are they supposed to know what some "arbitrary" painted pixel are supposed to mean. And yes they already have to do a awful amount of trick due to people incorrectly (one higher semantic level) use HTML & CSS.
Many of the defaults of Flutter (Web) are horrible, at least the last time I checked. E.g. text is unselectable by default instead of it being an opt in some site which have problems with stolen text content have use (and you still can steal it anyway just screenshot + OCR, duh).
Lastly (some) browsers optimized for good (e.g. fast or battery friendly) HTML/CSS rendering, non of this applies to Flutter. E.g. Firefox has a pretty need parallelization of layout and rendering allowing quite awesome usages of CSS animations, non of this will ever be possible in Flutter without replacing DOM with Flutter natively, at which point we have then a Google web instead of an internet. (Through tbh. replacing HTML+CSS with some proper abstracted API of flutters inner workings is tempting, it has some quite need aspects, that is if Accessibility works by then.)
I also think text not being selectable by default is an OK default for apps (actual desktop-grade apps, not websites with interactive elements).
Right now, in 2021, it's probably a bad idea to create a web app with Flutter or any other non-DOM-based toolkit, but I don't think that will be the case forever. The native apps I use are all as good as or even better than browsers at being fast and battery-friendly. They might achieve that by being more limited and not supporting all the features and usecases of HTML5, and that's perfectly fine. It's not impossible that we'll see similar high-quality GUI frameworks inside browser runtimes.
Sure there is no reason non HTML can't work at some point in the future if browsers and/or accessibility tools accept a new API as (a) standard for handling accessibility. But the way it currently is it is a accessibility nightmare and often even trivial things like text selection don't work because flutter defaults to not allow text selection if the programmer doesn't go out of the way to explicitly enable it.
IMHO before you push something like flutter web onto people you first need to push a way to handle accessibility with it or you will hurt a bunch of people.
And yes the whole semantic HTML document thing didn't work out well, but that is less so because of technical reasons but more so because:
- companies just not caring, even potentially going as far as intentionally obfuscating HTML
- a lot of the semantic parts not having been there from the get to go but bolted on later on. So a lot of people and material are still used to not using it. A mistake flutter is repeating just now
- and wrt. non-document based applications it just doesn't fit that well, but a lot of web-apps could be done in a document based fashion, if companies and (not affected) people would care more.
Flutter is written in Dart, which needs to compile to JS or WASM to run on the web, but can compile to native code. I'm guessing the native app is a lot faster.
And what specs does your phone have? It doesn't even run on mine - a Moto E6 that is probably representative of the phones used by the average American user, and probably better than the average user globally.
I'm not sure how that compares to the US where there's a 60/40 division in Apple/Android market share, though.
Tried their latest ISO[0] on QEMU and... no, it's mostly the same. But based on the release notes VM lag is a known issue. Maybe someone can try it baremetal and tell us how it went.
[0]: https://github.com/dahliaOS/releases/releases
This, among other more Googly reasons, is why I'm personally not a flutter fan. It's not like there aren't other decent cross platform UI toolkits anyway.
Still, an UI framework should never eat away so much performance. Even at full display refresh rate it should only consume a small percentage of available computation power.
it's the developer that uses the tech, or rather misuses the computer
you jump to conclusion rather quickly, that's fishy
These days there's worlds of abstraction between you and those problems. Those abstractions are in transpilation, libraries, etc which all take more power to get over the problem of time.
> Frameworks like Rails or Django didn't exist
You... might want to check the git histories. And a calendar.
Have them use their shitty 5MB webpage over a spotty 500kbps on a phone with 1GB RAM. Maybe they'll see what it feels like to have the page load bit by bit over a minute with stuff jumping around all the time. Maybe they'll reconsider if they need 5 megs of js to display text and images then.
Though in this case it feels like problems might be due to running in a web browser and not being optimised.
And like I mentioned before, with my low-end laptop its hard to run full Android Studio. Tho Dart's not that pleasant compared to Kotlin, the tooling outside a single IDE was enticing for me.
if that's what you want then you should support things like kotlin multiplatform, react-native or SwiftUI, dart is a very meh language comparing to those above with established back-end ecosystems.
They want it because it gives them control over their future in a way that Kotlin or Java and the JVM do not.
The “bundle the whole world in your app” isn’t space efficient, but it’s efficient enough and sidesteps a large part of the outdated Android issue. Meanwhile the react-style components are very popular among devs with UI know-how. The rapid uptake of Flutter also speaks to the hole it is filling.
Then there’s FuschiaOS where they’re seemingly intent on making it the primary dev language.
Lots of good reasons to continue support and not many reasons not to. Sounds like a decent bet to me
Qt is the only real alternative to WPF/WinUI on medical devices, so you would be in good company.
And then there is ChromeOS with PWAs and Fungu project.
Google is all in internal political wars about their platforms.
Edit: Submitter shared the repo link in another comment: https://github.com/dahliaOS/pangolin_desktop
(If not, then ouch...)
Won't do.
Please don't use flutter web, it's a unacceptable accessibility nightmare.
Same here. I'm using Firefox.
But that's not even a click-dummy "desktop". Also, form the tech perspective, it seems pre-alpha state. At least the web version renders with maybe 10 fps on a pretty decent machine, and every click has at minimum half a second latency. No clue why someone put up a website marketing this thing to end-users. It looks like 3 to 6 years of hard work form usable, imho.
* There's a massive company like Google behind it
* Google has experience with app dev
* It's been 3+ years
* The project has been hyped up a lot, and has a lot of supporters
* has a programming language that basically exists to support this one dev kit.
Tagline: "So good, it'll go viral"?
http://www.vitanuova.com/inferno/screenshots.html
Dis => ART.
9P => Binder
Inferno kernel => Linux/Treble
I wouldn't want my Linux distro looking like something from Google tbh :)
https://en.wikipedia.org/wiki/EyeOS
It certainly ran better than this.
https://news.ycombinator.com/item?id=26845037
How smooth that is compared to this here…
https://news.ycombinator.com/item?id=24976732