Compose for Web(compose-web.ui.pages.jetbrains.team)
compose-web.ui.pages.jetbrains.team
Compose for Web
https://compose-web.ui.pages.jetbrains.team/
53 comments
If you start badly it’s likely to get worse over time, not better.
I don't think that's a foregone conclusion. It largely comes down to your decision-making principles.
"Make it work, make it right, make it fast", for one.
"Make it work, make it right, make it fast", for one.
I think both things are true but you can’t expect to do that over a whole codebase; you have to do it feature by feature as you build them or you’ll literally be fixing issues forever.
I'm a full time Android dev, who's also a intermediate in web dev. When I first started using compose / flutter, I assumed it was for the best, since I didn't have to learn anything new. I battled myself everyday, whether or not I had to learn React. My views are pretty clear now.
React with PWA - For my internal projects. React & Android app with Kotlin - For Products I ship.
Ended up learning and liking react!
Like pier25 has pointed out, I don't think it's worth loading 2 mb for a single button. So as painful as it maybe to have 3 code bases for 3 platforms, IMO gives the user the best experience.
React with PWA - For my internal projects. React & Android app with Kotlin - For Products I ship.
Ended up learning and liking react!
Like pier25 has pointed out, I don't think it's worth loading 2 mb for a single button. So as painful as it maybe to have 3 code bases for 3 platforms, IMO gives the user the best experience.
I think it'll get optimized. We went from GWT apps needing like 250k to render a HelloWorld, to J2CL + Closure Compiler being able to do the same thing with a 1 line output.
Compose has an elegant, theoretically pleasant way of modeling reactive frameworks as pure functions with memoized state, and an explicit call stack.
But right now you're paying a giant tax for all this since you bring in the entire Kotlin runtime, coroutines, collections, etc plus the Compose runtime, plus the Widget library. Since Compose is only beta right now, this is clearly unoptimized.
It's definitely not eliminating all the dead code or metadata it could, there's a ton of code like this:
``` function(e, t) { e.exports = function(e) { return { name: "Inform 7", aliases: ["i7"], case_insensitive: !0, keywords: { keyword: "thing room person man woman animal container supporter backdrop door scenery open closed locked inside gender is are say understand kind of rule" }, contains: [{ className: "string", begin: '"', end: '"', relevance: 0, contains: [{ className: "subst", begin: "\\[", end: "\\]" }] }, { className: "section", begin: /^(Volume|Book|Part|Chapter|Section|Table)\b/, end: "$" }, { begin: /^(Check|Carry out|Report|Instead of|To|Rule|When|Before|After)\b/, end: ":", contains: [{ begin: "\\(This", end: "\\)" }] }, { className: "comment", begin: "\\[", end: "\\]", contains: ["self"] }] } } }
```
Which looks like some kind of parser embedded in it.
Compose has an elegant, theoretically pleasant way of modeling reactive frameworks as pure functions with memoized state, and an explicit call stack.
But right now you're paying a giant tax for all this since you bring in the entire Kotlin runtime, coroutines, collections, etc plus the Compose runtime, plus the Widget library. Since Compose is only beta right now, this is clearly unoptimized.
It's definitely not eliminating all the dead code or metadata it could, there's a ton of code like this:
``` function(e, t) { e.exports = function(e) { return { name: "Inform 7", aliases: ["i7"], case_insensitive: !0, keywords: { keyword: "thing room person man woman animal container supporter backdrop door scenery open closed locked inside gender is are say understand kind of rule" }, contains: [{ className: "string", begin: '"', end: '"', relevance: 0, contains: [{ className: "subst", begin: "\\[", end: "\\]" }] }, { className: "section", begin: /^(Volume|Book|Part|Chapter|Section|Table)\b/, end: "$" }, { begin: /^(Check|Carry out|Report|Instead of|To|Rule|When|Before|After)\b/, end: ":", contains: [{ begin: "\\(This", end: "\\)" }] }, { className: "comment", begin: "\\[", end: "\\]", contains: ["self"] }] } } }
```
Which looks like some kind of parser embedded in it.
On the same vein, everyone that bet the farm into GWT, ended up rewriting their application.
GWT is still being used, no one needed to adopt J2CL, and with judicious use of code splitting, the enterprise apps it was designed for worked fine. It’s still being activity developed and used by the open source community.
There are plenty of SPA JS projects that send down a MB of JS.
A lot of the tech JS frameworks adopted in the last few years was shipping in GWT more than a decade ago: tree shaking, uglification, sprite sheets, style sheet languages, compiler directed code splitting, etc
GWTs Achilles heel was it was developed to paper over differences in browsers from the IE4 era, and so the widget model design is a left over heavyweight legacy from needing to make modern and ancient browsers work similarly.
There are plenty of SPA JS projects that send down a MB of JS.
A lot of the tech JS frameworks adopted in the last few years was shipping in GWT more than a decade ago: tree shaking, uglification, sprite sheets, style sheet languages, compiler directed code splitting, etc
GWTs Achilles heel was it was developed to paper over differences in browsers from the IE4 era, and so the widget model design is a left over heavyweight legacy from needing to make modern and ancient browsers work similarly.
Sure it is being used, just like Java 1.4 still is.
So with this, Flutter, and others it seems there is a drive to unify Web/Desktop/Mobile development (the mythical "truly-cross-platform UI")
If I understand the code samples here correctly, Compose for Web enables someone to write basically standard HTML/CSS components (in the "React" sense) and the hope is that higher level components wrapping the platform-specific components will be written:
> Use and build Compose widgets that work on Android, Desktop, and Web by utilizing Kotlin's expect-actual mechanisms to provide platform-specific implementations
While layout will be handled in-house (not via traditional HTML layouts?)
> Experiment with a set of layout primitives and APIs that mimic the features you already know from Compose for Desktop and Android
This seems a much nicer approach than Flutter's default ("we render everything in a canvas")
But can this really pan out? Layout being handled in-house, non-native UI elements on iOS/Android (from what I have read) are strong signals the "higher level components" approach doesn't work in practice
If I understand the code samples here correctly, Compose for Web enables someone to write basically standard HTML/CSS components (in the "React" sense) and the hope is that higher level components wrapping the platform-specific components will be written:
> Use and build Compose widgets that work on Android, Desktop, and Web by utilizing Kotlin's expect-actual mechanisms to provide platform-specific implementations
While layout will be handled in-house (not via traditional HTML layouts?)
> Experiment with a set of layout primitives and APIs that mimic the features you already know from Compose for Desktop and Android
This seems a much nicer approach than Flutter's default ("we render everything in a canvas")
But can this really pan out? Layout being handled in-house, non-native UI elements on iOS/Android (from what I have read) are strong signals the "higher level components" approach doesn't work in practice
> This seems a much nicer approach than Flutter's default ("we render everything in a canvas")
IMO Flutter should have used the DOM for web. Right now it's reimplementing (and shipping) tons of stuff that the browser already solves: layouts, styles, text editing, spellchecking, etc.
IMO Flutter should have used the DOM for web. Right now it's reimplementing (and shipping) tons of stuff that the browser already solves: layouts, styles, text editing, spellchecking, etc.
People sort of miss the point on that imho, as a Flutter dev I don't want compatibility with the DOM, I want my app to look and work the same on the web as it does on iOS as it does on Android
As a user of the web, I don't want webpages to work like a second rate android app.
I want my browser extensions to work. I want screen readers to be able to understand the webpage and read aria tags. I want to be able to copy+paste content. I want platform-native controls and input boxes, which support all of my OS's keyboard shortcuts for scrolling and moving the cursor around. I want the browser's dev tools to work, so I can delete unreadable color combinations and take a look at what fonts you're using. And use reader mode if I need to.
There's probably a shining hill on the other side of this mountain, where we have a nice cross-platform UI toolkit thats not electron. But there's an awful uncanny valley to cross along the way. In the valley nothing works quite right and apps are a bit ugly on every platform. The valley is a graveyard of good intentions and failed ambition. WxWindows. Java's Swing. In its own way, Qt. And Phonegap, and probably React Native, though that still has some life left in it. I hate using software in this place. Notion is dog slow. Java Spring apps were always ugly and weird. Apps made with Phonegap have halfbaked javascript replacements for iOS controls that look native but break when you try to use them like their native equivalents. Does Google Blogger still load so much GWT it needs a loading animation?
Maybe I'm letting my cynicism show. I hope Flutter succeeds. I worry that it won't, and its only legacy will be another wave of half broken apps that subtly break platform conventions.
I want my browser extensions to work. I want screen readers to be able to understand the webpage and read aria tags. I want to be able to copy+paste content. I want platform-native controls and input boxes, which support all of my OS's keyboard shortcuts for scrolling and moving the cursor around. I want the browser's dev tools to work, so I can delete unreadable color combinations and take a look at what fonts you're using. And use reader mode if I need to.
There's probably a shining hill on the other side of this mountain, where we have a nice cross-platform UI toolkit thats not electron. But there's an awful uncanny valley to cross along the way. In the valley nothing works quite right and apps are a bit ugly on every platform. The valley is a graveyard of good intentions and failed ambition. WxWindows. Java's Swing. In its own way, Qt. And Phonegap, and probably React Native, though that still has some life left in it. I hate using software in this place. Notion is dog slow. Java Spring apps were always ugly and weird. Apps made with Phonegap have halfbaked javascript replacements for iOS controls that look native but break when you try to use them like their native equivalents. Does Google Blogger still load so much GWT it needs a loading animation?
Maybe I'm letting my cynicism show. I hope Flutter succeeds. I worry that it won't, and its only legacy will be another wave of half broken apps that subtly break platform conventions.
You’re not letting your cynicism show. If for no other reason, the lack of accessibility makes Flutter a toy project rather than something you’d professionally use to built a site.
It’s Flash all over again otherwise.
As a user, the lack of compatibility with standard browser APIs is why I have such a bad experience with Flutter web apps and will avoid them when I can.
Flutter's rendering may be fast and efficient on native code, its performance sucks when I try to use it in my browser. A website bringing its own javascript-based DOM tree to my browser engine is just ludicrous.
Flutter for the web feels like a "we made an app, might as well create a web version of it because it's one click anyway" kind of solution in the same way Electron is a "we made a website, might as well make it an app" solution. Comfortable for developers, but terrible for end users, unless you're willing to give up most of the developer comfort to work out the performance issues.
Flutter's rendering may be fast and efficient on native code, its performance sucks when I try to use it in my browser. A website bringing its own javascript-based DOM tree to my browser engine is just ludicrous.
Flutter for the web feels like a "we made an app, might as well create a web version of it because it's one click anyway" kind of solution in the same way Electron is a "we made a website, might as well make it an app" solution. Comfortable for developers, but terrible for end users, unless you're willing to give up most of the developer comfort to work out the performance issues.
If the success of the web has proven anything, it's that user comfort will win over developer comfort every time.
sigh another thread I show up to next day and I got downvoted through the floor for a simple straightforward polite though. As someone using Flutter to great effect daily, without much chance to discuss it with other engineers, I'm really interested in this discussion, but I'm also really worried I can't have it here, I'm guessing it leaves people feeling like I'm attacking the open web or something
That's going to apply _again_ here: I really cannot visualize what you mean, beyond the comparison to Electron, which you nail. Flutter is "electron done right" for people like me building cross platform apps, it's a cross platform rendering engine, not a browser engine.
Presumably, this is immensely frustrating in your experience, but I really can't name a web app that uses Flutter - Flutter Web apps are/should be distributed like Electron apps. What's the Flutter Web app that frustrated you, I'm intensely curious, I didn't know people were trying to attempt that..
That's going to apply _again_ here: I really cannot visualize what you mean, beyond the comparison to Electron, which you nail. Flutter is "electron done right" for people like me building cross platform apps, it's a cross platform rendering engine, not a browser engine.
Presumably, this is immensely frustrating in your experience, but I really can't name a web app that uses Flutter - Flutter Web apps are/should be distributed like Electron apps. What's the Flutter Web app that frustrated you, I'm intensely curious, I didn't know people were trying to attempt that..
The latest web app I've been annoyed with to the point of just giving up has been FluffyChat, a Matrix client written in Flutter. The mobile app has been working fine, although somewhat unstable, and the desktop application didn't work at all (I believe desktop support is pretty much in alpha so I can forgive that). I've settled for trying the web app instead.
It works, but it feels off. It consumes loads of CPU, it's not close to the normal responsiveness of a real application and the whole feel is that of a video game UI, something alien to the rest of the system.
Putting Flutter Web into Electron honestly sounds like it would just produce slower Electron apps. One of the strengths of Flutter is that it can target multiple native systems with no code changes, so if you're going to provide a native download, just make a native executable and be done with it.
The state of Flutter Web is quite sad because it could easily become the de facto standard for web app development for platforms that would otherwise not allow your app (say, an app that wouldn't pass Apple's stringent requirements).
I don't blame the developers using Flutter to make apps for the shitty Flutter (and Flutter Web) performance, Google made the choice to drop all native components and render their own either through OpenGL or through a web canvas, and the usability problems that stem from that choice are Google's problem. Even after a few hours of messing around with Flutter, I could see its potential for app development. I'll still prefer a "real" native app any time, but I accept that not every dev shop has the resources to maintain separate code bases for the different platforms they support.
It works, but it feels off. It consumes loads of CPU, it's not close to the normal responsiveness of a real application and the whole feel is that of a video game UI, something alien to the rest of the system.
Putting Flutter Web into Electron honestly sounds like it would just produce slower Electron apps. One of the strengths of Flutter is that it can target multiple native systems with no code changes, so if you're going to provide a native download, just make a native executable and be done with it.
The state of Flutter Web is quite sad because it could easily become the de facto standard for web app development for platforms that would otherwise not allow your app (say, an app that wouldn't pass Apple's stringent requirements).
I don't blame the developers using Flutter to make apps for the shitty Flutter (and Flutter Web) performance, Google made the choice to drop all native components and render their own either through OpenGL or through a web canvas, and the usability problems that stem from that choice are Google's problem. Even after a few hours of messing around with Flutter, I could see its potential for app development. I'll still prefer a "real" native app any time, but I accept that not every dev shop has the resources to maintain separate code bases for the different platforms they support.
My point is not about DOM compatibility, it's about unnecessarily bloating Flutter web apps.
I think Skia is on the order of a megabyte, it'd be nice to skip it, but it's even nicer to ship prototypes that work in the browser and look the same as the 'shipping' version. Changed the way my team works
I guess, but most people don't care about that stuff. Which is why Flutter is dying :/
Flutter isn't dying, not even close, here to stay and increasing share
Flutter won't survive long. The whole point of cross platform dev is to pull better apps with limited resources. An app without backend is nothing. JS is web native language, it will always be easier to code Node JS backend than to code using Dart. 1 indie developer with one skill set can pull off an end to end app. Dart seems to be competing with Javascript only that too in
client side dev, totally ignoring JAVA, Kotlin and Swift.
The point of a cross platform dev is to write the same app for all platforms using the same codebase. I'm happy to "totally ignore JAVA, Kotlin and Swift" doing that
You really rarely see native components. Try to take a look at Telegram for iOS - there are zero built-in components: literally everything is rebuilt from scratch - navigation, buttons, toggles, all animations, etc.
"Non-native" is not always a bad thing.
"Non-native" is not always a bad thing.
> "Non-native" is not always a bad thing.
Setting aside the non-native look and the non-native feel, one reason it's almost always a bad thing in practice is because developers who re-invent everything rarely match the accessibility support of the native platform.
Setting aside the non-native look and the non-native feel, one reason it's almost always a bad thing in practice is because developers who re-invent everything rarely match the accessibility support of the native platform.
I believe that this applies not just to the front-end development, but also the back-end frameworks and libraries.
I've seen people attempt to create their own (oftentimes poorly documented and poorly tested, as well as poorly supported) web frameworks even in large projects far too often.
It seems that for any project that needs to be supported and maintained for years if not decades, the argument could be extended to: "Non-native and non-standard is usually a bad thing."
Of course, there's nothing wrong with using bleeding edge technology and writing your own frameworks and libraries, however that should only be done when and where it makes sense.
I've seen people attempt to create their own (oftentimes poorly documented and poorly tested, as well as poorly supported) web frameworks even in large projects far too often.
It seems that for any project that needs to be supported and maintained for years if not decades, the argument could be extended to: "Non-native and non-standard is usually a bad thing."
Of course, there's nothing wrong with using bleeding edge technology and writing your own frameworks and libraries, however that should only be done when and where it makes sense.
ex3ndr(1)
Non-native look and non-native toolkit is two different things. You don't need to look native to support accessibility, built-in i18n and L10n, to behave like other native looking applications. But you certainly need to be native to not stick out like a sore thumb.
It is so ironic to see the politics from Android related teams against the Flutter uptake.
Bringing Compose to every platform Flutter is targeting, just in case.
Bringing Compose to every platform Flutter is targeting, just in case.
This looks a good first step. But what is the iOS story of jetpack-compose? It's non-existent.
Right now, there's only one single-codebase solution to render to android, ios, mac, linux, windows and the web - and that is Flutter.
But Flutter choosing Dart is more of an "easier to control the roadmap" strategy than the bs they actually put up on their FAQ
I'd really like a Flutter like framework (that renders to it's own widgets) but with kotlin as the framework language and it isn't impossible to make. I don't see Google making it, as it conflicts with Flutter.
Would like to see a developer oriented company like Jetpack and the open source community, make a push for a truly Flutter alternative.
Right now, there's only one single-codebase solution to render to android, ios, mac, linux, windows and the web - and that is Flutter.
But Flutter choosing Dart is more of an "easier to control the roadmap" strategy than the bs they actually put up on their FAQ
I'd really like a Flutter like framework (that renders to it's own widgets) but with kotlin as the framework language and it isn't impossible to make. I don't see Google making it, as it conflicts with Flutter.
Would like to see a developer oriented company like Jetpack and the open source community, make a push for a truly Flutter alternative.
No, right now the only way to target all platforms is JavaScript. Flutter's desktop and web support is a sad joke, and even on mobile it doesn't feel native even on Android.
React Native runs on all those platforms too.
> ...only one
React Native, NativeScript, Xamarin
React Native, NativeScript, Xamarin
Working on it right now, we're in stealth but going public in a few months, working on language support for modern editors, previews and our own editor right now!
It's a unified solution that gives developers more freedom of choice, with some versions of it already battle tested in large production apps. If you're up for it, I would love to be able to email you when we release the public version or maybe even earlier.
It's a unified solution that gives developers more freedom of choice, with some versions of it already battle tested in large production apps. If you're up for it, I would love to be able to email you when we release the public version or maybe even earlier.
> that renders to it's own widgets
I've always felt this to be a net negative, and it puts me off Flutter more than anything else.
I know it has no bearing on the app developer or the end user, but there's something about pouring thousands of person-hours into making a facsimile of something that already exists (especially something that has already had thousands of person-hours put into usability and accessibility) that feels so wasteful. It's silly I know, but it just doesn't sit right with me.
I've always felt this to be a net negative, and it puts me off Flutter more than anything else.
I know it has no bearing on the app developer or the end user, but there's something about pouring thousands of person-hours into making a facsimile of something that already exists (especially something that has already had thousands of person-hours put into usability and accessibility) that feels so wasteful. It's silly I know, but it just doesn't sit right with me.
Not Kotlin, but working to bring Flutter to other languages https://hydro-sdk.io/
"But Flutter choosing Dart"
Maybe kotlin was a year too late, not making it to 1.0 till
February 15, 2016.
The sky project that became flutter was demoed at the April 2015 dart conf. https://www.youtube.com/watch?v=PnIWl33YMwA
As regards Javascript, that's what they started with, they looked at other languages and gave dart a go, it gave them faster startup and the dart team offered them stateful hot reload.
Anyway working in the chrome space, they prob didn't know that Kotlin existed pre 2015 and prob would have gone with Python if could.
The sky project that became flutter was demoed at the April 2015 dart conf. https://www.youtube.com/watch?v=PnIWl33YMwA
As regards Javascript, that's what they started with, they looked at other languages and gave dart a go, it gave them faster startup and the dart team offered them stateful hot reload.
Anyway working in the chrome space, they prob didn't know that Kotlin existed pre 2015 and prob would have gone with Python if could.
It loaded 2MB (443kB gzip) of JS for that single button.
How many real world apps are a 'single button' though? If its a fixed overhead then I'm cool with it for anything more than a contact form.
It's not optimized at all, and they say so, so this is really jumping the gun for an alpha tech preview.
Is there anything that describes architecture of the verb? Like https://quark.sciter.com/ or something ...
My guess: it is a JavaVM combined with CEF(WebKit) to achieve actually what?
My guess: it is a JavaVM combined with CEF(WebKit) to achieve actually what?
The Kotlin compiler has multiple backends and can target JS and native code (the latter via LLVM) in addition to JVM bytecode.
I'm not sure I understand. Is this essentially a cross-platform tool, like Electron?
shit
I'm surprised Kotlin has a Slack instead of a Discord. The biggest React, Vue, Svelte, and Deno communities are on Discord.
And yet people already rushing to conclusions about code size.