Choosing the Right Tools for the Modern Web – A Conversation with Lemon

If you’ve spent any time exploring the modern web, you’ll know that choosing the right technology stack has become more challenging than ever. Between traditional CMSs, headless architectures, frontend frameworks, AI-powered tools, and constantly evolving development practices, building a future-proof website can feel like navigating a maze.

That’s where people like Lemon come in.

A developer advocate, web enthusiast, speaker, and relentless experimenter, Lemon has spent years helping developers and organizations make sense of the ever-changing web landscape. His work spans content management systems, frontend technologies, developer experience, and emerging web standards. He’s also known for bringing curiosity, creativity, and a healthy dose of fun to topics that are often discussed in overly technical terms.

At Webinale Berlin 2026, Lemon delivered two memorable sessions: CMS Speed Dating and The CSS You Don’t Know About. While one explored the strengths and trade-offs of modern CMS platforms and the other uncovered lesser-known CSS capabilities, both talks shared a common theme: helping developers build better web experiences by making smarter technology choices.

In this edition of The Better Web Dialogues, we speak with Lemon about the future of web development, the evolving role of CMSs, the hidden power of modern CSS, and what it takes to create websites that are not only functional and maintainable but genuinely enjoyable to use.

The journey

Q. For those meeting you for the first time, can you tell us a little about your journey into web development and what keeps you excited about the web today?

Like a lot of people who do this for a living, I didn’t originally intend to make websites for a living. What I wanted to do was work for music magazines. I wanted to be where the cool weirdos were at. I wanted to hang out backstage. I wanted to be part of an exclusive club. But then, once I actually got a job for a music magazine, I realized “music magazines” weren’t going to be A Thing for very much longer. So I taught myself HTML. All tables all day at that point. And then eventually I realized, that’s actually where all the cool weird people are – on the internet.

I stuck around because I genuinely continue to be in love with The Web. The World Wide Web is the singular most impactful publishing platform in human history. Literally anyone with a bit of motivation and something to say is able to put their ideas on the internet, tomorrow, for basically no cost. As complicated as we’ve made everything, the fundamentals of The Web: HTML, CSS, and JS – they’re fault-tolerant. They’re friendly. And there’s more education in web development than in chemistry. The shelf-life might not be the same, but you’re inside a field that’s evolving at a different rate.

Q. Your work spans development, CMSs, design, and experimentation. How would you describe your approach to building for the web?

A major part of that depends on who I’m doing it for. If it’s something I’m doing for myself – if it’s one of the games on kinda.fun or some silly experiment for ahoylemon.xyz – then it’s distilling it down to the idea: What am I trying to make, and what will be the most pleasurable way to make it? My side projects – some of those are about stretching some flabby technical muscle, sometimes it’s about testing a hypothesis, but it’s always about “How can I make sure I like doing this?” So sometimes the architecture is clumsy, or sometimes I’m doing something complicated just to see if it will work, but the zen of the making is half of the point.

When I’m building for a client, the thought process is a whole lot more pragmatic: What are your organizational goals, your known limitations, and what’s missing in the middle? The answers are different every time, and sometimes it takes a few days to get honesty, but I’m rarely building a website because a client asked me to. I’m solving a client’s goal using some form of technology.

CMS Speed Dating (A topic from Lemon’s talk)

Q. Your “CMS Speed Dating” session was a fun and engaging way to compare CMS platforms. What inspired the format?

Thanks! I only wish I had more time to introduce more CMS platforms, because there are so many of them. I think the original hook, in my mind, was the idea of someone looking at CMS like they use Tinder: Maybe you’re looking for a long-term partner, and you find a fun thing that seems short-term. Or the opposite. Even the biggest CMS are driven by one (usually very strong) personality. And it comes across. Most of them are offering the same thing, but actually spending time with them looks a lot different.

Q. If a company asks you, “Which CMS should we choose?”, where do you usually start the conversation?

I’ve never been asked that question! Usually, they’ll come to Meeting 1 with WordPress in their heads, and I’m the one who has to turn it into a real conversation. But once we’re having that conversation, there are a couple of key factors. How often do you realistically see yourself updating this? Who’s actually going to be doing that updating, and how much do they want to think about the mechanics of it? Is everything going to one website, or does the same content need to show up in an app, a newsletter, and whatever platform gets invented next year? And the question nobody enjoys answering: what happens when the person who set it all up moves on? Once I’ve got those answers, the CMS mostly picks itself. A small team updating a few times a year shouldn’t be saddled with something that needs a developer on standby. Somebody publishing daily across five channels is a completely different date.

