Frameworks (arguably) make building complex applications easier, but they make doing simple stuff more complex.
And that’s why I think people should learn vanilla JS first. I’ve had many students who tried to learn frameworks get frustated, quit, and focus on vanilla JS.
Some of them have gone back to frameworks later, and told me that knowing vanilla JS made it a lot easier for them to pick up frameworks afterwards.
Monday, April 8th, 2019
Friday, April 5th, 2019
This is a bit ranty but it resonates with what I’ve been noticing lately:
I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.
Wednesday, March 13th, 2019
Saturday, March 9th, 2019
This is such a great excercise for teaching the separation of structure and presentation—I could imagine using something like this at Codebar.
Thursday, March 7th, 2019
Going Offline—the talk of the book
I gave a new talk at An Event Apart in Seattle yesterday morning. The talk was called Going Offline, which the eagle-eyed amongst you will recognise as the title of my most recent book, all about service workers.
I was quite nervous about this talk. It’s very different from my usual fare. Usually I have some big sweeping arc of history, and lots of pretentious ideas joined together into some kind of narrative arc. But this talk needed to be more straightforward and practical. I wasn’t sure how well I would manage that brief.
I knew from pretty early on that I was going to show—and explain—some code examples. Those were the parts I sweated over the most. I knew I’d be presenting to a mixed audience of designers, developers, and other web professionals. I couldn’t assume too much existing knowledge. At the same time, I didn’t want to teach anyone to such eggs.
In the end, there was an overarching meta-theme to talk, which was this: logic is more important than code. In other words, figuring out what you’re trying to accomplish (and describing it clearly) is more important than typing curly braces and semi-colons. Programming is an act of translation. Before you can translate something, you need to be able to articulate it clearly in your own language first. By emphasising that point, I hoped to make the code less overwhelming to people unfamilar with it.
I had tested the talk with some of my Clearleft colleagues, and they gave me great feedback. But I never know until I’ve actually given a talk in front of a real conference audience whether the talk is any good or not. Now that I’ve given the talk, and received more feedback, I think I can confidentally say that it’s pretty damn good.
My goal was to explain some fairly gnarly concepts—let’s face it: service workers are downright weird, and not the easiest thing to get your head around—and to leave the audience with two feelings:
- This is exciting, and
- This is something I can do today.
I deliberately left time for questions, bribing people with free copies of my book. I got some great questions, and I may incorporate some of them into future versions of this talk (conference organisers, if this sounds like the kind of talk you’d like at your event, please get in touch). Some of the points brought up in the questions were:
- Is there some kind of wizard for creating a typical service worker script for any site? I didn’t have a direct answer to this, but I have attempted to make a minimal viable service worker that could be used for just about any site. Mostly I encouraged the questioner to roll their sleeves up and try writing a bespoke script. I also mentioned the Workbox library, but I gave my opinion that if you’re going to spend the time to learn the library, you may as well spend the time to learn the underlying language.
- What are some state-of-the-art progressive web apps for offline user experiences? Ooh, this one kind of stumped me. I mean, the obvious poster children for progressive webs apps are things like Twitter, Instagram, and Pinterest. They’re all great but the offline experience is somewhat limited. To be honest, I think there’s more potential for great offline experiences by publishers. I especially love the pattern on personal sites like Una’s and Sara’s where people can choose to save articles offline to read later—like a bespoke Instapaper or Pocket. I’d love so see that pattern adopted by some big publications. I particularly like that gives so much more control directly to the end user. Instead of trying to guess what kind of offline experience they want, we give them the tools to craft their own.
- Do caches get cleaned up automatically? Great question! And the answer is mostly no—although browsers do have their own heuristics about how much space you get to play with. There’s a whole chapter in my book about being a good citizen and cleaning up your caches, but I didn’t include that in the talk because it isn’t exactly exciting: “Hey everyone! Now we’re going to do some housekeeping—yay!”
- What kind of things are in the future for service workers? Excellent question! If you think about it, a service worker is kind of a conduit that gives you access to different APIs: the Cache API and the Fetch API being the main ones now. A service worker is like an airport and the APIs are like the airlines. There are other APIs that you can access through service workers. Notifications are available now on desktop and on Android, and they’ll be coming to iOS soon. Background Sync is another powerful API accessed through service workers that will get more and more browser support over time. The great thing is that you can start using these APIs today even if they aren’t universally supported. Then, over time, more and more of your users will benefit from those enhancements.
If you attended the talk and want to learn more about about service workers, there’s my book (obvs), but I’ve also written lots of blog posts about service workers and I’ve linked to lots of resources too.
Finally, here’s a list of links to all the books, sites, and articles I referenced in my talk…
- Resilient Web Design
- The Prime Number Shitting Bear
- The Session
- Una Kravets
- Sara Soueidan
- dConstruct Archive
Progressive Web Apps
- What the heck is a “Progressive Web App”? Seriously. by Ben Halpern
- Building Progressive Web Apps by Diogo Cunha
- Before You Build a PWA You Need a SPA by Mark Muskardin
- Tweet by Jake Archibald
- What is a PWA by Salva de la Puente
- Naming Progressive Web Apps by Frances Berriman
- Progressive Web App Checklist by Google
This is such excellent advice for anyone starting out in front-end development:
- Get comfortable with the naked internet (sorry, not THAT naked internet)
- Build yourself some nice little one-column websites
- Learn about layout
- Make it work on phones
- Make it dynamic
(I would just love it if Meagan were posting this on her own incredibly beautiful website rather than on Ev’s blog.)
Tuesday, February 19th, 2019
CSS Grid is easy to use but difficult to learn. It’s a more intuitive paradigm than any other CSS layout technique, but it’s completely different from its predecessors.
Some great advice here on how to approach CSS grid:
- Use names, not numbers
- Use fr as your flexible unit
- Don’t use a grid system
Friday, February 1st, 2019
Here’s a thorough blow-by-blow account of the workshop I ran in Nottingham last week:
Jeremy’s workshop was a fascinating insight into resilience and how to approach a web project with ubiquity and consistency in mind from both a design and development point of view.
I saw Daniel give a talk at Async where he compared linguistic rules with code style:
We find the prescriptive rules hard to follow, irrespective of how complex they are, because they are invented, arbitrary, and often go against our intuition. The descriptive rules, on the other hand, are easy to follow because they are instinctive. We learned to follow them as children by listening to, analysing and mimicking speech, armed with an inbuilt concept of the basic building blocks of grammar. We follow them subconsciously, often without even knowing the rules exists.
Thus began some thorough research into trying to uncover a universal grammar for readable code:
I am excited by the possibility of discovering descriptive readability rules, and last autumn I started an online experiment to try and find some. My experiment on howreadable.com compared various coding patterns against each other in an attempt to objectively measure their readability. I haven’t found any strong candidates for prescriptive rules so far, but the results are promising and suggest a potential way forward.
I highly recommend reading through this and watching the video of the Async talk (and conference organisers; get Daniel on your line-up!).
Thursday, January 31st, 2019
When we talk about HTML and CSS these discussions impact the entry point into this profession. Whether front or backend, many of us without a computer science background are here because of the ease of starting to write HTML and CSS. The magic of seeing our code do stuff on a real live webpage! We have already lost many of the entry points that we had. We don’t have the forums of parents teaching each other HTML and CSS, in order to make a family album. Those people now use Facebook, or perhaps run a blog on wordpress.com or SquareSpace with a standard template. We don’t have people customising their MySpace profile, or learning HTML via Neopets. We don’t have the people, usually women, entering the industry because they needed to learn HTML during that period when an organisation’s website was deemed part of the duties of the administrator.
I agree with every single word Rachel has written.
I care not a whit what tools or frameworks, or languages you use to build something on the web. But I really care deeply when particular tools, frameworks, or languages become mandatory for even getting a foot in the door.
This is for everyone.
I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged. I have plenty of fight left in me to stand up against that.
Sunday, January 27th, 2019
Westley came along to my workshop at New Adventures …and liked it! (phew!)
I have long been a proponent of progressive enhancement on the web, perhaps before I knew the true value of it to the people that use the things we build for the web, but Jeremy has always been able to expand my understanding of its importance in the wider scope of things, how it inherently builds resilience into your products, and how it makes it more widely available to people across the world, in vastly different scenarios. The workshop itself was fluid enough to cater to the topics that the attendees were interested in; from over-arching philosophy to technical detail around service workers and new APIs. It has helped me to understand that learning in this kind of environment doesn’t have to be rigorously structured, and can be shaped as the day progresses.
Read on to discover how I incorporated time travel into the day’s activities.
Saturday, January 19th, 2019
Sunday, January 13th, 2019
One facet of this whole CSS debate involves one side saying, “Just learn CSS” and the other side responding, “That’s what I’ve been trying to do!”
I think it’s high time we the teachers of CSS start discussing how exactly we can teach a correct mental model. How do we, in specific and practical ways, help developers get past this point of frustration. Because we have not figured out how to properly teach a mental model of CSS.
Tuesday, December 18th, 2018
It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:
- Programming languages are different, but design smells are alike.
- Frameworks are different, but the same design patterns shine through.
- Developers are different, but rules of dealing with people are uniform.
Sunday, December 16th, 2018
A personal history of personal publishing from Ana—it’s wonderful!
When I was feeling low and alone I would recall how happy I used to be before I was working in tech. I would remember my silly fan sites, my experiments, my blogs and everything that I loved so much that made me become a developer.
Thursday, December 13th, 2018
This is the real challenge for service workers:
For 30 years, we taught billions of humans that you need to be connected to the internet to consume the web via a browser! This means web users need to unlearn that web sites can’t be used offline.
Sunday, December 9th, 2018
Blogging about what you are working on is is really valuable for the writer because it forces you to think logically about what you are doing in order to tell a good story.
It’s also really valuable to blog about what you’ve learned, especially if you’ve made a mistake. It makes sure you’ve learned the lesson and helps others avoid making the same mistakes.
Friday, December 7th, 2018
Cassie and I went to a great Async talk last night all about code readability, which was well-timed because it’s been on our minds all week. Cassie explains more in this post.
Saturday, November 17th, 2018
Tuesday, November 13th, 2018
Optimise without a face
I’ve been playing around with the newly-released Squoosh, the spiritual successor to Jake’s SVGOMG. You can drag images into the browser window, and eyeball the changes that any optimisations might make.
On a project that Cassie is working on, it worked really well for optimising some JPEGs. But there were a few images that would require a bit more fine-grained control of the optimisations. Specifically, pictures with human faces in them.
I’ve written about this before. If there’s a human face in image, I open that image in a graphics editing tool like Photoshop, select everything but the face, and add a bit of blur. Because humans are hard-wired to focus on faces, we’ll notice any jaggy artifacts on a face, but we’re far less likely to notice jagginess in background imagery: walls, materials, clothing, etc.
On the face of it (hah!), a browser-based tool like Squoosh wouldn’t be able to optimise for faces, but then Cassie pointed out something really interesting…
- Drag or upload an image into the browser window,
- A facial recognition algorithm finds any faces in the image,
- Those portions of the image remain crisp,
- The rest of the image gets a slight blur,
- Download the optimised image.
Maybe the selecting/blurring part would need canvas? I don’t know.
Anyway, I thought this was a brilliant bit of synthesis from Cassie, and now I’ve got two questions:
- Does this exist yet? And, if not,
- Does anyone want to try building it?