I found out about accessibility in college, eight or nine years ago, and loved it so much it became my thesis. From then on, I was often the only person in the room excited enough to talk about it – I persisted, advocated, learned more, and fought to raise awareness.

Rarely did anyone listen, it wasn’t important. Until last year.

When the European Accessibility Act became law, suddenly everyone wanted to talk about accessibility. I was in meetings, resources were finally allocated, and the thing I’d been shouting about for nearly a decade was at last… important.

I should have been thrilled. Instead, I felt nothing.

Anyone, anywhere, should be able to use the web

Tim Berners-Lee said:

The power of the Web is in its universality.

I believed it in college, and I still believe it today: the web should be accessible to everyone. That’s the foundational principle behind the platform we build every day.

But for most of my career, that principle wasn’t even on the radar. I watched us build walls in a medium meant to have none and I kept speaking up anyway, because someone had to.

I‘d won the battle and lost the war

Then 2025 arrived – the European Accessibility Act. Accessibility wasn’t optional anymore, it was a legal requirement. And suddenly, people listened.

Finally, I was having real conversations about accessibility – the thing I’d wanted for eight years. But it wasn’t because most people truly cared, they were asking only because they had to.

For the most part, few conversations focused on the 15% of users who experience the web differently. Most discussions were about checkboxes, compliance audits, and legal exposure, rather than creating experiences that work for everyone.

I’d won the battle and lost the war: accessibility was happening, but the why (the empathy, the principle, the universality of the web) was missing.

Let’s fix something that isn’t broken

You know what’s funny? Everything was fine for a while.

Native HTML elements come with accessibility built in. A <select> is usable by default, and a <button> handles keyboard interaction automatically – HTML was designed with accessibility in mind. The challenge comes when we want to style them: for example, dropdowns are notoriously hard to customize, so they often end up looking like the browser’s default, which can feel “ugly” compared to the rest of our design.

So we built custom ones and this where we start to lose accessibility. We didn’t mean to, we just wanted things to look better. But in chasing the shiny new, we broke what worked.

I guess it got to the point where enough people with disabilities were heard, and finally someone started to care. And now here we are, trying to fix what we broke with our shiny new toys. I’m glad we’re here. If we can, we should take everyone into consideration. It’s also good for business or something—I don’t know, I’m just a developer

But here’s what I do know: ship fast, yes, but don’t skimp on quality. Every commit carries your name, and that matters.

Accessibility automated – no brain cells required

So here I am: building accessible components, creating tools to automate accessibility, and teaching AI to check WCAG compliance. The idea: make accessibility so easy developers don’t have to think about it. Use our Bepo components – get compliance for free, ship accessible products, no explanations required.

After eight years of trying to get people to care, I’m now building systems so they don’t have to. The irony isn’t lost on me.

We’ve built Navigation with a ton of keyboard interactions developers never had to write. Broadcast with ARIA patterns they never had to learn. Color contrast decisions made at the token level. Focus management handled automatically. Claude Code plugin that catches accessibility issues in code review.

It works. Users benefit. Rarely anyone understands why. And that haunted me.

And still, I couldn’t sleep at night

I wrestled with it for months. Had I traded education for efficiency? Made accessibility just a checklist, a tool, not a principle? Where was the empathy in automation?

We’re not just building components, we’re building experiences. Real experiences for real people: those who navigate with keyboards, rely on screen readers, need high contrast, struggle with complex interactions, or depend on assistive technologies.

How do you automate caring about those people?

I thought I understood select… until I actually built one

Until recently, I didn’t really understand the difference between Select and Combobox. I thought I did, I could cite the ARIA spec, but I didn’t. I’d accepted what authorities said without questioning it. In our design system, they were just one Select component… like in many UI libraries. So I never questioned it.

There’s really no difference in what a screen reader announces – Select and Combobox have the same role. I guess Select came first and ARIA later, so the role applies to both. So having just one component… almost the same, right?

Except if you care about the structure of these elements, what it means, and why you can’t fully follow the pattern with just one component. That’s the tricky part

I didn’t really know about the Combobox, until frustration made me curious.