Q. What are the most common mistakes organizations make when selecting a CMS?

Oh, it’s definitely building the thing out with a WYSIWYG editor. I’m thinking about Elementor and Divi specifically – I don’t usually like to call specific tech out as “bad”, but in this case I’m happy to. It’s a mistake every time. Anything where “editing a page” means “move these blocks around”. It means that every single time somebody edits a page, they have to be a web designer in that moment, but with a very limited skill set. It makes content an absolute chore, and your website will definitely break at some point. And when it does, I am not fixing it.

Basically, content entry and layout should have an established structure and rules. If you’re going to go without – well, in that case, use something like Wix and accept that it’s all meant to be thrown away when you find a better thing.

Q. Are we entering a post-CMS world, or are CMSs simply evolving into something different?

Oh, no way would I describe The Web as post-CMS. I mean, there are always things that aren’t. Right now, you’ve got some temp build one-shots on a Vercel server, and people publish on Substack. At one point, people used Facebook as their home page, and every major brand needed a Twitter persona. Before that, there were the niche forums and LiveJournal accounts. People slide into the convenience of superplatforms until they realize they can’t get their needs met that way.

It’s always evolving. It should. The Internet always does. But publishing your own content on a platform you actually control? That appeal never goes away. If anything, it’s getting more urgent, and it’s the hill I’ll happily die on. If anything, I think it’s a good time for headless CMS: The idea of “Write once, publish everywhere” has a lot of impact when we’re in a place of so many islands, and with LLMs being consumers of the content as well, and not needing all the chrome.

Q. How should teams balance flexibility, developer experience, content editor experience, and long-term maintainability when choosing a platform?

I think it should be triaged based on the makeup of the team actually working on the site itself. If the actual frontend and backend code are going to be written once and live for years, Developer Experience is less of a priority. But if there’s a developer on-staff? Let’s modularize the components to be extendable. Let’s create some automated jobs. None of us is an oracle; we can’t predict the future. But we can take the team that’s currently devoted to a website and give them each a way to do their jobs meaningfully.

The CSS You Don’t Know About (A topic from Lemon’s talk)

Q. Your second session focused on CSS features many developers don’t know about. What inspired that talk?

Honestly, I like to always have a modern-CSS talk in the arsenal, and I’ve written several of them over the years. CSS moves fast enough that there’s always a fresh batch of features most developers haven’t noticed yet, so the talk basically refreshes itself. Under all of it is a love for CSS, I never get tired of teaching. With web development, having good fundamentals of CSS (and recognizing the separation of concerns between markup and styling) leads to better accessibility, simpler build processes, and re-stylable molecules. And with modern CSS, that gets even better.

In general, I try to teach the mantra that if you can solve a visual problem using CSS, you probably should. The syntax is less important than knowing what’s available, and that’s what I love to show people.

Q. Are there any CSS features that you think deserve far more attention than they currently receive?

I think there are a couple that really can be game-changers for anyone dealing with frontend development right now:

• has() is a solution that was elusive for a long time. When you were choosing a selector, you were forced to always go down the chain into greater specificity, and targeting a parent based on what happened to the child was impossible with CSS alone. Now, you can wire up any DOM element to respond to any other DOM element based on hover/focus state or class. This eliminates a LOT of cross-dependency, and gives you way more flexibility in writing markup the way you want it.

• Container queries are now just a drop-in replacement for media queries. Rather than thinking about the screen, you can think about the box itself. Each box can get its own sizing rules, which makes responsive development truly self-contained.

• And then both animation-timeline and view-transition are incredible: Declarative ways to add impactful animation without overhead.

Q. Why do you think developers often reach for JavaScript solutions when CSS can solve the problem natively?

Mostly, I think it’s from habit. These languages evolve – I think people can lose sight of what’s possible, what’s complicated, what’s expensive. There are things you can do in CSS (like parallax or grid reorganization) that you wouldn’t have found possible six years ago. JavaScript would have been necessary. But that gap keeps shrinking. 

