Less JavaScript

Every front-end developer at Clearleft went to FFConf last Friday: me, Mark, Graham, Charlotte, and Danielle. We weren’t about to pass up the opportunity to attend a world-class dev conference right here in our home base of Brighton.

The day was unsurprisingly excellent. All the speakers brought their A-game on a wide range of topics. Of course JavaScript was covered, but there was also plenty of mindfood on CSS, accessibility, progressive enhancement, dev tools, creative coding, and even emoji.

Normally FFConf would be a good opportunity to catch up with some Pauls from the Google devrel team, but because of an unfortunate scheduling clash this year, all the Pauls were at Chrome Dev Summit 2016 on the other side of the Atlantic.

I’ve been catching up on the videos from the event. There’s plenty of tech-related stuff: dev tools, web components, and plenty of talk about progressive web apps. But there was also a very, very heavy focus on performance. I don’t just mean performance at the shallow scale of file size and optimisation, but a genuine questioning of the impact of our developer workflows and tools.

In his talk on service workers (what else?), Jake makes the point that not everything needs to be a single page app, echoing Ada’s talk at FFConf.

He makes the point that if you really want fast rendering, nothing on the client side quite beats a server render.

They’ve written a lot of JavaScript to make this quite slow.

Unfortunately, all too often, I hear people say that a progressive web app must be a single page app. And I am not so sure. You might not need a single page app. A single page app can end up being a lot of work and slower. There’s a lot of cargo-culting around single page apps.

Alex followed up his barnstorming talk from the Polymer Summit with some more uncomfortable truths about how mobile phones work.

Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.

And JavaScript frameworks aren’t helping. Quite the opposite.

But make no mistake: if you’re using one of today’s more popular JavaScript frameworks in the most naive way, you are failing by default. There is no sugarcoating this.

Today’s frameworks are mostly a sign of ignorance, or privilege, or both. The good news is that we can fix the ignorance.

Have you published a response to this? :

Responses

Tom Tinkerson

yeah, like convenience foot is good for health b/c ppl can’t (afford to) cook ;-)

patrick h. lauke

there’s developers who should know better but instead follow fashion, and those who are not expert enough to even decide

patrick h. lauke

how do you evaluate something without knowing what it is you’re trying to evaluate? not possible for many non-experts…

patrick h. lauke

non-experts will often just look at “this is popular, used by these big companies/projects, so must be good”

2 Shares

# Shared by Gabor Lenard on Thursday, November 17th, 2016 at 3:38pm

# Shared by Sam Wainford on Thursday, November 17th, 2016 at 9:43pm

2 Likes

# Liked by Gabor Lenard on Thursday, November 17th, 2016 at 3:49pm

# Liked by tedepstein on Saturday, November 19th, 2016 at 1:45pm

Related posts

Streamlining HTML web components

Some handy tips courtesy of Chris Ferdinandi.

Responsibility

Fear of a third-party planet.

My approach to HTML web components

Naming custom elements, naming attributes, the single responsibility principle, and communicating across components.

Displaying HTML web components

You might want to use `display: contents` …maybe.

Pickin’ dates

HTML web components for augmenting date inputs.

Related links

Write Code That Runs in the Browser, or Write Code the Browser Runs - Jim Nielsen’s Blog

So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”

Tagged with

React Won by Default – And It’s Killing Frontend Innovation | Loren Stewart

React is no longer winning by technical merit. Today it is winning by default. That default is now slowing innovation across the frontend ecosystem.

Tagged with

Why Silicon Valley CTOs Are Secretly Moving Away from React | by Coders Stop | in JavaScript in Plain English - Freedium

“We’ve stripped React out of our highest-traffic user flows and replaced it with vanilla JavaScript using small, focused libraries for specific needs,” said the CTO of a streaming service. “Our page load times dropped by 60% and our conversion rates improved by 14%.”

Tagged with

Close to the metal: web design and the browser

It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree

Tagged with

Hiding elements that require JavaScript without JavaScript :: dade

This is clever: putting CSS inside a noscript element to hide anything that requires JavaScript.

Tagged with

Previously on this day

10 years ago I wrote Brighton device lab

You should come by the Clearleft office and test your website on many many devices.

19 years ago I wrote Spoken

I delivered my spiel on microformats.

21 years ago I wrote Client communication

There’s a great interview with John Allsopp over at the Web Standards Group. John is the author of one of my all-time favourite articles over at A List Apart: Dao of Web Design.

22 years ago I wrote Sprint CSS

I got a nice email today from a very talented web developer named France Rupert telling me about the newly redesigned Sprint PCS site.

23 years ago I wrote Bringing Entertainment Home

After a long week of staring at code, I finally had some time this weekend to sit back and enjoy my new computer.

24 years ago I wrote The ugly world of PCs

Jessica and I got plenty of exercise today. We walked to the far end of town to look at the wares at PCworld.