I like Framer.
I should probably start there, because this isn’t really a story about discovering that Framer is bad and code is good. Framer is an incredible capable tool, and for a long time it was exactly what I needed. It let me take something from an idea to a designed, animated and deployed website ridiculously quickly.
But eventually, I started noticing something.
The better I got at Framer, the more time I seemed to spend trying to get around Framer.
Framer was great, until it wasn’t
Coming from design, Framer made a lot of sense to me. There wasn’t much of a gap between designing something and building it. Layout, typography, responsiveness, animation and publishing all lived in roughly the same place.
For client work, that is still incredibly valuable.
But the kinds of websites I wanted to make started changing.
I wanted more unusual interactions. More control over transitions. More control over what was happening while a page loaded. More control over assets. More control over basically everything.
And slowly, the abstraction that made Framer so convenient started becoming the thing I was fighting against.
There were also more practical problems.
Bandwidth became something I had to think about. Pricing started bothering me, particularly when things like locales and additional project editors entered the equation (fees kept on adding up). Features that felt like they should be relatively mundane could noticeably change the recurring cost of a website.
Performance became another consideration.
Framer is built around React (I think), but I don’t think blaming React itself would be particularly fair. The problem for me was control. As my sites became more interaction-heavy, I had less control over exactly what was loading, when it was loading, what was being rendered and how everything fit together and the most importantly, site speeds took a direct hit.
For simple sites, I rarely cared. For the sites I increasingly wanted to build, I cared a lot. I started writing code inside my no-code tool
This was probably the point where the switch became inevitable. I started making custom components.
At first, that was great. Framer lets you extend what the visual editor can do with code, and suddenly a lot of ideas that didn’t neatly fit into the platform became possible. Guess what you can also sell those components in the Framer marketplace as well (which was a huge plus, till Framer 3.0 - more on that another time).
Then I found myself making custom components more often (obviously).
An interaction needed something custom.
An idea didn’t quite fit the existing tools.
Something needed more logic.
Another thing needed a workaround.
Eventually I had to ask myself a fairly obvious question: If I’m writing increasingly more code to get around the boundaries of the platform, why don’t I just build the website with code?
So I tried Vue (on a whim, also because my goat Jesper Landberg uses it).
Vue was harder
There’s no inspirational transition here where I installed Vue and suddenly became enlightened.
It took longer.
I had used HTML and CSS before, but I had to properly freshen up on both. JavaScript mattered considerably more. Things Framer handled invisibly were suddenly my responsibility. There were components, packages, routing, build tools, errors in the terminal and plenty of moments where something didn’t work because I had misunderstood something embarrassingly basic.
I don’t even use Tailwind.
And that turned out to be one of the things I really liked about Vue. I didn’t need to completely adopt someone else’s idea of modern frontend development before I could make something.
I could write normal HTML. Normal CSS. Normal JavaScript. And things just worked.
That progressive nature of Vue isn’t just marketing. It is probably one of the biggest reasons the framework clicked for me.
Vue is ridiculously underrated
This is the part I didn’t expect (I was living under a rock). Good platforms don't get press like the billion dollar startups like Webflow or Framer and I was oblivious to standard platforms.
Vue in my eyes was a coding final boss (equivalent to a Hollywood hacker smacking keyboard in a green terminal to my grandmother).
There are obviously much larger conversations around React and its ecosystem, and React tends to dominate discussions around modern frontend development. But from the perspective of someone who sits somewhere between designer and developer, Vue feels almost suspiciously well suited to this kind of work.
A Vue Single-File Component makes immediate sense (sometimes a nightmare to navigate though):
There isn’t a huge conceptual leap between designing a component and thinking about one this way. And Vue doesn’t punish you for starting simple.
I can make something with essentially vanilla HTML and CSS, then gradually introduce state, composables, APIs or whatever else the project actually requires. Or while gradually amassing the knowledge required to navigate through complex problems.
Add Nuxt on top and it becomes an incredibly capable environment for making actual websites.
There’s also a less scientific reason I was interested in it: Jesper Landberg (as aforementioned) is one of my favourite creative developers. Seeing the kind of digital experiences that can be built with this ecosystem definitely made Vue more interesting to me.
So yes, Vue gets some completely biased bonus points from me there.
I don’t have to build everything myself either
One thing I underestimated before switching was just how much stuff I don’t have to build from scratch. There are a lot of component libraries and open-source Vue components available for free. And I’m not just talking about buttons, dropdowns and generic UI elements.
There are genuinely beautiful interactions, animated components, navigation patterns, transitions and interface primitives that you can bring into a project.
That saves a ridiculous amount of time.
Instead of spending hours recreating an interaction I’ve seen somewhere, I can often find a well-built component that already does most of what I want, bring it into the project and modify the rest until it fits.
And that’s the important part.
I’m working with the actual code. I can change the styling. I can change the animation. I can change the timing, behaviour or structure. I can strip out the parts I don’t need and combine it with something else. Having complete control doesn’t mean having to build everything from
zero.
That’s probably one of my favourite things about working this way.
I can use other people’s work as a starting point without necessarily being constrained by the decisions they made. The difficult part eventually became the good part
In Framer, a lot of decisions are already made for you.
In Vue, I have to make them.
Initially, that feels worse. Eventually, it becomes the entire reason to use it. If I want an asset loaded immediately, I can do that. If something shouldn’t load until later, I can control that too. I can decide how images are handled, how a transition works, when an animation initializes, what happens during navigation, where my content comes from and how the application manages its state.
I can choose my animation library.
I can choose my CMS.
I can choose my hosting provider.
I can install a package, use an existing component or write the functionality myself.
And if something behaves badly, I can actually go looking for the reason.
That’s a very different relationship with the website.
I’m no longer asking: Can my website builder do this?
I’m asking: How do I want to build this?
That’s probably the biggest difference between Framer and Vue for me. AI made the switch much easier and I also don’t think I’d write the same article five years ago.
And my website costs almost nothing
This one is difficult to ignore.
Framer free plan is too constrained, the basic one starts at €120 + tax.
Vue itself costs me nothing.
Nuxt costs me nothing.
There are free tiers available for hosting and content infrastructure that are more than enough for many personal websites. And most importantly, the website isn’t tied to any of them.
I own the codebase. If I don’t like one provider anymore, I can move. There isn’t a pricing tier determining whether I’m allowed another locale or another editor. I’m not paying for the privilege of keeping a project editable inside the tool that created it.
Obviously infrastructure can cost money as a website scales. Code isn’t magical free hosting.
But for the kind of personal and carefully built websites I’m talking about here, the cost can be remarkably close to zero.
Learning code made me better at no-code
There’s another benefit I didn’t really expect. Learning to build with actual code made me better at using tools like Framer too.
Once you understand HTML, CSS and JavaScript properly, a lot of concepts inside visual development tools stop feeling like arbitrary controls in an interface. You understand why a layout behaves the way it does. Flexbox and grid make more sense. Breakpoints make more sense. Relative and absolute positioning make more sense. You start thinking about reusable components, inheritance, states and responsive behaviour differently.
Even performance decisions become easier to reason about because you have a better idea of what the browser is actually being asked to do. And when you do need to write a custom component inside Framer, you’re obviously in a much better position to do it.
So strangely, moving away from Framer for a lot of my own work hasn’t made Framer less useful to me.
It’s made me better at using it.
The difference is that I now understand more of what the visual interface is abstracting away. I think that’s another reason designers shouldn’t see learning code as choosing between code and no-code.
Learning code doesn’t take no-code tools away from you. It makes them more powerful.
I still use Framer and I would still recommend it.
In fact, there is one area where I’d choose Framer over Vue without much hesitation: Client handoff.
Handing someone a Framer project and showing them how to change some copy, replace an image or manage a page is easy. Handing them a Git repository and explaining Node isn’t.
Framer is also exceptionally good when the objective is to get a well-designed marketing website from design to production quickly. Not every website needs a custom architecture. Not every button needs to become an engineering problem.
Sometimes Framer is simply the better tool.
But for one-off builds, personal sites, portfolios, experiments and digital experiences where every detail has been made with care and intent, I don’t think I want to go back.
For that kind of work, Vue has given me something Framer increasingly couldn’t: Room.
Room to make something unnecessarily complicated.
Room to optimize something nobody else will notice.
Room to make bad architectural decisions and learn why they’re bad.
Room to build an interaction exactly the way I imagined it.
Room to understand what my website is actually doing.
And room to get considerably better at building for the web.
So, should you switch too?
Yes but not necessarily. Honestly, it's not an easy answer but choosing based on multiple options is always better.
If Framer does everything you want, keep using Framer.
It’s good. Pricing , maybe not.
But if you’re a designer who has started accumulating custom components, working around platform limitations, worrying about performance, watching your subscription grow and constantly wondering whether the next idea is actually possible inside the editor, I think it’s worth paying attention to that feeling.
You might have reached the point I did.
The first website will take longer.
You’ll probably break things that Framer would never have allowed you to break. You’ll relearn things you thought you already understood. And you’ll occasionally spend an unreasonable amount of time fixing something that would have taken thirty seconds in a visual editor.
But eventually something changes.
You stop learning how to operate the tool and start learning how the web actually works.
For me, that trade was worth it.