Can You Afford It? Real-World Web Performance Budgets
infrequently.org
Can You Afford It? Real-World Web Performance Budgets
1–10 of 130 posts
Re: Can You Afford It? Real-World Web Performance Budgets
#2I think the article makes some valid points, but it's important to remember that PWAs are just getting going. The existing SPA frameworks are still a little crude at the moment, but there is definite progress. For my own app (https://usebx.com), I eventually ended up writing my own front end framework, as existing frameworks at the time felt rather bloated. Now, however, things are starting to look better with the likes of Vue.js etc coming on the scene. I also feel that PWA development will explode once Apple ships service workers with Safari, and that will bring along with it even more motivation to innovate in this space.
Re: Can You Afford It? Real-World Web Performance Budgets
#3It's remarkable how much js gets loaded onto a page (mainly due to libraries) vs. how much of its functions are needed for what the web developer is trying to do. There just is not a whole lot of use cases for the big libraries unless you're doing something really intensive like a drawing app.
Re: Can You Afford It? Real-World Web Performance Budgets
#4> 45% of mobile connections occur over 2G worldwide
> 75% of of connections occur on either 2G or 3G
this is so important. if you want growth you need to be making a product for growing markets.
Re: Can You Afford It? Real-World Web Performance Budgets
#5Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better.
I know we switched because front end experts told us that users found the full refreshes annoying. They said that users really wanted native desktop like seamless change pages. Never did I see proof of these claimed. Is the modern JS based design our cubicle moment? Did we get suckered in by experts making productivity claims with nothing to back them up?
Re: Can You Afford It? Real-World Web Performance Budgets
#6Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…
I think there is (limited) semantic value to single page forms. They also encourage api first design. Is this always worth it? Certainly not. But it does have value.
Re: Can You Afford It? Real-World Web Performance Budgets
#7Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…
I think the problem is in all the data-binding of JSON responses to the front end. I don't care what anyone says, it's slow.
Re: Can You Afford It? Real-World Web Performance Budgets
#8Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…
I think the problem is in all the data-binding of JSON responses to the front end. I don't care what anyone says, it's slow.
If you don't care what anyone says, then I guess there's no point in presenting data.
Re: Can You Afford It? Real-World Web Performance Budgets
#9Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…
I prefer the "classic" MVC design approach. It may not be flashy and some may turn their noses for not being hip, but its easy to develop, test, and scale. I certainly use JavaScript, but I use it when it adds to the workflow of the application.
Re: Can You Afford It? Real-World Web Performance Budgets
#10Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…
Good single-page app development is just as clean (I've done both), and will be faster over the long term, and scales out better. It keeps all the components cacheable and DRY. The benefits are all about data locality. If your code and data are cached on the client, then the only the minimal subset that has changed needs to be invalidated and updated. If it's only data that has changed, that's all that's retrieved. If it's only code, same goes here. For old-school MVC, if a single character has changed, the whole page is invalidated and must be re-rendered.
The tangible benefits when done right (there's lots of crappy code in every language and system) are greatly reduced user-perceived latency (the system reacts immediately, indicating that something is currently being updated, etc).