4 ms·

Interesting. I use full Vue for this quite a lot, mount onto specific DOM points, replace their content with (most commonly) an enhanced form, or a data table.

Interesting. I use full Vue for this quite a lot, mount onto specific DOM points, replace their content with (most commonly) an enhanced form, or a data table. Works well, costs 30Kb plus compat layers. You can argue all day long about the cost of 30Kb, but then you put a 200Kb image in your header. Anyway, looking at the docs, my approach wouldn't be as easy in vue-petite. It looks like Components have been functionally gutted. You can still approximate something, but you seem to lose a lot of ecosystem benefits of Vue. Theirs looks great for Ultimately, this all seems like something coverage and tree-shaking should be able to do. If you're only using 5Kb of Vue, only 5Kb should be bundled. One day, eh? Until then, is the additional 25Kb actually hurting your users?

conradfr 5y ago
I think it's supposed to work that way in Vue 3 as you don't import the full Vue script anymore. Also as long as we're talking about Vue, people that have Vue 2 apps and missed the 3.1 release announcement (I don't remember seeing it on HN's frontpage) should check it out, there is a compatibility layer that works really well to migrate progressively. I started with this post https://blog.ninja-squad.com/2021/06/07/what-is-new-vue-3.1/ https://blog.ninja-squad.com/2021/06/07/what-is-new-vue-3.1/
- dustymcp 5y ago
  Yeah we are still upgrading, migrating it progressively is still a chore
- robflynn 5y ago
  I did miss this! Thank you for mentioning it. I've been putting off a Vue2 -> 3 migration for a bit now.
- oliwarner 5y ago
  And they said Python 2 ⇒ 3 was difficult ;) Unfortunately the major blocker (for me) is the lack of IE11 support and the bloody paying customers who refuse to move off IE11. One day they'll be gone.
mklepaczewski 5y ago
200kb image doesn't block rendering, and while somewhat important, it's not the content the user came to see. 30kb might not be much, but this has to be downloaded, parsed, compiled and executed. These 30kb fight for bandwidth and CPU with other resources or even apps running on the same machine. Sometimes it's fine, but sometimes... Sometimes one component is generated only after another one has loaded, which itself depends on other components, each of which might depend on other resources. It might get pretty bad really quickly. Usage of JS when done right is fine, but it's really easy/convenient/common to do it badly.
- oliwarner 5y ago
  For the little it's worth, my 30KB+ full-Vue progressive enhancements don't render block either. It's happening after DOMContentLoaded fires, replacing "real" content with Vue content. And yes, they use more CPU and RAM than -petite. My point there was that a lot of people focus on a bandwidth argument while their sites use [comparatively] massive blobs of media. 3MB bitmap image on their CMS uploaded by Sean in marketing because he doesn't know any better. That sort of thing. Broadly speaking, I don't disagree. There's a lot of truly awful JS out there, wasting cycles doing things that CSS should be handling, but I think the tooling is slowly getting better.
- aeturnum 5y ago
  I think that package size is a useful gut check about how you're delivering your web app. It's hard to screw up delivering a 100kb package, but it's pretty easy to screw up delivering 5 megs. You can probably also deliver 5 megs in a way that doesn't block anything - but you may not need to devote eng resources to doing that until you reach a certain package size.
rk06 5y ago
Vue uses vdom is render target agnostic. While petite-vue only targets DOM and does not use render function. Thus petite Vue can have much smaller size than Vue. TBH, Lack of ecosystem will be a hurdle here, then again, if you want to leverage multiple other libraries, then you might as well use Vue directly
onion2k 5y ago
Until then, is the additional 25Kb actually hurting your users? Not really. Nor is an extra 30KB font file. Or an additional 50KB for an icon set. Or an extra 18KB for a better select box. Nor is that 200KB header image. Why not add that 50KB analytics script too? The extra 40KB for a nice a animation library is useful. You need to add 150KB for a UI component library. And so on, all the way until your page is a 2MB download.. Any individual incremental increase can be justified as part of the page weight, but a few KB here, a few more there, and your site suffers death by a thousand cuts. You have to worry about the extra 25KB here and there if you're going to keep the overall size within a sensible performance budget.
- pier25 5y ago
  This. I always go to Bundlephobia before deciding to use an NPM dependency. https://bundlephobia.com/ https://bundlephobia.com/
  - niutech 5y ago
    Actually Petite-Vue is 6.4KB gzipped: https://bundlephobia.com/package/petite-vue@0.2.3 https://bundlephobia.com/package/petite-vue@0.2.3, whereas Alpine.js 2 is 8.3KB gzipped: https://bundlephobia.com/package/alpinejs@2.8.2 https://bundlephobia.com/package/alpinejs@2.8.2
- oliwarner 5y ago
  I absolutely agree with the gross sentiment —CPU time and bandwidth are expenses that should be argued— but your argument omits two key items: developer time and UX benefit. In my case, using full-fat Vue lets me do a swathe of complex stuff, pulling in libraries and components we use elsewhere, that also do piles of complex stuff, and it only takes me a couple of hours to progressively enhance a big form, which makes it nicer for the user with pro-active validation, breaking the thing into a wizard, easy dynamic lookups, etc. My work increases conversions, creams KPIs. Is that worth 30KB? Every day of the week. Can I batter it down to 20KB? Probably, but it'll take me at least twice as long this time, possibly make the work output less reusable and cost the client twice as much. Is that 10KB worth it? Maybe, maybe not. Don't get me wrong, I'm not the sort of person who throws JS everywhere. I'm a Django developer who will always push to SSR over SPAs... But I also realise there is occasionally a business case for a but of reasoned splurging. Again, my hope is that within a couple of years tree-shaking gets good enough to automate this nonsense, trim out everything that isn't used.