I dove into building a “vanilla” Select from scratch – ARIA patterns, screen reader testing, understanding user expectations, the whole thing. And I realized: modern components don’t really follow patterns. Some tools are technically correct, but they feel… wrong. Clunky. Not what users expect.

Bridging UX gaps is about making interfaces seamless, accessible, and human-first

This is the UX gap. We want custom, modern, polished, and accessible but there’s a bridge missing between the spec and good UX.

I realized: we can have almost all of it if we build with the experience in mind. Combine patterns. Use micro knowledge (like tabbing to inputs or arrowing through options) to make the Select feel as clear as native. Screen reader and keyboard should just make sense.

Average users don’t know about triggers. They just want to open the Select and pick an option. Keep it simple.

As a frontend developer, I see myself as a bridge between users and what I build. It’s my responsibility to make interfaces the best they can be, and to care about them.

You know what I had the most fun with while building my Select? Focus and keyboard interactions. It’s seamless, it works beautifully, exactly as I expect.

I see it in chunks: arrows navigate options, tab moves to buttons, links, inputs. But here’s the twist: if a Select has a custom footer with action buttons, arrows should still navigate options. The footer isn’t part of the pattern; it’s our addition. That’s where we bridge the gap. Or, as the Brits say: mind the gap.

This is the space for custom solutions, where language standards and patterns meet usability, inclusivity, and the full interaction experience.

Building that Select taught me the difference between patterns, user expectations, and implementation flexibility. It was so much fun.

I’ve always loved HTML and CSS – the right semantic element, the right ARIA role, perfect keyboard navigation. It’s craftsmanship. Most users won’t notice, they’ll just use the Select. That’s the point: good infrastructure and accessibility are invisible. You only notice when it’s missing.

We need the knowledge, the understanding, the empathy. UX gaps can’t be automated. Someone has to know what they’re building and who they’re building it for. That’s deep work. And it matters.

The accessibility reconciliation that gave me peace

Then I realized something:

I don’t need everyone to care the way I care, I need everyone to build accessible products. Those aren’t the same thing. And pretending they are was making me miserable.

Here’s the mental model that gave me peace:

Tier 1: The Foundation

• Use accessible components correctly
• Trust the automation
• Get accessibility “for free”
• Ship accessible products without deep expertise

This is how we scale accessibility: give people the right tools and let them use them.

Tier 2: The Curious

• Understand the patterns and why they work 
• Can compose components accessibly
• Catch edge cases automation misses
• Teach others

This is where cultural change happens: people see when automation isn’t enough, ask why, learn deeper patterns, and build better products for their users.

Tier 3: The Champions

• Deep expertise
• Build the infrastructure
• Advance the field
• Fight the eight-year battles

This is where I live, building the tools that make Tier 1 possible.

For eight years, I tried to push everyone to Tier 3, make everyone care as much as I did. I failed. I was exhausted. And I’ve realized I can’t make everyone care, but I can build the infrastructure, play the long game, and ship accessible products anyway. Maybe some will get curious, maybe they won’t, but by making accessibility the default, we create space for learning and a future where it’s just how things work.

Automation doesn’t give up; it accepts that people engage differently.

The door is always open: use components (Tier 1), get curious (Tier 2), contribute patterns (Tier 3). Or stay at Tier 1. That’s fine. That’s success. That’s an accessible product shipped.

You don’t need everyone to care, but everyone can benefit from what you build

If you build accessibility infrastructure, your work matters, even when it’s invisible. Build the safety net, automate what you can, and leave the door open for those who want to see how it works.

If you’re a developer: Tier 1 is enough: use the accessible components, trust the tooling, ship accessible products. Tier 2 is there if you’re curious: learn the patterns, understand your users, make better products. Tier 3 is there if you’re passionate: join us. We’ve been out here a while; it’s lonely sometimes, and we’d love the company.

After eight years in the wilderness, I’m finally building the tools – tools that make accessibility easy, scale empathy, and create experiences for everyone. That’s the infrastructure that matters. And that’s enough.

The post You don’t need to care, just make your products accessible appeared first on ShiftMag.

Our tool addresses the gap between design and development by creating tools that cater to both, ensuring a smoother transition from design to production.

