DEV Community: Andreas Møller

CSS has become too POWERFUL

Andreas Møller — Wed, 19 Nov 2025 13:45:05 +0000

Modern CSS is amazing. It empowers us to build incredible experiences on the web, but as CSS becomes more powerful, we are beginning to see a new weak point.

When I got my first job as a web developer, it was common to have to come up with different hacks to work around the limitations of CSS. Those times are long gone. Modern CSS is amazing. It has powerful layout algorithms, 3D transforms and an incredibly capable set of animation primitives.

Most of the limitations of modern CSS don't actually have anything to do with its capabilities. Instead, it has to do with how we write it. For this reason, the future of CSS might not be text files, but visual editors.

You might be ready to call blasphemy and close the tab in anger, but if you stick around i'll do my best to make the case.

Read the full article here

No Figma, I won’t fit in your little box

Andreas Møller — Wed, 01 Oct 2025 12:59:56 +0000

Once upon a time, design and code worked as one. Web designers would imagine beautiful designs and turn them into beautiful websites with HTML and CSS. As the web grew both in use and capability, companies started offering software services built entirely on the web. These companies needed more and more software to be built and more and more people to build it. They started sorting people under the names “Designer” and “Developer”, so they were easy to organize. Designers would go into a design team and draw user interfaces. Developers would go into a dev team and write code. And thus, the hand-off was born.
In the years to come, the divide grew stronger. Designers stopped writing CSS and withdrew to vector drawing tools like Figma. Developers started adopting web frameworks with increasingly complex build systems, making it ever more difficult for designers to contribute. And so, the hand-off grew stronger and darkness spread across the land.

Today, it is common for companies to have cross-functional product teams that combine both designers and developers, but they still work in separate tools and rely hesitantly on the dreaded hand-off.

Treating the symptom

Through the years there have been several attempts and hundreds of millions of dollars spent on trying to fix the hand-off. Despite this, we are no closer to solving the problem than we were 10 years ago. But, the hand-off is a symptom, not the disease. The real problem in this industry is the split we have created between “Designer” and “Developer”.

Where developers have HTML and CSS, designers have layers and style. Developers say “background”, designers say “fill”. Developers use flexbox, designers use auto-layout. The differences are tiny but just big enough to ensure there is friction. The hand-off is just a symptom of the larger issue: designers and developers speak entirely different languages.

A smaller and smaller box

When designers were kicked out of the codebase and found a new home in Figma, their roles slowly started to change. Instead of building user interfaces they created Figma designs. Instead of sharing links to websites they had built, they shared images on Dribbble and Behance. Designers became UI designers focusing more and more on the visual aspect of design and less on its function. Much of the functional aspects of design, such as interactions and accessibility, were left to the developers to figure out.

As the web evolved and CSS became more powerful, the gap between CSS and design tools grew. CSS now lets developers build responsive layouts using different layout modes, functions, and an ever-increasing number of relative units. Design tools still rely on pixels. Over time, more responsibility was moved to the developer, and the box that designers had been put in grew smaller.

Creativity withered

In the beginning CSS was very limited in scope, and designers often had to adjust their expectations to align with what could be implemented on the web. Today we face the opposite problem: CSS has far outgrown the capabilities of design tools like Figma in areas such as layout, animations, and especially interactivity. Even when it comes to colors and gradients, Figma is far outmatched by the capabilities of modern CSS.

Designers today are limited not by the platform, but by _tools and processes. _

Great design happens when you take good design and iterate.

Tools are not the only culprit. Any process with as much friction as the design hand-off will slowly kill creativity. When even the most trivial design fix requires you to create a Jira ticket for a developer, the easiest way is just to let it slide.

Great design happens when you take good design and iterate, but if the process for iteration is slow and cumbersome, then you never get there. For great design to happen people must be free to iterate, experiment and play: unburdened by tools and processes.

We wanted more

Some companies have addressed this by only hiring designers who can code. However, code was never a great medium for design.

The Nordcraft editor is built entirely in Nordcraft so we get to experience the benefits every day.

We started Nordcraft because we were not satisfied with the tools and processes that most software teams use today. We wanted a new set of tools that bring design and development together, instead of separating them. We wanted tools that are built on top of HTML and CSS that can take full advantage of the web platform, but with visual interfaces that enable rapid iteration and experimentation. Instead of being for designers or for developers, Nordcraft is for building websites and web applications. It does not dictate what roles you have, or who should do what. In Nordcraft, each team can draw their own lines and divide responsibilities as they see fit.