conradfr 5y ago

I think it's supposed to work that way in Vue 3 as you don't import the full Vue script anymore. Also as long as we're talking about Vue, people that have Vue 2 apps and missed the 3.1 release announcement (I don't remember seeing it on HN's frontpage) should check it out, there is a compatibility layer that works really well to migrate progressively. I started with this post https://blog.ninja-squad.com/2021/06/07/what-is-new-vue-3.1/ https://blog.ninja-squad.com/2021/06/07/what-is-new-vue-3.1/

dustymcp 5y ago
Yeah we are still upgrading, migrating it progressively is still a chore
robflynn 5y ago
I did miss this! Thank you for mentioning it. I've been putting off a Vue2 -> 3 migration for a bit now.
oliwarner 5y ago
And they said Python 2 ⇒ 3 was difficult ;) Unfortunately the major blocker (for me) is the lack of IE11 support and the bloody paying customers who refuse to move off IE11. One day they'll be gone.

mklepaczewski 5y ago

200kb image doesn't block rendering, and while somewhat important, it's not the content the user came to see. 30kb might not be much, but this has to be downloaded, parsed, compiled and executed. These 30kb fight for bandwidth and CPU with other resources or even apps running on the same machine. Sometimes it's fine, but sometimes... Sometimes one component is generated only after another one has loaded, which itself depends on other components, each of which might depend on other resources. It might get pretty bad really quickly. Usage of JS when done right is fine, but it's really easy/convenient/common to do it badly.

oliwarner 5y ago
For the little it's worth, my 30KB+ full-Vue progressive enhancements don't render block either. It's happening after DOMContentLoaded fires, replacing "real" content with Vue content. And yes, they use more CPU and RAM than -petite. My point there was that a lot of people focus on a bandwidth argument while their sites use [comparatively] massive blobs of media. 3MB bitmap image on their CMS uploaded by Sean in marketing because he doesn't know any better. That sort of thing. Broadly speaking, I don't disagree. There's a lot of truly awful JS out there, wasting cycles doing things that CSS should be handling, but I think the tooling is slowly getting better.
aeturnum 5y ago
I think that package size is a useful gut check about how you're delivering your web app. It's hard to screw up delivering a 100kb package, but it's pretty easy to screw up delivering 5 megs. You can probably also deliver 5 megs in a way that doesn't block anything - but you may not need to devote eng resources to doing that until you reach a certain package size.

rk06 5y ago

Vue uses vdom is render target agnostic. While petite-vue only targets DOM and does not use render function. Thus petite Vue can have much smaller size than Vue. TBH, Lack of ecosystem will be a hurdle here, then again, if you want to leverage multiple other libraries, then you might as well use Vue directly

onion2k 5y ago

Until then, is the additional 25Kb actually hurting your users? Not really. Nor is an extra 30KB font file. Or an additional 50KB for an icon set. Or an extra 18KB for a better select box. Nor is that 200KB header image. Why not add that 50KB analytics script too? The extra 40KB for a nice a animation library is useful. You need to add 150KB for a UI component library. And so on, all the way until your page is a 2MB download.. Any individual incremental increase can be justified as part of the page weight, but a few KB here, a few more there, and your site suffers death by a thousand cuts. You have to worry about the extra 25KB here and there if you're going to keep the overall size within a sensible performance budget.

pier25 5y ago
This. I always go to Bundlephobia before deciding to use an NPM dependency. https://bundlephobia.com/ https://bundlephobia.com/
- niutech 5y ago
  Actually Petite-Vue is 6.4KB gzipped: https://bundlephobia.com/package/petite-vue@0.2.3 https://bundlephobia.com/package/petite-vue@0.2.3, whereas Alpine.js 2 is 8.3KB gzipped: https://bundlephobia.com/package/alpinejs@2.8.2 https://bundlephobia.com/package/alpinejs@2.8.2
oliwarner 5y ago
I absolutely agree with the gross sentiment —CPU time and bandwidth are expenses that should be argued— but your argument omits two key items: developer time and UX benefit. In my case, using full-fat Vue lets me do a swathe of complex stuff, pulling in libraries and components we use elsewhere, that also do piles of complex stuff, and it only takes me a couple of hours to progressively enhance a big form, which makes it nicer for the user with pro-active validation, breaking the thing into a wizard, easy dynamic lookups, etc. My work increases conversions, creams KPIs. Is that worth 30KB? Every day of the week. Can I batter it down to 20KB? Probably, but it'll take me at least twice as long this time, possibly make the work output less reusable and cost the client twice as much. Is that 10KB worth it? Maybe, maybe not. Don't get me wrong, I'm not the sort of person who throws JS everywhere. I'm a Django developer who will always push to SSR over SPAs... But I also realise there is occasionally a business case for a but of reasoned splurging. Again, my hope is that within a couple of years tree-shaking gets good enough to automate this nonsense, trim out everything that isn't used.