After spending the previous years of his career working for Aptana, RivalSoft Inc., and Asana, Rasmussen got the position of VP of Engineering at Figma, and five years later, he became the CTO. He started working with Figma in 2016, a month before its public launch. He was intrigued by its unique approach, combining graphics, real-time systems, and reactive programming. 

Although it wasn’t initially committed to being entirely web-based, it chose to because of its potential for performance and consistency. 

Design means nothing if you don’t ship it

Kris acknowledged the challenges of real-time collaboration and feedback, emphasizing the importance of balancing exploration with execution. Internally, Figma uses milestones and designated responsible individuals (DRI-s) to manage projects and ensure progress. 

Product design doesn’t mean anything if you don’t actually ship the things you design, and you really need to build a new product design tool for a new type of product team.

He added that developers didn’t always want to navigate this big and messy TV canvas that a designer might brainstorm to find the specific version of the design that the designer wants or one of them to look at.

AI removing roadblocks

Rasmussen mentioned Figma’s AI efforts to automate tedious tasks, expediting designers’ and developers’ work. Popular features include automating mock-to-prototype transitions and renaming layers for better code structure:

We’ve been working on our AI release over the last year and just want to configure user confidence. Our focus for this initial release and our strategy on AI generally is to expedite many of the roadblocks designers and developers face every single day.

He said that instead of being focused on really dramatic ways AI will change the world, we should not underestimate the fact that AI is making many previously tedious and slow things much faster and more possible.

The post Figma’s CTO: Design means nothing if you don’t ship it appeared first on ShiftMag.

JAMstack is almost 10 years old. For developers today, it’s just a natural way they’ve learned to build websites.

But it wasn’t always like that. Biilman coined the term in 2015. to be able to easily refer to the architectural approach of decoupling the app logic from the backend and infrastructure.

“JAMstack allowed new developers to learn web technology and build websites really quickly without having to dive into a lot of backend and infrastructure code,” says Matt.

This video is a part of ShiftMag’s video series, Engineer Explains.

We’ve asked experienced engineers to share how they would explain some basic and some less basic tech terminology to different tech job titles or at three levels of experience — from junior developer to CTO.

More:
How would you explain APIs, internal developer platforms, software architecture, software testing, scaling infrastructure without breaking the bank,  low-code as a dev tool, what is a database, Network APIs or Developer Relations at three levels of experience?

The post Engineer Explains: What is JAMstack? Matt Biilmann breaks it down for us appeared first on ShiftMag.

They come and go, change faster than you can imagine, and each new release promises a revolution in how we create layout. If you are starting with web development, this can be overwhelming and off-putting, also it can lead you in the wrong direction. 

Let’s uncover the pros and cons of front-end frameworks dynamism, highlight the potential pitfalls of blindly following the latest trends without a solid foundation, and provide guidance on mastering any front-end framework. 

The Pros and Cons of a variety of choices

One of the biggest drawbacks, and at the same time the advantage, is an overwhelming variety of choices. In the ocean of front-end frameworks, it is challenging to make the correct selection, and a wrong choice can potentially delay project progress. Moreover, the variety of choices can overwhelm you with a constant need to learn new frameworks, potentially leading to burnout as you strive to keep up.  

However, this vast array of choices  allows developers to select a framework that aligns with their project specifications, potentially leading to improved performance, scalability, and more.  

Another positive aspect that emerges from dynamic development is innovation and evolution.  

New versions and updates often bring innovative features and improvements in performance, security, and user experience. Also, innovation often produces productivity boost. It brings features like hot reloading, component-based architecture, and more.  

That can also have a downside in some cases, such as deprecation of older features or APIs, which require developers to adapt and update their codebase to stay compatible with the latest advancements.  

How I prioritized frameworks over fundamentals

When I first ventured into frontend development four and a half years ago, my knowledge of HTML, CSS, and JavaScript was quite limited. Like many beginners, I was eager to jump into building impressive applications. So, as you might have guessed, I went on YouTube and found some videos that show how impressive frameworks are. That is the moment when a crucial mistake was made, I prioritized framework over fundamentals, but I did not realize it at the time. 

