The Cost Of JavaScript - 2023

[@yix7347]

Amazing talk! I watched twice. I just feel some slides need to be updated. For example, the price category picture you used here is identical to the one from 2018. The phone price has gone up a lot since then.

[@shai_reznik]

Great video as always Addy! Wanted to share something about "Resumable Hydration" mentioned on 28:42: (For context to the other viewers, I'm part of the Qwik team, but I'll write my own POV and happy to get feedback) I view Resumability as a different concept from hydration. To me - Hydration is about executing JS on browser load time to attach event listeners and build the Framework + App state. In Resumabilty - all of this happens on the server, then on client it prefetches the bits of JS the page could need to the cache. And then on user interaction it "lazy executes" that code. So that's why we started promoting the "JavaScript Streaming" metaphor (just like video streaming, but with more sophisticated "buffering", where it buffers based on user interaction vs compared linear buffering of a video) So I personally prefer calling it "Resumability" instead of "Resumable hydration". but as I said - would love to hear any feedback and other opinions. Thanks again for this video and your incredible educational work in general!

[@gperaltascura]

I look forward for each "The Cost of JavaScript" posts each year. Thank you Addy!

[@AddyOsmani]

I'm glad if it the yearly entries are of any help. More to come!

[@gzargary]

Hands down the best video I’ve seen giving overview of current challenges in building performant websites. It not only highlights the problems, but also gives hints, ideas, specific tools and frameworks without sparking a “X vs Y, take side” destructive discussion. Keep rocking Addy. 🚀

[@AddyOsmani]

Thanks for the kind words! Just wanted to say how much I deeply appreciate folks taking the time to share if this talk was helpful in any way. It really helps energize me to share more on this topic.

[@BalaevArif]

So much useful information! Thank you, Addy! You are helping to look at problems from simpler view point. Excellent explanation

[@AddyOsmani]

Glad it was helpful! :)

[@kxmode]

A summary for future reference: + Building interactive web experiences often involves sending large amounts of JavaScript to users that impact performance. + It's crucial to balance the use of JavaScript to ensure quick loading experiences and maintain a high-quality user experience. + The "Zero JavaScript" trend has emerged, emphasizing reliance on default browser capabilities. + Various rendering patterns have evolved, such as server-side rendering (SSR), Islands architecture, and partial hydration. + SSR generates the full HTML on the server, avoiding the need to send JavaScript to the client, but it may delay interactivity for single-page apps. + Progressive hydration selectively loads and renders components to improve performance. + Optimizing JavaScript bundles can enhance download speeds, reduce memory usage, and decrease CPU costs. + JavaScript execution time is vital, but parse and compile costs are less important. + It's essential to consider hardware optimization, CPU performance, thermal throttling, cache size, and power constraints on various devices. + Network latency and bandwidth also affect web performance. + Understanding the actual cost of JavaScript and optimizing for hardware and network conditions can significantly improve web performance. + The cumulative effect of frameworks, libraries, UI components, third-party code, trackers, and analytics, known as the "JavaScript helpful tax," can significantly impact performance. + The goal is to provide users with a fast, interactive experience as soon as possible. + Strategies to improve web application performance include dynamically importing components, bundle splitting, code splitting based on routes and components, and importing on visibility. + Different approaches to rendering and hydration include islands architecture, progressive hydration, resumable hydration, react server components, streaming server-side rendering, and selective hydration. + I've highlighted the importance of performance budgets and testing on real devices. + I recommend a free performance pattern book you can access on patterns.dev.

[@eo4wellness]

"Sweeping water back into the ocean" was hilarious footage, as well as a very funny analogy.

[@ytadi9229]

Thank you. Was always confused about what is what Hydration. Got a good idea from this.

[@bryikcode]

i have follow u in LinkedIn for long time , i just get this video by coincidence and i really like it and it was very useful thank you

[@derekiwasiuk6130]

You do the editing? this is amazing. Amazing content, well done.

[@LaxMariappan]

Thanks Addy, enjoyed the video, this topic is need of the hour

[@stefanjudis]

Dang!!! 💙 That's a lot of info very well put together and presented. Fabulous job! 👏 Thank you for sharing, Addy!

[@AddyOsmani]

Thanks so much for the kind words, Stefan! Glad if any of it was helpful :)

[@NeilMeskauskis]

33:56 Can we also stop taking large screen sizes for granted? Start building sites for smaller notebook screens again

[@ShashiMishra1990]

Thank you for making this video on javascript, this is wonderful explanation of too many things in such a short video, people need to spend more time figuring these things and implementing it on their own. This should be mandatory for everyone to atleast know and implement few to give good customer experience for people having low end phones.

