Hacker News Reader

Comment by ng12 | Hacker News Reader

Absolutely agreed. I have never in my life had a stakeholder get on my case because our site was 3mb when it could have been 1mb. I have had many stakeholders get on my case because we couldn't turn around features fast enough, or the site was buggy, or our UX was worse than our competitors. Those are the things that the people who pay me and my team care about and if I could 10x our bundle size for a 1.5x improvement in development speed I would do it in a heartbeat.

View on HN

That depresses me because it's clear who is being ignored here: the user.

A 3MB bundle size instead of 1MB does make a difference, and if you're working on the kind of site that relies on conversions/purchases to succeed then you're absolutely leaving money on the table. Not to mention that Google factors in page load time to rankings.

> our UX was worse than our competitors

If your competitor has a < 1MB bundle and yours is 3MB then any user on a low end Android phone is absolutely going to have a worse UX experience. Maybe stakeholders aren't aware of all this. Maybe you should tell them.

Most of the apps I've worked on don't have conversions and aren't indexed by search engines. One app I worked on recently did have a mobile version that received a small fraction of all traffic, and even then overwhelmingly from relatively modern iOS devices.

It's like all engineering: use the right tools for the job. If low-end Android users are a significant portion of your target audience you have to design your system around that.

Dev experience and productivity is key, but don't forget that 10x bundle size has effects you can't simply dismiss. It does cause a UX problem since a slower pageload is part of the UX.

SEO. Google also takes into account page / paint times.

These are the things your stakeholders probably don't know about but you should.

The majority of the projects I work on target users on desktops with modern browsers. You have to get into the massive 10mb range before noticing any lag, and even then only on an empty cache. SEO isn't a concern either, all of our marketing pages (when we have them) are static sites.

It's all about picking the right tools for the job. If low latency is a business requirement by all means don't use a framework.

As a Frontend Engineer I can assure you there are ways to counter that issues but they're not exactly popular: Server Side Rendering. It adds another step t the build process in which HTML is prerendered, so you get the speed of loading plain HTML. It then loads the actual JS in the background. It's a PITA to implement

With tools like Next.js or Gatsby it's not that bad. We use Next at work on a large scale and it works for us. But do you know what language gives you instant SSR? PHP :) It's funny how we had to invest so much effort to replicate with another language supports out of the box. I've built a blog in a few hours with Craft CMS, perfect tool for the job this case, I didn't even have to touch PHP files, just the templates.

Wait another year or two and your stakeholders will smarten up - users are noticing. Svelte JS, for example, has everything you listed minus the costs. React is very far from the end of the road.

Maturity matters, unfortunately. I've been looking for a chance to try out Sapper but I wouldn't feel comfortable recommending that we start a major new project with it.

Also don't miss out S-js and Surplus.js. They are helpful tools to build reactive tools without VDOM.

I was lucky at one point to work with product owners who understood that latency translated to lost revenue and so they helped champion the idea that engineering excellence was actually valuable, and that squeezing out performance was itself a worthy goal. It helped that we could compare our metrics to comparable sites, and could give upper management bragging rights when our pages loaded faster than bigger higher staffed “competitors”.

But otherwise, I think you tend to be right, in a lot of areas even an extra second of latency doesn’t matter, and more features will move the needle more.

2 more MBs is going to matter to some users with limited data or bandwith.

Sure, that's a trade-off you have to make a decision on when designing the core architecture. If your users are sitting behind corporate T1 connections near an AWS data center bundle size doesn't matter at all. If your users are still on 3G phones it matters a ton. For somewhere in between it becomes a business decision: how much performance are you willing to trade for developer productivity?

You're comparison implies that T1 is faster than 3G, but that's probably not the case except in really poor coverage areas.

T1's maximum data transmission rate is 1.544 megabits per second. [0] While 3G's theoretical maximum is 21.6 Mbit/s for HSPA+. [1]

[0] https://en.wikipedia.org/wiki/T-carrier#Transmission_System_...

[1] https://en.wikipedia.org/wiki/3G#Data_rates

In practice, 3G is quite slower than that.

>I have never in my life had a stakeholder get on my case because our site was 3mb when it could have been 1mb.

As cloud costs become tougher to swallow, this is going to change.

Reply on news.ycombinator.com