In the beginning, the development was quite rapid, even though I had no idea what exactly was happening and how the web or that framework functioned. A few months later, I began researching other frameworks because I was influenced by fellow frontend developers who consistently endorsed them. At that time, I was a self-taught developer with no working experience, and I found myself caught in the never-ending carousel of front-end frameworks.  

I was becoming a jack of all trades but master of none. After a few months, I came to the realization that I did not even grasp the fundamental aspects of web development . I secretly knew it all along but did not want to admit it to myself. After acknowledging this, I went back to learning the basic concepts, and shortly thereafter, I landed my first internship.  

If you understand one framework…

The most significant realization came after two years when a situation at work required me to learn a new framework again, but the learning process was quite straightforward. It was clear that I had gained more experience, but it was not just that. I realized that a deep understanding of JavaScript, HTML, CSS, and browser superpowers was crucial. Experience certainly contributes to even faster learning because you can connect more things. Also, if you understand one framework on top of the mentioned skills, drawing parallels and achieving outstanding results in learning another becomes easy.  

A blessing and a curse

The ever-evolving world of front-end frameworks can be both a blessing and a curse. While they offer exciting innovations and productivity boosts, diving into them without a solid understanding of frontend fundamentals can lead to shallow knowledge. So, before you rush into the latest frontend trend, take the time to build a solid foundation it will pay off in the long run . 

The post New frontend framework, again?! appeared first on ShiftMag.

Web Accessibility basically means that the tools, technology, websites, and software are designed and implemented in a way that people with disabilities can use them and participate equally on the web.

As Josefine Schaefer, Developer Relations Engineer at Storyblok says, access to information is a basic human right and developers should do everything in their power to not create additional hurdles.

“It’s super important, especially for folks with disabilities, but it actually benefits all of us: whether you are looking at your phone in the sunlight and need higher color contrast or are using captions on a video in an environment where you can’t turn up the volume. All of these are accessibility features we all massively benefit from”

What should developers pay attention to?

What are some common challenges faced by users with disabilities when accessing websites?

Josefine: If you are interested in numbers, there is a great report by WebAim, it’s called WebAim one Million. They basically ran automated tests on one million websites to see what the most common accessibility issues are.

By far most common is low contrast text, missing alternative text and empty links or form labels.

Another big issue is keyboard accessibility: you want to make sure people can navigate your website with out a mouse, e.g. when they are using the keyboard or assistive technology.

What legal requirements or standards related to web accessibility are there?

Josefine: In the EU, there is a Web Accessibility Directive, which requires public sector organizations to have fully compliant websites since 2020, and accessible mobile apps since 2021. There is also the European Accessibility Act (Directive 2019/882), which is a landmark EU law that requires some everyday products and services to be accessible for persons with disabilities.

It follows a commitment to accessibility made by the EU and all member states upon ratifying the United Nations Convention on the Rights of Persons with Disabilities. It covers certain products and services, which from June 28th 2025 onward need to be compliant with Web Accessibility.

How to test for web accessibility

What are some methods or tools that developers can use to test the accessibility of a website?

Josefine: There are many different ways to test for web accessibility. A good place to start is usually a general, automated audit, like with the Lighthouse report where you can explicitly check for accessibility, or with the Axe Dev Tools. This kind of automated report will guide you through issues and provide explanations of what could be improved. This can then also be a starting point for further investigation. It will bring insights about color contrast issues, missing alternative text or empty links.

But regardless of how well it works, it’s important to double-check manually, test the keyboard functionality and if possible, have testers with disabilities who use screen readers and assistive tech natively.

The importance of semantic HTML

How can you ensure that images on a website are accessible to users with visual impairments?

Josefine: Always make sure that you include alternative text for images unless the images are purely decorative. The alternative text should describe in brief words what you are trying to bring across with the image. You don’t have to say “image of…” or “photo of…” as the screen reader will announce an image, anyway.

What is the role of semantic HTML in creating an accessible website?

