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.

Let's start with parsers. Browsers are clever; they use threaded parsing and compilation for both script and other resource types (e.g. CSS)

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

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

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:

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.

I found it not as hard as perceived to move 'server concerns' to browser several years ago. PWA make my architecture native :)

developers routinely make implicit decisions without having a clue that they've done so, or what the tradeoffs were 😕

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.

I have massive respect for Apple's HW. Amazing screens/digitizers, great thermal balance. This is an example of perf balance.

That's very interesting to know. Thank you for such a detailed answer!

predicting in 2017: web devs rediscovering the platform be like

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.

Is baking CSS + templates into script fundamental? Don't these tools let you code split them separate, rather than bundle all?

#twoosh 🎊 Twitter website: You will never find a more wretched hive of scum and villainy. 🏜👴🌌🌑

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.

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.

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"? ;-)

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.

It seems we agree on user centered design and empowerment and also disagree on the net win of JS-centric patterns.

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.

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?

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.

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.

More developers need to start asking themselves "am I better served by using a framework or by the browser's innate behavior?"

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 🏳

My company's R&D team develops on MacBooks with no firewalls. I implement their software in banks. Write protected terminals and firewalls.

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.

i think the takeaway here is not to use a framework as is. Instead of JS first, we focus on progressive enhancement first

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.

and add mobile-first & offline-first to enchance experience. Only use minimal JS as possible to enhance UX