title: You probably don’t need that hip web framework
url: https://char.gd/blog/2019/you-dont-need-that-hipster-web-framework
hash_url: 0c2fa2dc32036c32f5d8f3e658522f82

<div class="post-content" itemprop="articleBody">
<p>Every year, there's something new to learn and play with in the web development world that's considered something you <em>must </em>use: React, Vue, GraphQL, Docker, whatever it might be. And, every year I mess around with these new things and find myself stuck, regretting even trying to use them when I could have just <em>launched </em>something. </p>
<p>The obsession with finding better frameworks is killing ideas before they reach the world, and nobody's really talking about it.</p>
<h4>Modern web, dependency hell</h4>
<p>In 2018, I spent most of my time tinkering with new ideas and trying to launch a handful of web-based products. I went public with <a href="https://char.gd/recharged">reCharged</a> in early 2018, and toward the end of the year I launched <a href="https://writetogether.space">Write Together</a>—both based on PHP frameworks with templating engines<strong>—</strong>but in the middle I found myself lost in a sea of frameworks, never really shipping anything, starting over and over again.</p>
<p>Perhaps it was reading too much Hacker News, or simply seeing these famous developers from Facebook and Google using it... but I wanted the latest and greatest in web technology, or at least something that felt more 'modern.' </p>
<p>So, I experimented with the ones that seemed relevant: I tried Vue, React, GraphQL, Docker, and so many more different tools. Instead of becoming more productive, I ended up in an endless learning loop paired with dependency hell, rebuilding logic that's been provided for free in more mature language for years. </p>
<p>What I've come to realize over the last few months is that <strong>your first version of your idea almost always doesn't need that hipster web framework you're thinking about using</strong>. </p>
<p>If you're building a new idea, you want to get it to market as fast as you can, so the absolute best thing you can do is ignore all of these new fads, frameworks, and fancy patterns—instead just using <em>whatever works </em>to ship a first cut.</p>
<p>Every time I start a new side-project or product, I find myself pulled in by the allure of the shiny new tools only to end up spinning my wheels. I'll get tangled in some gotcha, or required <em>other thing </em>like VueX, Apollo, GraphQL, or whatever else, getting nothing in particular done outside but fighting the tool and the array of packages that come with it. </p>
<p>This has always been the case on the web, but I don't remember it ever feeling this awful. Usually I'd start a new project by scaffolding out a blank Laravel template or a new Rails site and building out with the included templating language, but in the development community that seems to be considered incredibly old-school.</p>
<p>But, when I started on my work to rebuild reCharged into an 'app' rather than a custom-rolled solution, it felt like I was missing out on <em>something </em>by not building an all-React app or going head-first into a Vue SPA, so I'd try the 'modern' way.</p>
<p>Essentially, I wanted to build a 'productized' version of the tooling I had already created for myself. It allows creators to easily spin up a subscription newsletter or community with their own Stripe accounts—I had proved the model was interesting with reCharged, and wanted to help others do the same.</p>
<p>Not wanting to bet on the wrong horse, I chose Vue as my framework of choice, as a single-page app. I went away and built a RESTful back-end, with a Vue SPA that made it all seem snappy and futuristic... but it's unbelievable how complicated it was to get to a point where I could put a MVP into the world. </p>
<p>Passing data back and forth between the backend and my SPA was a recurring hellscape. Basic routing became an exercise in futility, duplicating the logic needed to render a single view into insanity. I spent more time trying to figure out how to properly deal with state than actually building my app. Ever tried to do server-side rendering if you're using anything other than Node? Good luck.</p>
<p>I don't even think I really needed a SPA. The site was fast, when it worked, but it was just a bunch of pages of content. I probably picked the wrong thing, but it seemed like everyone was doing it, and there were a bunch of reasons <em>not </em>to build the old way.</p>
<h3>Growing weary</h3>
<p>I grew so frustrated with Vue, and building a SPA, that my interest in the project completely waned, so it stagnated for months. I had figured I was a decent, multi-disciplinary developer since I could build a full PHP back-end, wire up the HTML, Javascript, and CSS on my own, and launch a product, but I felt defeated by how overwhelming it all was.</p>
<p>Since then, I've discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there's something we should be doing better. The web is incredible these days, but I'm not sure every app needs to be a React-based single-page application, because the complexity is so great in a product's infancy.</p>
<p>These SPA tools are incredible, and fun to use, but unless you're a crack team of developers, have a bunch of financing to blow, or just time to spare, it's <em>really </em>difficult to maintain them without scale. </p>
<p>Almost always, I'm finding that the tightly-coupled back-ends that ship with a templating language, like <a href="https://laravel.com">Laravel</a> (which is a delight, by the way) or Ruby on Rails, have put so much thought into the tooling experience that they get out of the way—generate a controller at the command line and pass some data into a view, that's it. </p>
<p>In the Javascript ecosystem, that doesn't <em>really</em> exist and we're all falling over our own feet constantly. In our quest for something more modern, we've created a mess of developer tooling and ruined the experience of just shooting the shit on a new idea. </p>
<p>I've gone back to the tried and true ways of building my own products, for now. I still use Vue, but instead of introducing the complexity a SPA, I'm building with single-file components. Write Together renders Vue's bits <em>inside </em>the Blade template, which loads fast while delivering the flexibility of things like Vue's great event system.</p><p>It's a compromise, but one that almost always seems to be better; I'm able to deliver the benefits of Vue <em>without </em>the witchcraft involved in full server-side rendering of a SPA, or the complexity of adding a routing and state management layer.</p>
<p>But, this has all made me wonder: has the modern stack killed experimentation, and shipping bad ideas? Do weird experiments and fun ideas die on the floor, tangled in complexity, more often now? I'd hazard a guess that the answer is yes, and that you should probably skip that hipster framework—for now—as well. Just ship something instead.</p>
</div>