Josefine: It’s super important to use semantic HTML to bring across structure and meaning, rather than just styling elements like spans or divs to look like, for example, a headline or a link. This way, you are conveying meaning to screen readers and assistive tech: by using landmarks for example, like a nav element, users can directly jump there and know what to expect. It helps screen readers announce content in a more structured way (e.g. in a list, it will tell the user how many elements and which elements it is currently on…).

Also, HTML elements come with some basic default styles and inherent functionality. Think of the element, for example, you can inherently click it, it has a hover style and a characteristic look. All of this, you would have to build in manually if you didn’t use the element – lots of time and energy saved!

Please describe the importance of proper heading structure in web content and how it contributes to accessibility.

Josefine: Part of semantic HTML is also the use of h1 – h6, in reasonable order. Use the different headline levels to create a meaningful hierarchy – this way, if you are using a screen reader like Voice Over for example (built into Mac), users can skip through links, headlines, or other interactive elements. This is much faster than going through all the content to find something specific.

Try using only a keyboard for a few minutes a day

Please describe the importance of proper heading structure in web content and how it contributes to accessibility.

Josefine: Part of semantic HTML is also the use of h1 – h6, in reasonable order. Use the different headline levels to create a meaningful hierarchy – this way, if you are using a screen reader like Voice Over for example (built into Mac), users can skip through links, headlines, or other interactive elements. This is much faster than going through all the content to find something specific.

Why is keyboard accessibility important, and how can developers ensure that all interactive elements on a website can be navigated using a keyboard?

Josefine: Keyboard Accessibility means that users can not only navigate a page with a mouse, but also use the keyboard, tab key, and arrows to navigate. A lot of assistive technology works in a similar way as the keyboard, so it opens up your content to a large audience. It’s also great for general user experience, as it can be much faster than using the mouse.

A few things to look out for in terms of keyboard accessibility:

• Make sure all interactive elements are focussable, and the focus state is visible (and has enough contrast),
• Make sure the functionality you would get through the hover effect is also applied for keyboard users,
• The reading order should be the same as when browsing through a page with the mouse: in English, that would be top to bottom, left to right.

Try it yourself: try only using a keyboard for a few minutes a day, visit your favorite web pages, and try to get around. Can be a nice learning experience.

Web Accessibility improves UX, performance, and SEO

Web accessibility best practices and guidelines can evolve over time. How do developers can stay up-to-date with the latest developments in web accessibility?

Josefine: That’s a good question. Some things change over time, but actually, most things stay consistent. A great place to start is the WCAG – the web content accessibility guidelines. Those are the rules to follow when making sure web pages and apps are accessible. A nice blog to follow is also the A11y Project – if something did change drastically, you would surely find out there.

How does web accessibility benefit not only users with disabilities but also website owners and developers?

Josefine: That’s the beauty of it, really: implementing web accessibility benefits all of us! Despite making a big difference for folks with disabilities, it also improves general user experience, performance, and likely search engine optimization. As a website owner, this will benefit your business as it increases traffic and makes your users happy; making your website accessible can help broaden your reach and offer your services to a wider audience.

If implemented correctly, web accessibility can help make the code more readable and easier to maintain, which benefits web developers. So: Win win win

The post Josefine Schaefer: Accessibility improves UX, performance, code readability, and maintenance appeared first on ShiftMag.

At tech conferences, you usually expect to learn more about a specific technology or a tool, hear more about how to ship better software, be more productive, or learn about emerging trends in the industry. Not how to use coding to become better at – public speaking!

That’s why Jhey Tompkins’ presentation at the Shift conference in Miami blew away the audience. Jhey not only told but showed the audience how to use creative coding with JavaScript – using code to create art and multimedia content – to deliver highly entertaining and interactive talks. 

Bringing ideas to life with code

Jhey used to work at Google, Uber, Nike, and Monzo but describes himself only as “a web developer that thrives on bringing ideas to life with code.” And brought ideas to the life he did at the stage at Shift, interacting with his slides in real-time via voice and hand gestures with his phone and even giving the audience a chance to participate by popping emojis over his slides. 

After you’ve seen it, it’s hard to believe Jhey only started exploring the idea of this talk about a year ago. He admits this talk at Shift Miami Supercharge your skills with creative coding, Volume VIII: Make it pop! was the best in this series.

Building slides is hard

