My problem with non-native UIs is that they often lack some behaviours and capabilities of native ones. For example, the Java UI file selection dialog doesn't let me perform a right-click action on a folder before selecting it, as well as a lot of other things I would've been able to do with a native equivalent. Some cross-platform multi-windows come with a horrible drag lag due to not issuing a redraw update every tick. They also often don't support half-screen docking by dragging the window to the side. Qt scrollbar, if I recall correctly, misses the feature of the native one that if you drag too far in the perpendicular direction, it wouldn't move at all, preventing an accidental mistake in scroll direction. There's a billion little things like this that just cannot be accounted for by a single ultimate cross-platform UI framework. BUT webpage-based UI seem to have become a nice compromise. A browser provides a sort of 'frontend' (as in 'compiler fronted', i.e. a 'common representation -> native result' transformation), which more often than not relies on native UI components, or at least mimics their behaviour well enough for every platform individually. And the developers get a relatively uniform target representation. So, as much as I dislike javascript and the tendencies it has caused in webapps, I think webpage-based cross-platform UI is a step forward from whatever Java, Qt & etc. tried to do
Thanks for the talk. It's still weird to have so much of the work being done in the platform, but I'm sure once the ecosystem has developed more, there'll be a lot of nice ones to use.
What I hate in the short term: having a framework that forces me to completely and explicitly manage all my side-effects in a User event -> update -> model -> view -> User event loop. What I love in the long term: (s. above!)
I really wonder if this will be good enough to replace C#. So far, I really like it, but I was a bit dissapointed with the memory usage. Hello world app in WPF with dotnet 6/7 uses far less memory, big app uses 70-80MB (plus any graphics you load, like images). And you can also cross-compile C#/F# into native executables. I will defienetely try it out :)
As is demonstrated, it all depends on what platform you use for your program, you can choose to make the tradeoffs that make sense for you it seems, wgpu-rs might bring a lot to the table for the memory it takes idk
I am tired of this JavaScript mentality where everyone want to rewrite a popular tool, change few things in it, and call it the best thing since sliced bread. We then get a pollution of language dialects or framework, all badly designed and all trying to correct the mistake of another badly designed tool, language or framework. I am sticking with Haskell and Elm. Period. No Roc or anything else. Don't bother trying to invent another Haskell dialect. I am not interested in it and I will not waste my time learning it. Roc can go suck!!!! By the way, I wonder why I should learn a language written by someone who doesn't understand Elm pipelines. You could go check the Elm introduction course that Richard gave at FrontEnd Masters to find out.
Richard is like a kid in a candy store - awesome!
Feldman strikes again. Very interesting.
"Early days" but _very_ promising. Great work Richard! 😍
My problem with non-native UIs is that they often lack some behaviours and capabilities of native ones. For example, the Java UI file selection dialog doesn't let me perform a right-click action on a folder before selecting it, as well as a lot of other things I would've been able to do with a native equivalent. Some cross-platform multi-windows come with a horrible drag lag due to not issuing a redraw update every tick. They also often don't support half-screen docking by dragging the window to the side. Qt scrollbar, if I recall correctly, misses the feature of the native one that if you drag too far in the perpendicular direction, it wouldn't move at all, preventing an accidental mistake in scroll direction. There's a billion little things like this that just cannot be accounted for by a single ultimate cross-platform UI framework.
BUT webpage-based UI seem to have become a nice compromise. A browser provides a sort of 'frontend' (as in 'compiler fronted', i.e. a 'common representation -> native result' transformation), which more often than not relies on native UI components, or at least mimics their behaviour well enough for every platform individually. And the developers get a relatively uniform target representation. So, as much as I dislike javascript and the tendencies it has caused in webapps, I think webpage-based cross-platform UI is a step forward from whatever Java, Qt & etc. tried to do
Thanks for the talk. It's still weird to have so much of the work being done in the platform, but I'm sure once the ecosystem has developed more, there'll be a lot of nice ones to use.
What I hate in the short term: having a framework that forces me to completely and explicitly manage all my side-effects in a User event -> update -> model -> view -> User event loop.
What I love in the long term: (s. above!)
I tried to cross compile C++ for Linux on Windows in 2016. It was easier to ship the code to a Linux server, compile there, and get the binary back.
I would watch Richard talk about gardening :), I need to figure out what is the Roc thing
I really wonder if this will be good enough to replace C#. So far, I really like it, but I was a bit dissapointed with the memory usage. Hello world app in WPF with dotnet 6/7 uses far less memory, big app uses 70-80MB (plus any graphics you load, like images). And you can also cross-compile C#/F# into native executables.
I will defienetely try it out :)
As is demonstrated, it all depends on what platform you use for your program, you can choose to make the tradeoffs that make sense for you it seems, wgpu-rs might bring a lot to the table for the memory it takes idk
I also love winamp. The open source community also loves winamp that is why they have multiple winamp clones in Linux
Is there any source code for this? How to use the platform?
Network latency is avoidable if you use service workers
I am tired of this JavaScript mentality where everyone want to rewrite a popular tool, change few things in it, and call it the best thing since sliced bread. We then get a pollution of language dialects or framework, all badly designed and all trying to correct the mistake of another badly designed tool, language or framework.
I am sticking with Haskell and Elm. Period. No Roc or anything else. Don't bother trying to invent another Haskell dialect. I am not interested in it and I will not waste my time learning it. Roc can go suck!!!!
By the way, I wonder why I should learn a language written by someone who doesn't understand Elm pipelines. You could go check the Elm introduction course that Richard gave at FrontEnd Masters to find out.
@@actualwafflesenjoyer ! After you, my big brother! Birthright obliges!
Chill out man. No one’s forcing you to do anything 😂