Some time ago, I remember when there was a deliberate push towards CSS-in-JS, paired with JSX. Basically, to do away with CSS-based styling entirely, and hand everything (markup, styles, interactivity, backend) all over to JavaScript, and have everything be monolinguistic. I get the appeal, but I do think it’s a mistake. It means taking web conventions that have been actively worked on for over thirty years and handling them all inside a language that’s never been complimented for its stability. If you don’t like CSS because you think it’s confusing, I’m empathetic to that. But the solution isn’t to deny its existence, it’s to learn enough so that’s not the case.

Q. How has modern CSS changed the way you approach interaction design?

At this point, with grid, container queries, and built-in defaults, I can make a prototype webpage with a good amount of complexity in maybe 6k of CSS, uncompressed. I’m not thinking about edge-cases, I’m not thinking about if/then, and I’m definitely not thinking about browser support.

Most interestingly, I can do all the markup before I even get designs, because it’s easier than ever to backfill. You can look at Stephanie Eckles’ Style Stage (the modern equivalent of CSS Zen Garden) and see how you can take the exact same markup and make it look a thousand different ways with a bit of finesse.

Q. If someone hasn’t revisited CSS seriously in the last few years, what would surprise them most?

Probably the most surprising thing is how CSS preprocessors (Sass and Less) have basically been folded into native CSS enough to make those other languages nearly deprecated. You’ve got the concept of @imports, you’ve got CSS variables (which are even better than Sass variables, because they’re reactive), and you’ve got nesting. All the niceties that made people want to add Sass to their stack have been absorbed with the appreciation of the CSS Working Group, and it really does a lot for developer ergonomics.

UX, interaction & performance

Q. How do you think interaction design has evolved over the last decade?

There was a fad I really didn’t like about what I’d consider maximum scrolljacking. You get to a website, you start scrolling, and it just does a lot of stuff on your screen: Stuff swooshes in from the right, items appear, your focus bounces all over the place. It’s fun as a tech demo, but as a website trend, it’s annoying. You’ve turned an interactive experience into what’s basically a scrubbable .mp4 file.

I think where we are now, and it’s partly because of a robust, natively supported View Transition API, is that we’re getting a lot more transitions between the pages themselves. You can come to a page and start clicking around to other pages and see elements enlarge, shrink, and move based on your current context. There’s so much to explore there, and it’s exactly the kind of satisfying user experience that made people reach for cumbersome single-page apps a decade ago before they realized the weight wasn’t worth it.

Q. What separates delightful user experiences from merely functional ones?

I think a “delightful” user experience is something that’s considered during the design phase, rather than a cheap add-on at the end. Those basic tricks (like soft color changes, slight scale-ups on hover, maybe a drawn underline), they all add a feeling of polish, but they miss the window of “delight”. If you want something more impactful, you should at least sketch in that idea before designing the layout: For example, variable web fonts are very much A Thing. And they look great! I really want to see more websites play with the gamut between the subtle changes you can make to a font’s weight, slant, and serif rather than just alternating between normal, bold, and superbold.

Q. Is the web becoming too complex? What can developers do to keep experiences simple and intuitive?

Well, yes, but fortunately, there has always been a trap door. “The Web” has always had very complex avenues, even in the beginning. It took a lot of technology to make online banking a concept that somebody could trust. It took complicated problem-solving to make Netflix work. The big FAANG companies are going to have tens of thousands of web engineers solving their problems on the internet. But the Web is a big place. As long as you can render Tim Berners-Lee’s first website in your browser, as long as you can view source on the original Space Jam website, the Web is something for everybody to learn from.

Q. Are there examples of modern websites getting UX wrong despite having access to better tools than ever before?

Well, absolutely, yes. Because big organizations can really lose sight of the perspective of their end users. They can rely too heavily on their brand book to create components that look like their ideals rather than the actual problem and solution statements that accomplish both the organizational goals and the user’s intent.

I don’t think this is a matter of tooling. It’s a matter of psychology. If you have the money, the ideal way to handle this is a “fish bowl exercise”: Put a bunch of volunteers in a room and ask them to do things with your current UX. When they struggle, you’ll know. And you’ll always be surprised to learn the “obvious” thing actually isn’t obvious to them.

And if you can’t get that elaborate, anything approaching real-world user-testing is valuable. Take somebody completely tabula rasa and have them use your website and self-report. Plead with them to be brutally honest. And then, if even that is too cumbersome, look at your competitors – how do they handle the same workflow, and ask yourself why they chose to do it that way.

AI and next-generation development

Q. AI is rapidly becoming part of the development workflow. How do you see it changing the way websites are built?

