Items tagged javascript, alexrussell
Filters: javascript × alexrussell × Sorted by date
Someone asked me today if there was a case for using React in a new app that doesn’t need to support IE.
I could not come up with a single reason to prefer it over Preact or (better yet) any of the modern reactive Web Components systems (FAST, Lit, Stencil, etc.).
One of the constraints is that the team wanted to use an existing library of Web Components, but React made it hard. This is probably going to cause them to favour Preact for the bits of the team that want React-flavoured modern webdev.
It’s astonishing how antiquated React is.
— Alex Russell # 15th August 2023, 9:15 pm
A Netflix Web Performance Case Study (via) Fascinating description of how Netflix knocked the 3G loading times of their homepage in half for logged-out users by rendering the React templates on the server-side and using the bare amount of vanilla JavaScript necessary to get the homepage interactive—then XHR prefetching the full React code needed to power the subsequent signup flow. Via Alex Russell, who tweets “I’m increasingly optimistic that we can cap JS emissions by quarantining legacy frameworks to the server side.” # 6th November 2018, 8:54 pm
Can You Afford It?: Real-world Web Performance Budgets. Alex Russell’s magnum opus on web performance budgets in 2017. He proposes a baseline testing device equivalent to a $200 Android phone on a slow 3G network emulated at 400ms RTT/400Kbps transfer and encourages a goal of 5s time-to-interactive on first load and 2s TTI for subsequent views. This means around 130kb of gzipped JavaScript—challenging but not impossible with modern JavaScript frameworks. # 23rd October 2017, 1:51 pm
If HTML is just another bytecode container and rendering runtime, we’ll have lost part of what made the web special, and I’m afraid HTML will lose to other formats by willingly giving up its differentiators and playing on their turf.
— Alex Russell # 17th March 2010, 10:37 pm
Dojo: Still Twice As Fast When It Matters Most. Alex Russell shows how Dojo out-performs jQuery on the TaskSpeed benchmark, which attempts to represent common tasks in real-world applications and has had code that have been optimised by the development teams behind each of the libraries. # 28th January 2010, 10:40 pm
It’s interesting to me how much [Closure] feels like a more advanced version of Dojo in many ways. There’s a familiar package system, the widgets are significantly more mature, and Julie and Ojan’s Editor component rocks. The APIs will feel familiar (if verbose) to Dojo users, the class hierarchies seem natural, and Closure even uses Acme, the Dojo CSS selector engine.
— Alex Russell # 6th November 2009, 7:35 am
JavaScript cannot save you. Even if it could, you should not let it, for the price of this short-term salvation is the end of what you like about the web.
— Alex Russell # 19th August 2009, 11:33 am
And Now For Something Entire... Oooh! Shiny! Alex Russell on O3D, the new 3D browser plugin from Google that makes OpenGL accessible to JavaScript (and embeds V8 so performance won’t suck even on slower browsers). # 22nd April 2009, 12:19 pm
Making queries faster isn’t in the critical path for improving the real-world performance of any Dojo apps I know of, and I bet the same is true for JQuery users. Reducing the size of the libraries, on the other hand, is still important. Now that we’re all fast enough, it’s time that we stopped beating on this particular drum lest we lose the plot and the JavaScript community continue to subject itself to endless rounds of benchmarketing.
— Alex Russell # 22nd August 2008, 8:12 am
Dojo 0.9 Update. Big changes are under way in the Dojo camp. # 29th April 2007, 8:18 pm
The website to web application gradient. Jeremy snapped this cunning illustration at my JavaScript Libraries panel at the Web 2.0 Expo. # 20th April 2007, 12:30 am