re: Send Ember on a diet and thrive innovation VIEW POST

FULL DISCUSSION
 

Hello! thanks for writing out your thoughts on this :)
couple things:

mono-repos:

  • imo, this is a concern of yarn workspaces, and would work independent of any SPA ecosystem. Ember, React, etc. :)

Bundle size:

  • it seems like you're reporting bundle sizes pre-gzip. It's tricky cause no one has ever said that all bundle sizes should be min+gzip... but when you hear about how small Vue and React are, that is def post min+gzip. For example, my entire canary app (which has a bunch of extra stuff, cause canary), without embroider, is 458KB (min+gzip), and more than half of that is libsodium. Ember itself is 125kb :) Just something to consider. The engineer side of me would be all like "add units!", but, I mean, KB is already a unit... so, idk how to best represent or know what kind of thing KB (min+gzip) is. :shrug:

Also, feel free to poke around the bundle analysis: emberclear.io/bundle.html

It would be great if the top 100 addons would have TypeScript definitions and are coded to work with TypeScript.

I agree with this so much. Unfortunately, it seems there is a schism in the js world :(
I'm hoping that this becomes less and less over time, as there are more success stories with Typescript. People just don't like being told they're wrong, or don't like learning it. :shrug: idk. it's weird.

Overall, I actually agree with most of what you've written <3

Just a couple last things though:

It also feels like focusing on backward compatibility slows us down a lot.

This is a HUUUUUUGE bonus for long-term projects though, and especially large projects who aren't as capable of adopting the latest and greatest patterns at the drop of a hat.
However, one of the goals of embroider, editions, and all the recent efforts is to make everything modular enough for our weekend worriers to "just pick up ember" and build something cool in a couple days.

Glimmer.js

idk how long glimmer.js as an independent project/app ecosystem is going to live? I know some things need to be supported, and many of the core projects live on in ember, but I think the future of npm-installing your way to ember is going to be less about glimmer, and more about answering the question "what makes up an application?" -- like starting with the glimmer components and vm, adding services, adding routing, etc.

that's just my perspective on stuff. I have no official knowledge from anywhere

 

without embroider, an octane app:

Built project successfully. Stored in "dist/".
File sizes:
 - dist\assets\auto-import-fastboot-d41d8cd98f00b204e9800998ecf8427e.js: 0 B
 - dist\assets\octane-app-ce547d91fdbeb1ed608d28fde680522d.js: 4.79 KB (1.4 KB gzipped)
 - dist\assets\octane-app-d41d8cd98f00b204e9800998ecf8427e.css: 0 B
 - dist\assets\vendor-cb080f97ddf7f4d173b22f81be86eb28.js: 647.89 KB (164.71 KB gzipped)
 - dist\assets\vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B

164.71KB gzipped
(I agree that this is still large)

With embroider


$ ember build -prod
Environment: production
Built project successfully. Stored in "dist/".
File sizes:
 - dist/assets/chunk.23debe7eaa558bf9c016.js: 188.2 KB (43.08 KB gzipped)
 - dist/assets/chunk.ddf452a573e57637cd4b.js: 12.47 KB (3.07 KB gzipped)
 - dist/assets/octane-app.css: 0 B
 - dist/assets/vendor.js: 477.96 KB (125.92 KB gzipped)

126kb
Still large for an empty app, but an improvement!

 

Thanks for the details about build sizes. This is exactly what I wanted to post as well but didn't have the time to. You were faster than me 😎 For us not only the gzip size is important especially for our e-commerce projects also the parse time of the JS is important. Many of the e-commerce businesses we work with heavyly rely on mobile traffic so it's even more important to ship less JS.

code of conduct - report abuse