Convopage
See the entire conversation
32 replies and sub-replies as of Jul 14 2017
conundrum - those reqts require strong education and experience, but formal education unavailable, and the tools/platform aren't there yet
It appears like we're getting there, but even I worry it's not enough, and/or too late
I call BS. How strong was "JS education" when you started? What's required is _valuing the lived user experience_.
This often runs *directly* counter to tech-obsession and purity. UI engineering is harder than backend engineering, full stop, as a result.
UI engineering -- and for the browser, that's "web development" -- requires a fusion of skills; it's like cooking.
It's fine to be a master of the grill station, but if you can't turn out a sauce or plate a dish, you'll never excell.
...and that's where much of the JS community seems to be today: stuck in minutia of grilling, valuing a perfect saute like a finished dish
There were different constraints, you remember. Nobody built anything serious, till chrome arrived, and laptops/pcs became really powerful
As a result, you could get away with more. Mistake is we're taking the same approach with mobile, and failing.
I was there, I was writing JS then; this is revisionist BS.
I'm agreeing with you here, but pointing out that just valuing UX isn't enough, simply by the list of reqts in OP article
Valuing UX is how you get to things like valuing URLs and a11y and all the rest. It's valuing the _totality_ of the experience.
And you know what? It's OK for us to say "UI is hard, don't expect it to be as easy as the backend". It has always been true.
...and it's fine for us to appeal to something bigger than the next fad and keep things in context. History is not the enemy.
The shortcut version for new engineers needs to be "set budgets, learn to live within them". Those budgets need to be representative.
Anyway, happy to dig up some of the history and context next week when I'm back from holiday.
👍🏽was just sharing my own experience. Looking forward.
Sorry if that came across as ranty; didn't mean to unload on you!
it's cool, I understand and empathise where you're coming from. on my mind a lot, but struggle to see the way forward, hence defer to you.
It's important to understand why script is chosen. One big reason is transitioning from one page to another. It's faster in JS.
Once you've chosen to paint a page in JS, now you have to paint ALL pages in JS. Stuck with choice to duplicate work, or only do script.
But, you lose *a lot* of built-in browser things at this point. So you have to reimplement, leading to even more script.
If something like Jake's navigation-transition was implemented, doing in script becomes less desirable.
What Chrome devrel doesn't understand is why people choose script, and assume it's about fashion.
Until you accept that devs are making this choice for non-shallow reasons you'll have the power to provide an alternative.
2 things: I'm not in devrel (it shows!), and I appreciate all those factors.
...and because I appreciate them, I work on long-run solutions (e.g. ES6, WC, SW, etc.).
The flip side is I also see what platform can do and what devs are sending; massive disconnect and it hurts users.
Not to use too broad a brush, but I *frequently* see apps where devs are making these choices from uninformed positions & w/o budgets.
So your point (if not conclusions) stand, but so does mine: we are all multiply-optimizing but many are omitting a constraint (usable perf).
...and if you don't include "it must be usable for real users" in the equation, you explore the wrong parts of solution space
I'm going to steal this metaphor!