I’d argue “rapidly becoming” is less accurate than “rapidly became”, but I concede the premise entirely. Agentic development is definitely A Thing, and mindsets have adjusted as a result.

The word that a lot of people like with agentic development is “velocity”, and I think that’s absolutely valid. Expensive tasks become cheaper, and that’s good in a lot of ways. Keeping current with documentation has never been easier, so rather than creating hundreds of unnecessary docs, just keep the half-dozen that matter up-to-date every time you PR. And for a lot of people, TDD (test-driven development) was just a pipe dream. Now you can do red -> green development so much easier, as a matter of course, leaving the third item (refactor) for the human and agent to agree upon.

Q. What parts of web development do you think AI can genuinely improve, and where does human creativity still matter most?

Speaking about frontend specifically, I think people are still leaning too much on “ask the AI to do a one-shot design” (which is a direction, but very often leads to crummy cookie-cutter designs) as opposed to “give AI a corpus, a ruleset, and the directive to present options.” The iteration is fast, and that can be lovely, but the developers and designers should not be abdicating responsibility, especially when it comes to taste. Make documentation the AI must absorb, try some throwaway designs, and then tighten your design docs from there.

Q. Which current web development trend do you think is overhyped, and which one deserves more attention?

Chat as an interface isn’t interesting to anyone anymore, and people doing actual agentic UX need to be way more creative about that. Something that can offer quick guides from massive text is great, but that conversation isn’t started with “What can I help you with?” Users have seen that, and it’s lame. Make some decisions, offer some guidance, and don’t make it a chat window.

One-pagers are better than they ever have been before. Speak to a very specific group with a very specific message. If your site has a thousand pages and several audiences, they shouldn’t be coming to your home page first. They should be seeing the page that speaks to them specifically.

Looking ahead

Q. What excites you most about the future of web development?

I’d actually say that the barrier to entry for web development is lowering, and that’s extremely exciting to me. There used to be this mystique about “those who can code” vs “those who can’t”, and the stratification just kept getting more severe as meta-frameworks evolved in complexity. Now, we’re moving back to MPAs (multi-page applications), we’re using simpler tools with less configuration, and we’re accepting that the occasional “vibe coding” exercise has value even if the resulting code needs to be refactored. All of this is a good thing. And selfishly, it’s good for me: the less ceremony between an idea and a working page, the more room there is to make dumb, joyful stuff for no reason. That’s the whole reason I fell for The Web in the first place, and it’s the part I’d never want to optimize away. An easier web means more people get to build the weird little thing that only they would think to build.

Q. If you were building a website from scratch today, what principles would guide your technology choices?

Hah! I mean, I’m “building a website from scratch” at least once a month, so that’s hardly a hypothetical.

My primary guiding principle is “complexity only when I need it”. I tend to start with a really really small node package (Pug & TypeScript, maybe Sass, and browser sync) just to get started on the stuff that matters. When do I decide I need Vue? That’s when I add Vue. Partway through, I decide I need Nuxt as well? Okay, quick refactor to get Nuxt into this project. Maybe down the road, I anticipate having this do stuff with Firestore, but I’m not gonna add Firebase dependencies until I’m actually using them. It’s so easy to add complexity to a website. It’s much harder to remove it.

Closing question

Q. What’s one thing the web used to do better 10 years ago than it does today?

It used to be less reliant on the same twelve companies convincing you to convert your product to their platform.

PHP was never the language for cool kids. PHP developers had to accept that fact. But the idea of “I make my website using some CMS, I host it somewhere, and now the only thing I pay for is hosting costs” was always part of that ecosystem. We’ve let some of that be taken from us, but it’s not hard to get it back. Unless you want to set up a NAS under your desk just for self-hosting your website, you probably need to pay somebody to handle the actual website serving. But that can be incredibly cheap, and you have thousands of legitimate options there. Pay for your hosting, but don’t accept their platform as your ruleset.

About Lemon

A web developer and comedian from Minneapolis, MN, Lemon has been making things for the web for over two decades. Professionally, his role is to help organizations make better technology decisions, but personally, he likes making dumb websites.

For evidence of this, you can visit his personal site at AhoyLemon.xyz, listing a number of his personal off-kilter projects as well as his conference history. He’s spoken at over 60 conferences around the world about the medium he loves.

He works at Minneapolis’ own Blank Metal (“Your new favorite AI engineering partner”), and he’d really, really like you to play at least one of his games at kinda.fun and tell him what you thought of it.