4 ms·

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 h

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.

cromwellian 5y ago
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.
- pjmlp 5y ago
  On the same vein, everyone that bet the farm into GWT, ended up rewriting their application.
  - cromwellian 5y ago
    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.
    - pjmlp 5y ago
      Sure it is being used, just like Java 1.4 still is.

cromwellian 5y ago

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.

pjmlp 5y ago
On the same vein, everyone that bet the farm into GWT, ended up rewriting their application.
- cromwellian 5y ago
  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.
  - pjmlp 5y ago
    Sure it is being used, just like Java 1.4 still is.