Hard to put into words how utterly broken JS-first web development is. So many parts of the system work against you when you take the reins.
67 replies and sub-replies as of Nov 02 2016

i think the takeaway here is not to use a framework as is. Instead of JS first, we focus on progressive enhancement first
and add mobile-first & offline-first to enchance experience. Only use minimal JS as possible to enhance UX
I'm interested in the constraints more than the mechanisms. If folks tested on real hardware more, even JS-only could work well
yeah that's why im investing more on working on perf and using only minimal JS. Would it be better to call #minimalJS? :p
I like the "can you afford this?" framing. It applies to everything: CSS, Fonts, Images, etc. The budget is important.
i like that idea. It should be put in the dev work along with perf and ux.
what is "JS-first web development"?
I think app that sends an empty div and requires JavaScript to load elements
many gradations here. I sort of look at this by "how many default optimisations are you defeating & need to rebuild?"
it's a little tricky because you'd need to construct the theoretical #UseThePlatform clone to check.
My company's R&D team develops on MacBooks with no firewalls. I implement their software in banks. Write protected terminals and firewalls.
also JS-first is assumptive. “Please download this huge file (that won’t work)” rather than feature detect + load if passes
This is how we wind up with SPAs that download 2MB of JS just to present incapable browsers with a blank white screen of death 🏳
More developers need to start asking themselves "am I better served by using a framework or by the browser's innate behavior?"
And yet, many JS dev teams are happy and their products quite good. Perhaps only broken along less important dimensions?
I encounter many teams with this view. Then I plug in a ~$200 phone to chrome:inspect and take a trace; often shows otherwise
Most devs won't use stale code patterns to support low end phones that will go away in a year or two. Browsers will adapt.
users do not care about code patterns. Developer Experience should never come before User Experience.
Users want nice web apps, not 90s style "pages" that take 4x the cost to develop, test, and maintain.
I agree users want better experiences! Only discussion point is how to deliver them.
irony is that for a lot of web experiences today '90s style pages' is much more performant.
If the 1 metric is load time, yes. If the metrics are giving users superpowers with tech, no. (my original point)
"superpowers worth waiting for"? ;-)
It seems we agree on user centered design and empowerment and also disagree on the net win of JS-centric patterns.
Perhaps we also agree that abuse of frameworks is problematic and movement to vanilla JS is often a clear win?
Also, we might agree that service workers can help create friendly offline or sporadic connection situations?
That said, populating and manipulating the DOM with anything except JS (native or as a compile target) is doomed.
like most things on the web this isn't binary, I'm with you on these things but only when there is a user need.
yep, of course. Didn't spend years of my life on SWs/PWAs as a lark = )
I've been a part of offline-first around @pouchdb etc for a while now before SW.
JS centric solutions are important to solve some problems, but to say today developers understand how to balance
A tricky balance to be sure, especially for smaller dev teams.
not sure what you mean by superpowers, people want to get shit done not wait for a battlesuit to download
"Give your users superpowers" is a Kathy Sierra phrase about user centered design. Worth a read.
Let's start with parsers. Browsers are clever; they use threaded parsing and compilation for both script and other resource types (e.g. CSS)
but what if I want to with replace my CSS with a Cassowary Constraint Solver for layout? 😛
in serious, I hope people start recognizing how modern the new baseline is for dev and delivery and we see a renaissance.
it's one of the great things with going out and talking about PWA- people realize that the 2016 web is so much more capable.
Those parsers look for resources to fetch (pre-parsing and scanning). When you bake that into script, you defeat that whole system.
...which means the latency to begin fetching those resources is now much higher in the common case. Of course, you can work around (kinda)
A bigger toolchain, <link rel="prefetch">, H/2 push, etc. You can get some of it back, but not entirely.
But it's not just parsers! When you bake, e.g., CSS & templates into script, those things live in the heap. We can't drop them (usually).
Is baking CSS + templates into script fundamental? Don't these tools let you code split them separate, rather than bundle all?
I assume frameworks can figure out ways not to do this (and that will be a great day!)
Hm - React is agnostic about this. I believe (afaik) Webpack will let you do either.
#twoosh 🎊 Twitter website: You will never find a more wretched hive of scum and villainy. 🏜👴🌌🌑
Is baking CSS + templates into script fundamental? Don't these tools let you code split them separate, rather than bundle all?
So memory footprint goes up. The code that's generated is only a part of it; the source code stays around in most impls today -- often large
please fix :) I’d like to say: I don’t care what fn.toString() does. Please release what you can.
with V8 eventual new compiler toolchain, that should save a lot of RAM. PS: Not arguing with the wider point, of course :)
I hear future work may allow swapping source strings out of the heap; very excited about that, but not here yet.
The larger issue, of course, is script eval is single-threaded. We can't construct (e.g.) DOM off-thread. And script ~10x slower on phones.
Not all phones, mind. Developers with ~$700 iPhones & Pixels are living in a different world to most folks.
The most obvious impact is interactivity blocked on script eval. We can't load/run main-thread JS w/o halting input processing.
But what I'm seeing in traces is how script-based abstraction & dependence is dragging folks away from the impacts of these choices.
Old news that webdevs who don't know DOM instinctively pull in libs when not needed. We've tech'd up from there:
Just traced a site that included an ad. The ad included a full copy of a popular framework, to the tune of 150K (~50K gzipped). "Creative".
So when you see folks saying #usetheplatform, this is what we're talking about. We're not succeeding on mobile w/ current approaches.
Could go on-and-on about the script-first thing: resource fetch priorities, browser scheduling and idle-time control, input processing, etc.
The most important thing to keep in mind is that when you put your app in script, you are now entirely responsible. Browser can't help you.
Maybe you want/need that control. Congrats, you have it! But keep in mind what you're giving up and will need to work to rebuild.
developers routinely make implicit decisions without having a clue that they've done so, or what the tradeoffs were 😕
I found it not as hard as perceived to move 'server concerns' to browser several years ago. PWA make my architecture native :)
unrelated, but pixel web scores are 1/3 iPhone 7's. Is this purely hardware or is software playing a significant role too?
a bit of both; depends on benchmark, but the HW differences are huge. Straight-line, singled threaded perf stresses caches.
something important here: iPhones have HUGE L2/3 caches (historically). Can't buy an equivalent Qualcomm part today.
That's very interesting to know. Thank you for such a detailed answer!
I have massive respect for Apple's HW. Amazing screens/digitizers, great thermal balance. This is an example of perf balance.
predicting in 2017: web devs rediscovering the platform be like