Frontend & Backend Blur

3.20.24

I started to write a blog post about the JavaScript framework Astro. I still might, Astro is very cool. It has very recently become an official full-stack framework since they launched AstroDB, which is a fully managed SQL database. At first, this might sound a little weird coming from a framework that seemed to boast a bare bones ethos. Astro claims to be a content driven web framework and can strip away all of the JavaScript from the final build of a website, even if you choose to build it with React, for performance and SEO. In Astro’s attempt to allow devs to build anything, AstroDB seems to be a very welcomed feature to the ecosystem, but this is another example of a point I see raised pretty often in both positive and negative contexts; that in web development, there is no such thing as a “frontend developer” anymore.

Every now and then I’ll see a thread pop up on a web dev subreddit where somebody has been a frontend dev for a long time and either out of necessity or curiosity will explore the modern frontend world outside of vanilla HTML, CSS, JS (and usually PHP) and will be overwhelmed by how much more frontend devs are expected to handle compared to say ten years ago. One of the first hurdles I notice, especially in the React world, is state management.

Application state essentially serves as the foundation for dynamic content in UIs. The state is responsible for interactive elements that respond to user inputs, real-time data updates, and other asynchronous events. As applications grow in complexity, managing state can become crucial for having both a smooth UI and honestly, a smooth developer experience. Almost three years ago, I wrote a blog post on Redux, which at the time was the defacto industry standard for state management in React apps. The blog post is still relevant, the only thing that has changed is the fact that Redux is not the default go-to library anymore. Some newer and exciting options have popped up over the last few years including Jotai, Recoil, the native Context API, and my personal favorite Zustand. No matter which state management tool you go with, you will have to balance the pros and cons of the different libraries with the syntax of actually coding with these different tools. This also means understanding component state lifecycles and data flow which means having an architectural mindset that was traditionally reserved for backend development.

Sticking with React, which is where most of my professional experience and personal preferences lie, there has also been a pretty significant shift in the last few years away from client side SPA’s to full-stack frameworks like Remix and Next.js. Remix is a full fledged React full-stack framework (now owned by Shopify btw) with templates that come with all the bells and whistles of a Postgres database, authentication, testing and more with the ability to render React components either in the client or on the server. Next.js is a little different… it is a full-stack framework… but it’s also not, but kind of is, or kind of can be. Next.js is a little more nuanced and one of the features that has made Next.js so important and a little ambiguous in qualifying it as a full-stack framework is its serverless API routes. The Next.js serverless API routes essentially give you the power and serverless architecture of something like AWS Lambda right in your frontend; which for many use cases, lets you move away from the need for a traditional backend. Does that make Next.js full-stack, it’s debatable, however, installing an ORM like Prisma to a Next.js project to directly communicate with a database definitely does.

If you are using Remix, Astro or Next, you also have to understand the difference between writing client-side and server-side code and how it impacts hydration. The most recent version of Next.js has actually made it a server-side first framework, which is a little strange for a JavaScript framework. JavaScript has traditionally been a client-side scripting language for a really long time. Now, if you are creating a component that does not require server actions, you have to explicitly tell Next to “use client”. Fully server-side React code definitely has some cool advantages that include SEO and initial load times but for a lot of dynamic interactions that don’t require a fresh page from the server, client-side rendering can make the UI feel more responsive and fluid.

At first glance, these full-stack frontend frameworks, such as Next.js, might seem like they're retracing steps back to the more traditional full-stack frameworks like Django for Python and Laravel for PHP. However, Django and Laravel both follow server-centric MVC (Model View Controller) architecture where Next.js does not. Beyond simply enabling the use of React for the frontend, Next.js introduces a level of flexibility that proves to be pretty advantageous, not only in terms of the developer experience but also for developing scalable, microservice oriented applications with a more modular approach. They also play great together, you don’t have to choose or sacrifice using tried and true Django or Laravel as your backend to use Next.js on the frontend. In fact, using Next.js as the frontend framework with a traditional backend is still very common and super powerful.

Whether you are working on a traditional agile team of cross-functional frontend and backend devs, or a general web dev hobbyist, chances are you will have to dip your toes in tasks across the entire stack. For this very blog post, I had to recently migrate from an old database and created and provisioned a new Postgres database with a Node.js application serving API routes to display this in my website which is a Next.js application. These posts are also server-side for SEO and speed. That definitely sounds a little beyond traditional frontend to me. I’m not posing all of this to say that frontend is better or harder than traditional backend development, it’s actually the opposite. I love both and think those who love this stuff will inevitably be drawn to both. Being a full-stack developer means you can build anything, which is why I learned how to code in the first place. I’m psyched to see what the next several years look like for all of these awesome tools. Maybe I’ll even write that post on Astro.