Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can You Afford It? Real-World Web Performance Budgets

infrequently.org

Post reply on HN
Print view View original

101–110 of 130 posts

Re: Can You Afford It? Real-World Web Performance Budgets

#101

Post by kakarot »

tboyd47 wrote: post #97

Front-end developers could solve all of this by just learning the base technologies of HTML, HTTP, CSS, and JS really well and ignoring everything else. We're at a beautiful point in web development where browsers are finally unified on open standards, and we're all too locked into these outdated JS frameworks to take advantage of it.

It's important to strike a healthy balance between reinventing the wheel and locking yourself into a bulky framework. Whether you are building a personal project, or working on another's time, in the early phases your #1 concern should be speed of development. If a compact, properly modularized, battle-tested tool that completes your desired task is readily available, should you really be wasting your time writing something that's been done a thousand times before?

I've been around the block with popular front-end frameworks. The first one I've truly found to be a joy to use is Mithril.

Unlike React, a framework that's gotten a lot of buzz here lately, it's more than just a view library. There is a routing paradigm in place along with a few other goodies. Yet it all weighs in at Check out its performance compared to a few other popular frameworks:

https://mithril.js.org/framework-comparison.html

Re: Can You Afford It? Real-World Web Performance Budgets

#102

Post by tjoff »

kakarot wrote: post #99
amelius wrote: post #95

Earlier quoted context omitted.

And then there are media companies that try to shoe-horn 1) into 2) because it gives them more control over the user and allows them to track the user and serve them ads. If only there was a way to collectively punish this type of behavior.

Like ad blockers and informed browsing habits?

No, not that. Because that has not worked at all and I see no reason for why it should start working tomorrow.

Re: Can You Afford It? Real-World Web Performance Budgets

#103

Post by nojvek »

mrighele wrote: post #75
TeMPOraL wrote: post #67

Earlier quoted context omitted.

This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation? Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)

This. Every major client lib out there uses some variant of vdom. If this dom diffing was natively supported, browser would request with current dom hash and server could efficiently reply with a diff that both server and client can compute to be the same new hash.

If it's forms. Client calls server with base hash + changes made by client and server replies with. Base hash + new diff to apply. The new diff includes validation changes.

It's trees and diffs all the way down.

Re: Can You Afford It? Real-World Web Performance Budgets

#104

Post by pcmaffey »

mrighele wrote: post #75
TeMPOraL wrote: post #67

Earlier quoted context omitted.

This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation? Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)

This is exactly what React's virtual DOM does. Maybe the future is making the virtual DOM native to the browser?

Bundle React with Chrome? Or how about a browser package manager that could cache and reuse all these common js libraries used on so many sites?

Re: Can You Afford It? Real-World Web Performance Budgets

#105

Post by Can_Not »

samsonradu wrote: post #70
davidgh wrote: post #56

Earlier quoted context omitted.

This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render w…

> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.

Credit card info, passwords...

Re: Can You Afford It? Real-World Web Performance Budgets

#106

Post by jcelerier »

adventured wrote: post #58
saas_co_de wrote: post #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.

No, you need to assess where your customers are and focus there. Just because a market is growing, it doesn't mean that market contains customers for your product. That depends on numerous variables including pricing. The US will add ~$570 billion to its GDP this year. That's equal to 25% of India's entire economy. An increasingly large part of Europe is back to generating solid growth again. Even Japan is showing si…

> You don't need to focus on 2G markets if there are few customers there for your products.

as someone who used to have a poor internet access, rest assured that I will have no sleep until every review website and comment section has something about how slow your website / app / whatever is. These ones generally don't lag.

Re: Can You Afford It? Real-World Web Performance Budgets

#107

Post by naasking »

virmundi wrote: post #5

Do 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 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.

Even so, you can have that experience with server-side rendering and simpler client-side updating.

Re: Can You Afford It? Real-World Web Performance Budgets

#108

Post by naasking »

Can_Not wrote: post #105
samsonradu wrote: post #70

Earlier quoted context omitted.

> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.

Credit card info, passwords...

You're already submitting it to the server. It's no less secure sending it back if there's a problem.

Re: Can You Afford It? Real-World Web Performance Budgets

#109

Post by lastofus »

emp_ wrote: post #40

Just pushed live an app today that I had to cave and add babylon-polyfill so it would work in IE 11 after trying to polyfill a dozen missing es6 runtime features from various sources. That made the final JS output 25% larger, a 90kb increase from the polyfill library alone, so here's a serious optimization waiting to happen (the natural dying of an older browser).

I ran into the exact same issue not too long ago.

As an alternative, check out:

https://polyfill.io/v2/docs/

Re: Can You Afford It? Real-World Web Performance Budgets

#110

Post by hawski »

DCoder wrote: post #86
bildung wrote: post #43

Earlier quoted context omitted.

> What about all of the information that was already in the submitted form? Of course the form gets returned from server validation will all user input prefilled? At least with Django that's the default behaviour.

Does "all user input prefilled" include file uploads?

It's not complicated. Server could offer to use already uploaded file or selecting a new one. Identifying it with session cookie or some kind of file hash.
Post reply on HN