And he did start his public speaking journey by building slide decks, just like everyone else starts: 

Building slide decks is hard, whatever the format or the tool you use. 

My goal is to do something different for every talk I do. With slides, it takes a long time to design news slides every time.

In the end, no matter how much time I would spend doing the design, it never turned out just like I wanted it to. It takes work to show your personality through slides!

Jhey Tompkins

He used to get a lot of advice on how to make his slides pop by using animations, this or that element, this tool, or the other. But slides were just not it for him:

It’s all boring. I wanted to turn the idea of the slide deck upside-down.

Why not do it in the browser? 

Jhey Tompkins

Would you like to see 20+ slides and walls of code?

Learning public speaking and becoming confident on stage is a journey, Jhey says. His journey started by learning how not to do a tech talk from Chet Haase and his talk “Top Tips for Terrible Tech Talks”. 

The takeaway from that talk for me was to try and be a person in the room. Would you like to see 20+ slides with blocks of text or massive walls of code? Make it less formal. Make it engaging!

You can always see how good your presentation is by checking out the faces of people in the audience. No matter how good you find your content is, if they’re checking their Instagram while you speak….

Know your content inside out

Asked to share a tip or two for engineers to improve public speaking, Jhey offers simple but universally true advice – just be yourself. 

It’s a personal journey. It was a personal journey for me too.

 I can’t tell people how to do it. But once you start doing it, you find out who you are, what you like, and if you want doing public speaking at all or not. If you do, you become better the more you do it.

Jhey Tompkins

The biggest thing, he adds, is knowing your content inside out and trying and testing different things to find out who you are and what you want to say:

I know who I am. I simply present who I am and what I know. 

The post How to use code to deliver your best tech talk ever with Jhey Tompkins appeared first on ShiftMag.

CSS Wizardry’s Consultant Performance Engineer, Harry Roberts, has been a professional developer for 14 years and says he finds it funny how old trends in technology have become new again. He comments on developers’ tendency to get distracted by new frameworks again and again, and tend to fetishize frameworks. Oh, and he does not love the fact that everything is going JavaScript and into the browser.

As a Consultant Performance Engineer at CSS Wizardry, Harry also helps companies improve website speed and optimize front-end development.

Roberts has worked with some of the most prominent and respected global companies and organizations, including Google, the BBC, the Financial Times, and the United Nations. His meticulous and analytical approach has made him a go-to expert in the field, and he regularly speaks at conferences worldwide to share his knowledge with the technical community.

We’ll also share Harry’s insights, including his perspective on choosing the right tools for you and your team and whether the market needs so many tools. So if you’ve ever wondered whether you need all those developer tools, keep reading – we’ve got you covered.

On working at big companies and impact

Harry: Honestly? Some of the most meaningful work I’ve done has been with much smaller companies where you can affect way more significant change. It’s probably not a very “rock and roll” and exciting answer, but some of the most impactful work happens on smaller teams. Because it’s a small environment, your impact is way more significant.

But working for BBC before the Olympics, was inspiring. It was stressful but exciting, and working with the UN – you know you’re doing something good.

On website speed issues impacting business in the millions of dollars

Harry: It varies dramatically for some companies.

Companies leave hundreds of thousands of dollars on the table yearly because they’re getting site speed wrong.

Harry Roberts, CSS Wizardry

Most companies aren’t aware of how serious it is. The way I try to describe it is – if the roof blows off the top of your house, you notice it immediately, and you fix it immediately.

However, if the insulation in your roof isn’t perfect, someone might tell you you can save 500 euros per year on your heating bill if you put in insulation, but for you, it kinda works well enough for now. So for companies, it’s that kind of thing. Their roof blows off, and they fix it immediately, but it’s harder to notice slowdowns that might happen for 12 months.

So I’ve worked this before, where a simple 300 ms speed up would have made them an extra 8 million pounds a year, and I’ve worked with a client this year where a 500 ms speed up would make them an extra 11,5 million euros a year. These numbers are enormous, but it’s all because of lost sales. It’s not like someone took 11,5 million euros out of a bank.

