aarongustafson

Details on what Chrome & Edge are actually sending to their spellcheck APIs as well as how to protect sensitive user data using HTML.

You mean this SSL? http://www.symantec.com/connect/blogs/gogo-inflight-internet...

Comcast: https://www.aaron-gustafson.com/notebook/the-network-effect/

Some also block JS (sometimes accidentally). Remember Sky? https://www.theguardian.com/technology/2014/jan/28/sky-broad...

There is a line: support vs. optimization.

Support everyone with a browser & internet access, optimize for the stuff that has the greatest market share or where you can do the most good and stand a good chance of having your dependencies met.

I did some actual math on progressive enhancement costs vs. graceful degradation in consideration of reach: https://medium.com/@AaronGustafson/the-true-cost-of-progress...

You can use JavaScript, but it needs to be an enhancement, not necessary for the user to do what they need to do.

You can lazy load libraries for sure. I would still keep those to a minimum, including only what you need. For instance, don’t load all of jQuery if you only need one feature. And use native JavaScript code when you can get away with it—dataset instead of data(), querySelectorAll() instead of $(), etc.

I plan to write up how the site was built and give some hints as to how you can use lazy loading, etc. to your advantage.

Out of curiosity, which browser are you in? I get 87.9K for the homepage, including all dependencies, lazy loaded JS, the SVG hero, etc. Are you getting WebP images or PNG?

:-)

Although minification & GZip should even those out.

Disable JS and view on a small screen :-) It progressively enhances to that size. I’ll be writing about the process and design in forthcoming posts.

Smallest view (240px wide) with no JS renders in 6.9kB (DOMContentLoaded hit at 94ms, Load at 119ms). Also in play: client-side caching with ServiceWorker and some localStorage goodies to speed things up on modern browsers.

You can use a back-end in Python, Node, PHP, or .NET Core. The size of your back-end doesn’t factor in, just the markup, CSS & JS you deliver.

> For application-centric sites (For example, an internal admin app, or a B2B application where SEO and phones aren't the primary interface) why would I spend the money for the extra work?

If you have control over the end-user's environment, by all means do whatever you want. But when you don't (let's say your building an online banking site), you should ensure your real users can access it (and their money) no matter what.

Of course locking into specific technologies is why IE6 continues to persist (Intranets, South Korean banks), so that's some additional food for thought. It may not be a concern in your specific instance but it's a risk if you don't use web standards.

> It's almost as if your use case should determine your strategy.

:-) I wish more folks thought that way. When all you have is a hammer…

> If you're just starting a project out, you have to decided whether it's worth an extra X hours/days/weeks for any given bit of technical improvement

The thing is, PE is all about creating a workable, universal baseline that can be enhanced. It is a Minimum Viable Product. If you don't know if your product is, at its core, fulfilling a need, why spend the extra time making it fancy?

> Where I cut off my robustness work depends on the nature of the project, but every project has some point at which you'd improve user experience more by adding a feature than improving performance. For an early prototype, that point may be quite soon.

A prototype is naturally a quickly assembled thing (often held together by chicken wire and duct tape) that you use to test the viability of an idea. Build prototypes however you want. Of course I'd argue that a bare-bones MVP would be the cheapest way to test an idea, but it doesn't really matter. A prototype should never be your production product unless you know it to be robust though. You should expect to rewrite most of your prototype in order to make it production ready. Unless you follow PE, of course, in which case you should have a solid, usable baseline that you can enhance into your amazing final product.

> I think the author is aware of this, but there are many apps which just don't fit particularly well into a document. It's not clear whether the author really thinks all such apps are trivial (eg detecting your dog's age), but I'd argue there are plenty of substantial apps that don't fit that model well, and benefit substantially from being a full-on js-heavy web app.

I would counter-argue that we naturally gravitate toward doing stuff that's fun for us or gives us the opportunity to show off our skills. We over complicate things because we like challenges. Take the "dog age" example. An MVP would be uploading a photo and having the age guessing take place on the server side. One enhancement would do that via Ajax, another would add tap getUserMedia if it's available. In the end, the product works no matter what. There are very few "apps" that would not work in a PE scenario; it's all in how you look at them. The problems we are solving today on the Web are not new problems.

For a great, brief talk on these topics, watch Adam Silver discuss at EnhanceConf: http://m.youtube.com/watch?v=UlzG6-fI00g