At Nordcraft we have brilliant designers who are more than capable of understanding most of the logic behind the product we are building. Likewise, we have engineers with a keen eye for design. Instead of putting people in boxes labelled “Designer” or “Developer”, we lean into the strengths of each team member, and complement each other when necessary. The Nordcraft editor is built entirely in Nordcraft so we get to experience these benefits every day. After working this way for three years it is hard to imagine ever going back.

For so many years we have been held back by the tools and processes that were the standard of the day. We spoke loftily about agility and the awfulness of waterfall, while picking up tickets from designers and passing them down the assembly line to a QA.

It is time for something new.

Stop trying to fix the handoff process

Andreas Møller — Wed, 02 Jul 2025 08:05:28 +0000

For ages now, we have been trying to fix the handoff process between designers and developers. The truth is it should never have existed in the first place.

The design handoffs are a standard in every product team today.

UI/UX Designers draw up the UI for a new feature
Designers send the design to the Engineers
Engineers implement the design
Go to step 1

For as long as the design handoff has existed, people have been trying to fix it.

The design handoff makes it impossible to iterate quickly. The steps above represent a utopian view of the process. In reality you usually end up going back and forth between step 1 and 3 several times before the feature is done. This isn’t a failure of the team. We have long known that the assembly line approach to software development doesn’t work. As an industry, we collectively rejected the waterfall model decades ago, yet the tools we use today are still designed for that era.

The second problem is that information is lost at every step. The majority of designers today have little to no technical understanding of the platform they are designing for, whether it is the web or native apps. They also often lack an understanding of the technical limitations of the system the team is building. This impacts their ability to design functional solutions and is usually not discovered until the implementation starts. The design tools we use today are exclusively focused on the visual aspect of design, and provide no way of describing the functionality. How something behaves is just as important as how it looks, but behavior is all too often excluded from the design handoff.
There are many more problems, like the fact that every feature has to be built twice — Once by the designer in the design tool and later by the engineer implementing the feature, but we will focus on the first two.

I have come to realize that these problems aren’t incidental — they’re baked into the very nature of the design handoff. They are not edge cases to be fixed; they are the logical outcomes of splitting design and implementation into two separate worlds. If we want to solve them, we can’t optimize the handoff — we have to eliminate it entirely.

Can’t we just generate the code?

In order to speed up development, several companies have tried to automate the handoff process by generating code based on the design. Figma tried to do this by connecting the developer's code editor with Figma and generating code directly in the text editor when the Figma file was updated.
Recently, we have seen tools attempt the same thing but using AI to generate the code instead of a normal compiler. While AI does add some improvement over the previous solutions, the two main problems with the handoff still exist:

AI can attempt to guess what was intended, but it ultimately can’t know what the designer was thinking at every step.

The design tools we use today are not designed to create working applications. Just like with the handoff, much of the critical information is lost in the process. AI can attempt to guess what was intended, but it ultimately can’t know what the designer was thinking at every step.
The process still only works one way. When the design is updated, the code has to be generated again. If one of the engineers made changes to the code after the handoff, those changes will be overridden. In order to enable fast iteration, we have to eliminate the handoff altogether so designers and engineers are free to iterate without stepping on each other's toes.

Should designers learn to code?

That is one solution that does address the problem, but it also creates a new one. It used to be the case that all you needed to know was a bit of HTML and CSS in order to style a website, but for most web apps that is not the case anymore. With the introduction of web frameworks, TypeScript, and various build tools, the barrier to entry to web development has increased by several orders of magnitude in the last decade. Upskilling every designer to essentially be a junior frontend developer as well is simply not feasible.
Designers writing code is not the answer. That is probably a good thing. A large part of the design process is visual, so code was never really a good fit.
Hiding in plain sight

It turns out that the solution was right in front of us all along. We are not the only industry that has faced this problem. The game industry faced the very same problem, and over 30 years ago, it solved it. Every new game that has come out in the last 20+ years has been developed using a game development engine, which is essentially a framework and a set of design tools bundled into one: a single tool shared by both designers and developers.

Designers are not just drawing pictures of the characters and worlds in the game; they are creating them in the very same tool where the engineers are programming the logic and behaviors. Updating the design does not break the logic, just as changing the code does not invalidate the design. Designers and engineers can iterate on the same features without overriding each other's work.
Every major game engine even has a visual scripting system that lets designers create much of the logic on their own. Where the tools we use on the web are enforcing silos, game engines help break them down.