It’s a simple case of them earning that much extra. It’s not as urgent if you’re missing out. It’s critical if you’re losing money. So many clients don’t panic until they hear those numbers and see how big they can be.

On developer tools making life easier or more complicated

Harry: I don’t think it makes it more complicated, no. Most developers can pick the subset of tools that suits them and their day-to-day work, safely ignoring anything superfluous. The more significant fear is the obsession with frameworks rather than developer tools.

On favorite developer dools

Harry: 100% DevTools, in whatever browsers you’re working and testing in. Beyond that, a good command of whatever text editor you use and any useful plugins. For more peripheral development work (i.e., not actively writing code), solid foundational command line knowledge is constructive: Git, basic Bash/Zsh, etc. As a Performance Engineer, I also have tools like WebPageTest (a wrapper around DevTools anyway) that I couldn’t live without.

On developers being fascinated by every new framework and tool?

Harry: Firstly, don’t be! We fetishize frameworks, and they often get implemented on projects before they’ve stood the test of time elsewhere.

Everything old is new again, and we’ve already seen some of the largest and most prominent frameworks return to the ideas and solutions of yesteryear.

Some frameworks’ most significant initial selling points are now almost universally regarded as anti-patterns.

Harry Roberts, CSS Wizardry

U-turns at the scale are pretty terrifying. Instead, look at the problems you must solve and choose the most straightforward available tool. Focus on the fundamentals, and the rest will follow.

(Harry is not the only one highlighting the focus on the fundamentals, Kelsey Hightower said exactly the same in his interview for ShiftMag!)

On [disappointement that] everything is going into JavaScript

Harry: It used to be that a user visited a URL, their browser requested a page, and the server built the page and sent it back. It was the norm, and it worked very, very well. Folk decided to improve this for many reasons by shifting the workload to make it more like a user visiting a URL, requesting a near-empty page, receiving it from the server, asking for potential megabytes of JavaScript, running the JavaScript, and then building the page in the browser.

I mean, on what planet is that going to be faster?! (Note: not Earth, as we’ve learned.)

Developers made this a lot worse when they forgot that HTML exists and went to extraordinary lengths to rebuild native, accessible, fast browser features in woefully subpar JavaScript.

Harry Roberts, CSS Wizardry

That’s a lot of work (and code) to do a much worse job than we were five to 10 years ago! Thankfully, people have started to notice that this new way it’s better, and more considered solutions are slowly coming to the fore. That is reassuring!

On predicting tech trends

Harry: I’ve been thinking about this a lot. Trends move fast. And my career has always been based on something other than trends. In a way, I’m dull. Certain things are just fundamental to how the web works. So I’ve always bet on soft.

I’ve always gone with the reliable way things work. And I’ve felt like some miserable old man in the last five years.

Harry Roberts, CSS Wizardry

Everything’s really going JavaScript and into the browser, and I’ve always felt uneasy about that. But it turns out that the new trend is going along with the old ways but in a better way. I find it interesting that everything old is new again. And I’ve been a developer professionally for 14 years. I’ve seen a lot of changes and trends. They progressed fast, but they’re sometimes the right thing to do.

So over the next 12 months, we’ll see a bit of a return to, well, not necessarily basics, but more advanced ways of doing the old things. Developers have gotten more insightful and more mature. What I’m going to be focusing on, I have yet to learn! I need to start thinking about where I want to position myself in the next 12 months. But the industry is beginning to mature, so we won’t need to move as fast. Indeed, from a site speed perspective, the industry is moving as fast as ever, and I can’t comment on anything beyond my field.

On Shift conference

Harry Roberts is a long-time supporter of the Infobip Shift conference. A few years ago, he participated as one of the speakers, and is coming back to Zadar this September.

Shift stands out as a rare gem in a world of cookie-cutter tech conferences.

Listening to insightful talks from the brightest minds of today’s tech scene while surrounded by the enchanting history of a town built nearly two millennia ago, you’d be hard-pressed to find a more inspiring blend of past and future.
Oh, and it’s the most fun you’ll have all year!

Harry Roberts, 2019

The post On fetishizing frameworks and everything old becoming new again with CSS Wizardry’s Harry Roberts appeared first on ShiftMag.