I know how to do full-stack development, not because I wanted to but because I had to.
Grim, but true. I know quite a few extremely talented front-end developers who have been forced out of the field because of what’s described here.
There is no choice anymore, I can’t escape it. React is so pervasive that almost every job is using it. On the rare occasion that they’re not using it, they’re using something like it.
This is handy—a collection of font stacks using system fonts. You can see which ones are currently installed on your machine too.
The most performant web font is no web font.
Dave laments the increasing number of complex jobs involved in front-end (or “full-stack”) development.
But whereas I would just leave at that, Dave does something constructive and points to a potential solution—a corresponding increase of more thinsliced full-time roles like design engineering, front-end ops, and CSS engineering.
It me:
Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.
This rings sadly true to me:
Suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn’t need a framework — it’s one SELECT query, that’s it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn’t too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn’t have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.
Also, I never thought about “serverless” like this:
Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.
This is a terrific and nuanced talk that packs a lot into less than twenty minutes.
I heartily concur with Rich’s assessment that most websites aren’t apps or documents but something in between. It’s a continuum. And I really like Rich’s proposed approach: transitional web apps.
(The secret sauce in transitional web apps is progressive enhancement.)
Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:
- use custom elements (for modular HTML without frameworks)
- use the in-browser package manager (for JavaScript packages without build tools)
- match pages with files (to avoid routing and simplify architecture)
- stick to standards (to avoid obsolescence and framework fatigue)
Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!
Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.
I have a special disdain for beginner JavaScript tutorials that have you run
create-react-appas the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.
Katie shared this (very good) piece about service design on Slack at work today, and when I got to the bit about different levels, my brain immediately went “pace layers!”
- The Service
- The Infrastructure
- The Organisation
- The Intent
- The Culture
This is a superb twenty minute presentation by Trys! It’s got everything: a great narrative, technical know-how, and a slick presentation style.
Conference organisers: you should get Trys to speak at your event!
Trys describes the backend architecture of the excellent Sofa Conf website. In short, it’s a Jamstack dream: all of the convenience and familiarity of using a database-driven CMS (Craft), combined with all the speed and resilience of using a static site generator (Eleventy).
I love the fact that anyone on the Clearleft events team can push to production with a Slack message.
I also love that the site is Lighthousetastically fast.
Trys writes up the process—and the tech (JAM)stack—he used to build basil.christmas.
How cool is this!!?
Tom took one of the core ideas from my talk at Beyond Tellerrand and turned it into this animated CodePen!
A terrific—and fun!—talk from Zach about site deaths, owning your own content, and the indie web.
Oh, and he really did create MySpaceBook for the talk.
Chris broke both his arms just to avoid speaking at the JAMstack conference in London. Seems a bit extreme to me.
Anyway, to make up for not being there, he made a website of his talk. It’s good stuff, tackling the split.
It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry
Chris makes the very good point that the J in JAMstack isn’t nearly as important as the static hosting part.
I also pointed out to Phil recently that the M (markup) is far more important than the J (JavaScript), which is there to enhance the M. So I suggested that the acronym be updated accordingly:
MAJstack!
This is my maj.
This is very handy! Export your data from Ev’s blog and then import it into a static site generator of your choice.
You may have noticed the recent movement of people looking to get off Medium. Most of us are motivated by a desire to own our content, have data portability and get more control over how/where our content is displayed and monetized. Most importantly many of us consider our blog/site to be a core part of our online identity and while Medium offers a fantastic writing experience it sacrifices other important values. Luckily there’s a modern approach to running your blog which aligns with these ideals, its called the JAMstack and its all around us.
I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills.
A nice counterpoint to the last time I linked to Paul’s weeknotes:
However, there’s another portion of the industry, primarily but not exclusively within the public sector, where traditional development approaches (progressive enhancement, server-side rendering) remain prevalent, or less likely to be dismissed, at least. Because accessibility isn’t optional when your audience is everyone, these organisations tend to attract those with a pragmatic outlook who like to work more diligently and deliberately.
So far I’ve been drawn towards developer-orientated roles; working with HTML, CSS and JavaScript (in that order) to implement designs and ensure products are accessible and performant. However, it seems such work no longer exists. People talk about full-stack development, but nearly every job I’ve seen containing the words ‘front-end’ has React as a requirement. The gatekeeping is real.
Frustrating on a personal level, but also infuriating when you consider how such gatekeeping is limiting welcome attempts to diversify our industry.
Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.
Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”
The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.
Absolutely spot on! And it cuts both ways:
Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.