In the game development world, it means that your tools and workflows can now be adapted to the capabilities of the team. If you have a designer who is very technical, they can now own much more of the process without needing the assistance of an engineer. Similarly, designers who want to focus exclusively on the visual design of the application can do that without requiring the engineers to duplicate their work.

There is not a game studio today that would ever entertain building a video game without the use of a modern game engine and the excellent tools that come with it. It is an absolute necessity when building AAA games that have to push the boundaries of creativity and raw performance.

A web development engines combine interactive design tools with a powerful web framework.

The future of web development tools is borrowing from that same idea, but designed from the ground up for the web. This is a whole new category that we are calling a Web Development Engine. Web development engines combine interactive design tools with a powerful web framework. Web development engines are designed for high-performing product teams. Just like game engines, the goal is not to lower the bar for entry, but to raise the ceiling for what we can accomplish.

Try Nordcraft for free

Stop Saying Democratize When You Mean Dumb Down

Andreas Møller — Tue, 24 Jun 2025 08:34:04 +0000

Ever notice how every new tech tool promises to "democratize" something? Is making our tools simpler really a kind of liberation, or a new form of control?

In the last couple of years we have seen a lot of tech startups become successful by providing simpler alternatives for well-established products.

Canva has seen impressive growth by offering a simpler graphic design tool. No-code tools like Retool are democratizing software development, Veed.io is democratizing video editing and AI is supposedly democratizing everything.

All these products make their field more accessible to people from the outside and have had a very meaningful impact on a lot of their customers. I have nothing but admiration for the tools, but I do have a problem with the narrative surrounding them.

Specifically the term “democratization”. It seems to mean going from using a (usually free) tool that requires study and learning, to using a paid tool that does most of the work for you. Going from difficult but free to simple but controlled by a single company is almost the exact opposite of what the word democratization means.

But my issue with the phrase is much deeper. The word implies that what was there before was a form of oppression. Something was being kept from a class of people, but now finally they can access it. The reality is that if you wanted to learn graphic design, software development or video editing, you always could. There are excellent free tools available and anyone could learn to use them. If you were willing to spend the time.

When a word like democratization is used in this way it implies that having to learn things is a form of oppression. It shifts the responsibility away from the user. “It is not my fault that I don’t know Graphic design, it has not been democratized”.

This trend is even more clear with the onslaught of new AI tools that has hit the market in the last year. People are calling for the end of Software Engineers, Designers, Video Editors, Marketers and every other knowledge-based profession you can think of. You don’t need creative skills, what matters now is taste and a great idea. Yeah, about that.

You are not born with taste

The thing about taste is that people who aren't creative, don’t have it. Or at the very least, they lack the ability to express it. Anybody can look at a UI and decide that they don’t like it, but by itself that is not useful. What separates designers from everyone else is their ability to see what is wrong with a design and fix it. That is a skill that requires experience and training. Learning to use Figma takes a couple of hours. Learning to become a great designer takes years.

Design is also far from limited to the visual expression of software. Design is present in every aspect of how it looks, feels and functions. Software designers have to deeply understand who the software is for, and how it will be used. What is the user experience like for a completely new user and what is it like for someone that has been using it for years?

It is a massive puzzle that the software designer has to make sense of. It is a job that you can get better at your entire life without ever feeling that you have mastered it.

Tools are just tools

I like Canva because I am bad at design. Canva is dumbed down enough so even I can make visually appealing graphics. They are not great. But they are not terrible either. Canva accomplishes this by removing most of the actual tools from their graphic design tool, replacing it with templates and AI features. Using Canva does not make me a good designer and I am OK with that.

I almost never use no-code tools. I have been writing software for over 20 years and these tools don’t offer me anything that I can’t already do much better. These tools simply weren’t built for me.

If you are curious about design, software development or any other creative profession, by all means start with one of these simplified tools. Once you find the thing that you are passionate about, upgrade your tools and invest the time it takes to master them.

When the tools we use no longer require any skills, we no longer matter. The best design is the one generated by the best design tool and which ever company owns the best design tool has a monopoly on design.

