6 ms·
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 g
by ng12 6y ago
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.
- tiborsaas 6y agoDev 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.
- deleted 6y ago[deleted]
- ng12 6y agoThe 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.
- dirtnugget 6y agoAs 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
- tiborsaas 6y agoWith 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.
- thinkloop 6y agoWait 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.
- aardvark1 6y agoCan't wait to figure out how to staff a 5+ person engineering team who can deliver a SvelteJS product , oh and also maintain the codebase for 5+ years when likely a small minority (if any) of the original engineers are still around!
- thinkloop 6y agoIt's about a 4 hr learning curve from react - but I'm not shilling svelte, just showing that there are already superior models. Pre-compiling is really objectively better in every way except popularity, and that will change because of its betterness.
- aardvark1 6y agoSuperior in what way? Do you really trust that SvelteJS is going to be a better product in 5 years over something like React that Facebook invests millions of dollars every year?
- deleted 6y ago[deleted]
- thinkloop 6y agoA hello world react app with everything you would typically need (redux, router, etc.) starts at 100K+. Svelte is a couple K. A react app has massive abstraction to render on every frame, Svelte compiles out the framework to render instant straight vanilla js (wins all perf tests). Pre-compiling allows for beautiful syntax and more flexible app structure, since you aren't limited to the runtime. SSR and code-splitting are significantly easier and more straightforward. React is designed for a billion-user site and it shows. There really is zero cost to pre-compiling except mind-share, and only benefits. Of course an F100 company has many concerns above tech awesomeness, so no judgement on your selection criteria. But I assure you this movement is coming, react/vue/angular will adapt/change and/or people will move to Svelte-like solutions. You can already see it happening in the article facebook released today [1]: "By using rems, we can respect user-specified defaults and are able to provide controls for customizing font size without requiring changes to the stylesheet. Designs, however, are usually created using CSS pixel values. Manually converting to rems adds engineering overhead and the potential for bugs, so we have our build tool do this conversion for us." [1] https://news.ycombinator.com/item?id=23116300 https://news.ycombinator.com/item?id=23116300
- goatlover 6y ago2 more MBs is going to matter to some users with limited data or bandwith.
- ng12 6y agoSure, 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?
- hundchenkatze 6y agoYou'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/T-carrier#Transmission_System_... [1] https://en.wikipedia.org/wiki/3G#Data_rates https://en.wikipedia.org/wiki/3G#Data_rates
- entha_saava 6y agoIn practice, 3G is quite slower than that.
- untog 6y agoThat 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.
- ng12 6y agoMost 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.
- milesvp 6y agoI 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.
- nojito 6y ago>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.