[@AddyOsmani]

You're very welcome!

[@kenjimiwa3739]

Great overview of different JS rendering patterns

[@AdamFiregate]

Great summary, thank you! 👍🙂

[@1ABK]

Server components are like the repeated pattern previously also language frameworks have tried and been mostly bad at. Qwik tries dealing with Hydration, by replacing it with Resumability.

[@TheVitkuz]

Grate talk! Lots of insight and things to think about

[@FernandoBasso]

Very useful content, insights and ideas. Thanks for sharing! How are those magnificent slides created? The animations, colors, everything is perfect!

[@AddyOsmani]

Thank you! I hope it's helpful in some way. I usually create/illustrate my slides in a design tool (like Sketch or Figma) and then compose the final versions and animations in Keynote.

[@marciodelimapassos7651]

Thanks, mate! Saudações do Brasil =]

[@davatron5000]

Great talk per usual, Addy!

[@AddyOsmani]

Thanks for the kind words :)

[@sergeykaimin9616]

thanks, both video and learning patterns book is good

[@nakulgopal60]

Can anyone explain, why did he said JS is CPU bound ?

[@matthewwilson2369]

This is an excellent video. Thanks.

[@alaska90210]

Great work done, thnx

[@juancarlosgallegos3902]

Code splitting 20:43

[@sergiobotasierra1157]

Great talk sir, What are you using to animate your presentations?

[@AddyOsmani]

Nothing fancy, just Keynote for the most part :)

[@Yusuf-ok5rk]

wonderful content. I appreciate your works so much.

[@AddyOsmani]

Glad you enjoy it! I'm happy if it is helpful at all

[@aissa.bouguern]

Should we really care that much about users having devices of ~30$ ? Please don't get me wrong, I've a 150$ worth Xiaomi mobile. I am not obscenely rich and I'm not looking at anybody from a mountain's peak. I'm just asking a question. PS: Great video btw. You're one of guys every JS developers should follow. I'm one of your oldest followers. I discovered your blog once upon a time in 2011 while I was trying to learn how to write a jQuery plugin :) That was before you joined Google Chrome team.

[@AddyOsmani]

Great question. I think every business should aim to either (roughly) know the target device classes of the users they are building for (e.g. low, mid, high-end) or if possible look at their analytics/telemetry to see what folks are actually using. Unless you're explicitly targeting growth markets, it's very possible a a $30 phone isn't what you need to target, but folks should base this on data when they can. What's surprised me (regularly) on sites with 5-100M users is after iPhone, device class/speed drops off really fast. Many of those that are popular Android devices from malls, cellphone stores etc. are way way way slower than folks might guess (because they're average/affordable) and Snapdragon chips haven't gotten that much faster over the years.

[@Francisco-vl5ub]

4:57 for personal reference

[@RafaelCorreaGomes]

Excellent, thank you for sharing it!

[@AddyOsmani]

Glad you enjoyed it!

[@Kubenetik]

Thanks you a lot!

[@Hinata_azzahra10]

Thank sir

[@kyonas6047]

javascript: faster first tjme loading ..bad performance webassebly : slower first time loading ..good performance 💕 i love Javascript even tho I don't want to program in it i wanna make tools to help devolopers currently doing cli in deno using zig(a strange compo if u asked me)

[@GoLDnTRiXX]

Awesome! Thx

[@HartleySan]

The takeaway (which is the same as it has always been): Avoid JS as much as possible (although that's usually not very practical given time constraints often put on devs and the asks).

[@Panikulam]

9:05 I work for a web browser called Chrome. hmmmm interesting is that a new browser?

[@abhijithsj1]

Thank you

[@AddyOsmani]

You're welcome 😊

[@PatrickPease]

Is it genuinely a concern that programmers don't understand that some computers are limited? Are we not always at all times trying to reduce the demands our code places on hardware? If your guys can't understand the limitations, force them to work on an old machine or fire them.

[@PalakVC]

🔥🔥🔥

[@theklr]

🙏🏽

[@imrannarmi-o3q]

javascript is king

[@walterlol]

I don’t quite agree with this. There are tons of optimisations.

[@HugoPineda83]

great talk, but all these pictures are very distracting and doesn't add any value

[@lodoss118]

All i see is jank with javascript

[@o_glethorpe]

If you render javascript on the server and pay someone like vercer for it you are a fool. If was like, 20 years ago, ok nice ideia but now? most people these days have very powerful devices, even the cheaper ones are pretty powerful and are getting more powerful every time. Same goes to internet availability. And you can always provide two versions of the frontend with one being more simple. Way more cheaper than those vercel fees.