Mastering your profession is what sets you apart in a world where every new tool seems to start a sprint for a collective race to the bottom. As AI is getting more and more efficient at generating slop, your hard-earned skillset is what is going to keep you relevant. Having to invest time in learning new skills is not oppression; it is what brings you freedom.

Nordcraft completely revamps the design experience

Andreas Møller — Mon, 12 May 2025 13:48:50 +0000

We spent the last few months completely redesigning the style panel from the ground up. Styling your application in Nordcraft is now more delightful than ever.

The new style panel is packed full of great features: many more than we can cover here. Lets take a look at the highlights.

Everything at a glance

It is easy to see exactly which properties are set, without extra clicking or scrolling
You can now easily see every property that is set for the selected element without having to open panels or endlessly scroll. We removed the clutter but kept the most used properties front and center.

Each section expands to show you the full list of available styles.

⌘ + Search

We added a search feature so you can easily find any style property. This is great for new users who are learning to navigate the style panel, and for experienced users who want to work even faster.

Press ⌘/CTRL + S to highlight the search input.

Backgrounds

We have a brand new window for working with backgrounds. Set a color, image, or use the new gradient editor.

We believe that your tools should not hold you back, so we also let you control all the different properties of your backgrounds like background-position, background-size, and background-repeat.

You can add multiple backgrounds to the same element to create more interesting effects.

CSS if you want it

For every property you can see exactly what CSS will be set:

or you can see the complete CSS for an element with the CSS view:

One more thing...
You can now rearrange or duplicate elements directly inside the canvas using drag and drop.

Building a Drag and Drop feature for something as complex as a web app is actually quite a complex task because there are a lot of strange edge-cases, and deeply nested elements. To help make sure you are dragging to the right location we added a separate mode that gives you complete freedom to place the element exactly where you want. Just hold down ⌘ or CTRL while dragging.

For more information, check out the documentation on drag and drop, and view the new keyboard shortcuts.

What's next?

We are not done! We still have a ton of new features and improvements coming to the style panel that will make building UI in Nordcraft even more enjoyable.

We are also working on an Animation editor that lets you create keyframe animations right inside the editor. Stay tuned!

Programming is magical but it is not magic

Andreas Møller — Fri, 21 Mar 2025 14:59:06 +0000

AI "vibe coding" enables quick app creation, but lacks the control of traditional development. Developers ensure reliability, which AI alone can't provide.

Read the full article

They lied to you. Building software is really hard.

Andreas Møller — Mon, 24 Feb 2025 19:12:27 +0000

Read the full post here:

https://toddle.dev/blog/they-lied-to-you-building-software-is-really-hard

Are SPAs still relevant in 2025?

Andreas Møller — Fri, 21 Feb 2025 22:04:56 +0000

There are a lot of new tools to help us build fast websites in 2025. So do we even still need to build SPAs?

Watch video

toddle's open-source progress

Andreas Møller — Sat, 11 Jan 2025 11:00:13 +0000

Since 2024 we have been working on making our next generation web app editor open source.

I am excited to finally be able to share our progress:

https://toddle.dev/blog/open-source-progress-update-2024

Lighthouse wars!

Andreas Møller — Fri, 18 Oct 2024 21:10:10 +0000

https://lighthousewars.app lets you battle your website against some of the best web builders on the market.

Make sure to turn the music on!

Lighthousewars was built in https://lighthousewars.app to show what the platform is capable of.

What are abstractions in programming

Andreas Møller — Tue, 10 Sep 2024 17:35:58 +0000

watch here

Nordcraft, the visual programming platform that is built in Nordcraft

Andreas Møller — Sat, 31 Aug 2024 21:46:23 +0000

Visual programming has been around since people started connecting tv screens to computers. Every few years a new one comes along and is then forgotten almost as quickly as it was discovered.

Visual programming never made it into the mainstream programming community, but why is that?

Are text files really the best possible interface for programming?

For most visual programming platforms the problem was that they lacked the power and flexibility of text based languages. Once programmers started building more complex applications they would hit roadblocks and eventually not be able finish the task they set out to accomplish.

But is this an inherent limitation of visual programming, or have we just not invested enough time in developing this paradigm?

I strongly believe that the latter is the case, which is shy I started toddle.dev. toddle is a platform that lets you build complex web applications with a powerful visual interface. Anything you can build in a framework like React or VUE you can build in toddle.

To really test the limits of what toddle can do, we build the whole visual editor in itself.

I would love to hear what you all think. Could visual programming be the future of software development?