[{"_1":2,"_50":-5,"_51":-5},"loaderData",{"_3":4,"_7":8,"_48":-5,"_49":-5},"routes/_layout",{"_5":6},"isAuthed",false,"routes/_layout.blog._index",{"_9":10},"articles",[11,27,34,41],{"_12":13,"_14":15,"_16":17,"_18":19,"_20":6,"_21":22,"_23":24,"_25":26},"title","Why I left Next.js in the dust","summary","My personal journey through the world of React metaframeworks.","createdAt",["D",1734220800000],"author","Ryan Hopper-Lowe","draft","ids",[],"id","remix-over-nextjs","content","\n# Why I left Next.js in the dust\n\n6 months ago, if you were to ask me what to use for a new project, 9 times out of 10 I would have recommended Next.js. I've been using Next both personally and professionally since the major crash of Sillicon Valley Bank in early 2023 (a story for another time). For me at the time, the concept of colocating backend and frontend code was a total game changer, and (being a huge TypeScript nut) full stack typesafety felt like a dream come true. I mostly used the Pages Router (at work) and dabbled in the App Router for most of my web-based personal projects and I have to say, I was very happy with the experience.\n\n### So what changed?\n\nI wanted to love the App Router (I really did), but for whatever reason, I just couldn't get there. Since the first time Dan Abramov showcased the `\"use client\"`/`\"use server\"`([link here](https://www.youtube.com/watch?v=zMf_xeGPn6s)) directives, they felt a little hacky to me. I'm not sure if it was the fact that I was used to the simplicity of the Pages Router, or the idea of having to manually manage the client/server split, but I just couldn't get used to the dance between client state and server state. This was compounded by the not-so-subtle push towards server components. If you don't specify a client component, it runs on the server. However it will be converted into a client component when imported into another client component with no errors or warnings (...????). I felt like I had to re-learn everything I had spent the past four years learning about React.\n\nAnother thing that felt off here was my familiarity with api caching libraries like `react-query` and `swr`. I've been using these libraries for years and I still think they provide the best UX/DX for managing server state on the client. I love the Stale-While-Revalidating (SWR) pattern in general (more on that in a future post), and I just couldn't replicate that experience in Next.js. If I'm being honest, the more I used it the closer I felt to finding the right patters, but it felt like there was way too much room for error and I wasn't satisfied with how much trial and error it took to find those patterns.\n\n### Enter Remix\n\nAs usual I joined the party late with Remix, finally giving it a try in mid-2024, and right away I could tell it was what I had been looking for. I loved the simplicity of it: loaders load data and pre-render the page, actions handle mutations and retrigger loaders after completion. Everything else is is just React the way it was meant to be. The thing that mad Remix feel so right was that it comes with all of the opinions baked right into the framework. After reading the documnetation I felt like I was able to handle the most complex of problems with the simplest of solutions without having to spend hours of trial and error to get there on my own. They didn't push me towards the server by changing the rules out from under me, but they DID provide the tools and documentation to do so in a way that felt natural. The Route module is extremely powerful and they provide a ton of useful utilities to give your app the reactivity it needs while still operating exactly as you'd want it to with JavaScript disabled.\n\nGoing back to the SWR pattern, you can 100% accomplish the same effect with Remix's `useFetcher` hook. The best part is that it's built into the framework and you don't have to worry about breaking SSR or displaying loading states. (I even gave a talk about this at a Remix meetup in Austin! [link here](https://www.youtube.com/watch?v=pkcqumHpL8w))\n\n### Conclusion\n\nI'm not saying that Next.js is a bad framework by any means! If I were building a static website that needed some serious SEO, I would most likely still reach for it. However, applications are rarely fortunate enough to remain static, and SEO can be handled just as nicely with Remix. I'm also not saying that Remix is perfect: it leaves a lot to be desired in terms of typesafety within it's router, and I'm not a huge fan of only having 1 action per route (even if it pushes me towards better practices and logically nested routes) and having to manually differentiate the intents of different forms. That being said, the simplicity and intention behind each feature of Remix makes it a breeze to learn and an absolute joy to use. I've convinced my current employer to give it a try and we're loving every minute of it. I don't know that it will be the end-all be-all framework, but as of right now, I'm not going anywhere else.\n",{"_12":28,"_14":29,"_16":30,"_18":19,"_20":6,"_21":31,"_23":32,"_25":33},"You're using useRef wrong","Some fun facts about the useRef hook in React.",["D",1734480000000],[],"use-ref-wrong","\n# You're using useRef wrong!\n\n## Introduction\n\nWith the upcoming release of the [React compiler](https://react.dev/learn/react-compiler), the React team released a new set of linter rules that must be satisfied in order for it to work.\nAs someone who absolutely HATES the monotonous task of memoization and render optimization, I was very excited to start the process.\nWe've been pretty strict at following the [rules of react](https://react.dev/reference/rules) hooks, so there weren't too many issues to fix.\nWe weren't perfect though, and I noticed 2 common errors that would break the compiler:\n\n1. There were several instances where we had disabled the `exhaustive-deps` rule. (born purely out of laziness, and time constraints)\n2. (A bit more shockingly) There were a slew of red squiggles related to the `useRef` hook.\n\nNow I pride myself on being pretty knowledgeable about the [rules of react](https://react.dev/reference/rules) (even if I don't always follow them), so initially I was a bit confused. That confusion, however led me to do some soul searching and allowed me to completely rethink the way I used refs in my code!\n\n## Let's start with the basics\n\n### What is `useRef` ([docs here](https://react.dev/reference/react/useRef))?\n\n`useRef` essentially provides a component with a way to store a value that is not used for rendering.\nThis exempts it from some rules related to dependencies and memoization, but it also comes with some caveats.\n\n### The Caveat: do not use a ref value during rendering.\n\nMost tutorials will tell you not to do this:\n\n```tsx\nconst Component = () => {\n const ref = useRef(\"some value\"); // ref is assigned\n ...\n return

{ref.current}

; // access ref.current during rendering (no-no)\n};\n```\n\nand this would make sense! Since `ref` is not used for rendering, it won't trigger a re-render when the `.current` property is changed.\n\n**This is where most tutorials stop**.\n\nGoing a bit deeper, a common misconception is that \"rendering\" only happens anywhere there is JSX. That's not true! Here's another example of accessing a ref during rendering:\n\n```tsx\nconst Component = () => {\n const ref = useRef(10);\n\n const doubled = ref.current * 2; // also bad!\n\n return

{doubled}

;\n};\n```\n\nand here's another\n\n```tsx\nconst Component = () => {\n const ref = useRef(10);\n\n useHookThatUsesRefValue(ref.current); // sorry, still BAD!\n\n return

No Ref here!

;\n};\n```\n\nAnd here's the one I see the most (usually in my own code):\n\n```tsx\nconst Component = () => {\n const ref = useRef(null);\n\n return (\n <>\n

My Anchor Element

\n\n \n \n );\n};\n```\n\nNow I know what you're thinking...\n\n**\"How the hell do I get my ref value into my custom component without breaking the compiler??\"**\n\nWell you've got a couple of options, but here's the one that's worked best for me:\n\n### The Solution: You might not need a ref 🤯\n\nRefs are great for storing values outside of rendering... but the second you pass the `current` value as a prop to a component, you're inherently telling React that the value IS used for rendering. This is because React uses the props of a component to determine if it should re-render (the same reason why refs can't be used in dependency arrays).\n\n**\"Ok so how do I store the node for an HTMLElement?\" (I asked myself this too)**\n\n#### The answer? Ref Init functions!\n\nDid you know you can pass a function to a component's `ref` prop? I didn't until recently, and it's a game changer. Take this code for example:\n\n```tsx\nconst Component = () => {\n const ref = useRef(null);\n\n return (\n {\n ref.current = node;\n }}\n />\n );\n};\n```\n\nbeleive it or not, this is actually what React is doing under the hood when you pass a ref to a component!\n\nSo now when we want to store the node and pass it to ANOTHER component, we can just replace `useRef` with `useState` and an init function!\n\n```tsx\nconst Component = () => {\n // because we're using a state, we can use this anywhere in our component where rendering is happening\n const [anchorElement, setAnchorElement] = useState(null);\n\n useHookThatUsesRefValue(anchorElement); // this is fine because it's a state value\n\n useEffect(() => {\n console.log(anchorElement);\n }, [anchorElement]); // this value can now be used as a dependency\n\n return <>\n

{\n setAnchorElement(node);\n }}\n >\n My Anchor Element\n

\n\n \n \n );\n};\n```\n\nThis is a much more flexible solution, and now your component can be optimized by the compiler!\n\n**\"But what if I still need to access the ref value from `useEffect` without passing it as a dependency?\"**\n\nSometimes we need to access a value in `useEffect` without passing it as a dependency. This is where useRef can still be handy. But that's also why init functions are so great!\n\n```tsx\nconst Component = () => {\n // state variable to be used during rendering\n const [anchorElement, _setAnchorElement] = useState(null);\n\n // ref to be used outside of rendering\n const anchorRef = useRef(null);\n\n const setAnchorElement = useCallback((node: HTMLElement | null) => {\n // we can set both the state and ref and pass this function to the div's ref prop\n _setAnchorElement(node);\n anchorRef.current = node;\n }, []);\n\n\n return <>\n

My Anchor Element

\n\n \n \n );\n};\n```\n\nAs you can see, we now get the best of both worlds! We can use the ref value in `useEffect` without passing it as a dependency, and we can also use the state value in any part of our component where rendering occurs.\n\n## Conclusion\n\nRefs are great for storing values outside of rendering, but they can be tricky to use correctly.\nBy using init functions and state, we can create a more flexible and optimized solution that satisfies the compiler's rules.\n\nI hope this helps you understand how to use refs more effectively in your React code. Happy Compiling!\n",{"_12":35,"_14":36,"_16":37,"_18":19,"_20":6,"_21":38,"_23":39,"_25":40},"You probably never needed Zustand","A look at why React state management libraries are a waste of time.",["D",1736380800000],[],"ditch-state-management","\n# You probably never needed Zustand\n\nTLDR;\n\n> My main problem with libraries like Redux, and Zustand is that they often times get reached for long before the complexity rises to the point where they're needed. 95% of the time, you should be able to solve your issues with simpler methods.\n\nFor years, I used to swear by state management. Along with most of the React community, I thought of it as the silver bullet I could use to solve all of my problems. I've since changed my tune. After years of using them (Redux, Zustand, MobX, Jotai, Context API, and more), I've come to the conclusion that they're (mostly) a waste of my time as a developer.\n\n## What is state management?\n\nFor those of you who are newer to React, state management libraries are not far off from how they sound. If you've ever used the Context API, you've already used state management. I won't go into the details of how it works, but if you're interested, you can read more about it [here](https://react.dev/reference/react/createContext).\n\n### So why do we use state management in the first place?\n\nFirst and foremost, it's super convenient. One of the most tedious parts of building with react is prop drilling, and state management gives you an easy way to drill state down to components without having to pass props through multiple levels. It's a great high. But like most drugs, it comes with a cost.\n\nAnother benefit is that it can improve performance quite a bit, by making it easier to memoize data and functions within the central store. On top of this, it provides a great place to quarantine expensive operations and and provide a single source of truth for your data.\n\n## Why you don't need your state management library...\n\nAnytime you introduce a new tool into your codebase, you're adding complexity. That's just the way it works. This is not always a bad thing, but you'd be hard pressed to convince me that your state management library is worth the complexity it adds.\n\nWhy do I say this?\n\n_Because it's probably not the only state management tool in your codebase._\n\nThe thing about state management is that **everyone** uses it. Expecially the people who are building the tools you use everyday.\n\n- Are you using `react-hook-form`? Boom, state management.\n- Maybe you're using `@tanstack/react-query`? Also state management.\n- How about `react-router`? Again, state management.\n\nLet's take it up a notch... Are you using url query params? How about local storage? Cookies? Session storage?\nYou may not have guessed it, but these are all forms of state management.\n\nState management is already everywhere. My question here is do you really need **MORE**?\n\n### Let me tell you a story\n\nAt my previous company, I was on the frontend team for a Logistics based CRM.\nThe primary feature of this crm was the ability to effectively display and interact with a series of complex grids (each with hundreds of thousands of rows) which included server side pagination, sorting, and filtering.\nEvery piece of client state was managed by Zustand stores. And when I say every piece of state, I mean everything:\n\n- api state\n- form state\n- auth state\n- just about anything more complex than a `useState` hook.\n\nInitially, I loved it.\nThe api was simple, TypeScript was good, and I was able to get some GREAT render optimizations.\nAs we were developing this application though, we started naturally noticing some areas for improvement...\n\n- First, managing api state got tedious, and we found adding `@tanstack/react-query` allowed us to manage it way better while boosting performance, and cutting down on code. **So we migrated some state to `react-query`.**\n- Also, we wanted a more streamlined way to perform form validation. Turns out it was simpler to just use `react-hook-form` with `yup` than a zustand store. **So we migrated some form state to `react-hook-form`.**\n- Then we noticed we could cut out a lot of code by ditching our auth store and just storing our session in a cookie. **Another migration.**\n- Then the brokers started complaining that they couldn't share their searches with each other, so we replaced our grid stores with query params. **You can probably see where this is going.**\n\nSuddenly, there were wasn't a single zustand store anywhere in our codebase.\n\nIt was almost an erie feeling, but I soon realized how much healthier the code was.\nWhat's crazy is that we had removed THOUSANDS of lines of code in the process, and our codebase was 10x easier to maintain and 100x easier to read.\nThe truth of the matter is that we were leaning on a single tool to manage all forms of state, often ignoring the **right tool for the job** out of convenience.\nWhen everything was in a zustand store, the lines so easily got blurred and it became hard to discern one type of state from another.\nThere was truly no separation of concerns.\nNot only that, but every component had access to all state at every level to the point where you couldn't trigger a single event without affecting several other parts of the app. Reusing a component at this point was a pipe dream.\n\nIf you have been in the ecosystem long enough, you'll know that the best components are the **dumbest** components, and state management libraries often provide the perfect breeding ground for extremely smart, impure, and **dangerous** components.\n\n## The alternative\n\nYou can still use state management, but it's important to make sure it's solving a **specific** problem. Don't just bring it in because you think it'll make your life easier. Here are some examples of how you can solve **real** problems by using the right tool for the job.\n\n### 1. Api State\n\nUse something like `@tanstack/react-query` to manage your api state. Out of the box it will likely solve about 90% (if not all) of your global state problems. It combines the best parts of a state management library with api caching to make sure your data is always synced with the server. I can't recommend this enough.\n\n### 2. Form State\n\nFor the most part, form state can be ignored completely if you're able to implement validation on the server. If you need client side form state, `react-hook-form` and `zod` provide a fantastic way of managing **complex** form state on the client, but I'd argue you probably don't need it every time.\n\n### 3. Persistent State\n\nFor persistent state, I tend to mostly reach for URL query params. They're extremely easy to use, inherently accessible anywhere in your app, they persist between page loads, are navigable through browser history, and they can be saved as bookmarks and shared between users. This should be the go-to for all things filtering, sorting, pagination, and anything else that needs to be persisted.\n\nIn the case where persistent data needs to be more complex (as long as it doesn't need to be sharable between users), you can then reach for things like local storage or cookies (but I rarely have to go here).\n\n### 4. Auth State\n\nJust store it in a damn cookie and call it a day 🤦.\n\n## Brass tacks\n\nNow I understand that some problems are inherently more complex than others, and there are absolutely times where that catch-all state management library can be a godsend (Especially when render performance is a concern). Additionally, I think tools like this can drastically increase the velocity of development, and if you're goal is to get a product out the door, it can be extremely helpful.\n\n...\n\n...\n\n...\n\nBUT!!!\n\nI also think that you should be careful about how hard you lean on it. Very few problems are actually complex enough to warrant a state management library, and the consequences can far outweigh the benefits in most codebases.\nOnce you add a single Redux store, you'll be amazed at how fast it begins to replicate and infect the rest of your codebase. And it's not easy to remove.\n\nFor you and me, it's probably not that big of a deal. After all, perfect 10x engineers like us know how to manage such complexity while still following best practices. The issue here is that no matter how great you may be, patterns like this do not scale to bigger teams where experience and opinions are not uniform.\n\nWhenever you use a tool that is unopinionated in nature, you are forced to apply **your own opinions** to solve the problem. 99% of developers will not be able to intuit your thought process and continue in the same direction. Expecting them to is a bad idea.\n\nThis article isn't a smear campaign against all state management, but it is a warning to think twice before pulling in another state management library.\n",{"_12":42,"_14":43,"_16":44,"_18":19,"_20":6,"_21":45,"_23":46,"_25":47},"I might be ditching React 🤯","My take on a newer framework",["D",1740614400000],[],"i-tried-svelte","\n# I might be ditching React 🤯\n\nThe past year for me has been a whirlwind of learning. For the first 3.5 years of my career, all I knew was SPAs built in React. Fast forward to a year and a half ago, I was introduced to fullstack react frameworks like Next.js, then a few months later, I was introduced to Remix and I thought I had learned all there was to know. Then I found Svelte. Now a mere 2 months into my Svelte journey, I think I might be a convert.\n\n## Why I tried Svelte\n\nThe company I work for now is a small startup run by mostly cloud developers (specializing in Go). We maintain 2 Frontends, the one I own and maintain is built in React/React-Router, and the other one was built primarily by a backend developer who hates React with every fiber of his being. Ditching any notion of a shared codebase, he went a completely different direction and built his UI in Svelte. At the time I thought this was a horrible idea. 2 Frontends in 2 different stacks sounded like a nightmare in terms of design synergy and maintenance. To be honest, I still agree with that sentiment. The only difference is now I think I'd rather switch my frontend to Svelte than the other way around.\n\n## The problems with React\n\nI've been working with React for over 5 years total, and I'm realizing how much I've started taking my experience for granted. Over the years, I've started becoming frustrated with the lack of proficiency in the React ecosystem, often times adding extreme safeguards to my code to prevent other developers (and myself) from breaking the logic. For a long time, I attributed that to the idea that most JavaScript developers just tend to suck at what they do. (of course, I'm not saying I'm not one of them)\n\nI'm starting to think that React is just hard.\n\n### What's hard about React?\n\nThe first thing that comes to mind here is the sheer amount of framework knowledge you need to have to be productive without shooting yourself in the foot. Here's a far from comprehensive list of things that I've had to learn to produce high quality, performant, and maintainable React code:\n\n- The Component lifecycle (because you need to know why your app is rerendering)\n- Rules of Hooks (because useEffect is a bitch)\n- Context API (because prop drilling sucks)\n- Redux (because Context API is boring)\n- React Router (because no one knows how client side routing works)\n- React Query (for high volume data fetching)\n- Next.js or Remix (because SPAs are lame now)\n- Suspense (because loading states shouldn't be managed by state...?)\n- Server Components (because why learn one framework when you can learn 2?)\n- React Hook Form (forms were too easy... so we made them hard)\n- 100+ Component libraries (because we forgot how a button works)\n- ShadCN (Because component libraries suck, but accessibility is hard) (I actually really like ShadCN)\n- Imutable state\n- Pure functions\n- memoization\n\nI could go on, but I think you get the point.\n\nOne thing that you might notice there is a lot of the stuff on that list arent even related to React as a framework. That's because react is difficult enough that we need to rely on external libraries to abstract away the complexity. The result of this is that you have to learn a new library for every new problem you encounter. It also creates a lot of learned helplessness in the developer community (a large reason the React pool gets such a bad rap).\n\nI'm not saying React is a bad framework, but it's hard to justify the complexity of the framework when there are so manny other simpler frameworks.\n\n### Problems with React Metaframeworks\n\nI won't go into too much detail here. I have another article detailing the my problems with Next.js which you can read [here](/blog/1).\n\n#### Problems with Next.js\n\n- Super weird dance between client and server logic (\"use server\", \"use client\", is weird)\n- SUPER annoying file based routing conventions. I'm sure I could udpate my searching process, but I always get tripped up when I search for `page` in vscode and I'm prompted with a list of 35 `page.tsx` files and I don't know which one I'm looking for.\n- Default caching mechanisms were a NIGHTMARE (before Next.js 15)\n\nI spent a while trying to figure out how to make Next.js work for me, but I just couldn't get over the mental overhead of the framework. So I switched to Remix.\n\n#### Problems with Remix\n\nOverall MUCH better experience than Next.js (in my humble opinion). But just not quite there in a few areas.\n\nMy biggest gripe is typesafety. They have a lot of workarounds in their API, but it's a lot of subtle typecasting that leaves a lot to be desired for a TypeScript nut like me. Also, you can only have 1 action per route, which means you have to do a lot of conditional logic to determine the \"intent\" of a form submission. (this gets tedious when you have pages capable of lots of different actions)\n\nThat's really it in terms of major issues with Remix/React Router as a framework. Overall I love the vision and I think it's the best option by a landslide in the React ecosystem. But let's move on to the real reason we're here.\n\n## What's so great about Svelte?\n\nSvelte is a framework that is built on the idea that the framework should be as simple as possible. It really shines a light on how powerful raw HTML, CSS, and JavaScript can be (something I've been extremely reluctant to learn throughout my career).\n\n### Svelte is simple\n\nThey don't try to reinvent the wheel. They essentially took the same raw DOM apis that have ruled the web since the beginning of time, and threw in a few new concepts to make reactivity easier. The cool thing now is that with the introduction of runes in Svelte 5, the bridge from React to Svelte is actually SUPER manageable.\n\nThe fun thing about the simplicity of Svelte is that it allows it to be FAST. I haven't done anything too crazy, but I've noticed that I've never once had to worry about performance. Even when rendering huge lists of complex information, Svelte is able to keep up with just about anything I've thrown at it.\n\n#### Performance aside, my favorite part of Svelte is the list of things I DON'T have to worry about.\n\nVirtual DOM? Nope. Components are compiled directly to DOM nodes so any change you make has a direct impact on what the user sees.\n\nMemoization? What's that? Component code is only run once, when the component is mounted, from there on Svelte just watches for changes in stateful variables and updates the DOM accordingly. This means that you don't have to worry about optimizing rerenders because Svelte is already doing it for you!\n\nImmutable state? Gone! Svelte watches for changes in state so you can just mutate it directly. This is actually a much bigger win than it sounds becuase it means that you can program exactly the same way you would in any other environment. It removes a ton of mental overhead and allows you to focus on the problem instead of the framework.\n\nAnother big win is Svelte gives you global state for free! Much like signals in Solid, Svelte runes are not subject to the same tyranny as React hooks. They can exist anywhere inside or outside of a component. As a result you get free global state without having to pull in one of 300 libraries to manage it. Now you can treat your global state the exact same way you would treat component state (which is exactly how you would treat any variable in any other non-frontend environment).\n\nAt the end of the day, it just feels like you're writing JavaScript (which turns out not to be all that bad).\n\nI think the coolest thing about this simplicity is that it allows people to become productive without having to be a senior level engineer. As I mentioned I work with mostly cloud developers, and I've seen that they are very productive in the Svelte codebase, and refuse to touch the React codebase with a 10ft pole. Keep in mind, that most of them have worked with React FAR more than they have with Svelte.\n\nAnd don't even get me started on the builtin animation support! I won't go into it too much, but I've been able to create some extremely powerful, smooth animations in half the code with NO external libraries whatsoever. That alone is a game changer.\n\nThe list here goes on and on, but in the interest of time, let's get to the next thing.\n\n### Let's talk about SvelteKit\n\nIt wouldn't be a modern discussion of JavaScript frameworks if I didn't mention the Metaframeworks. And I feel like SvelteKit is everything I love about Remix, with none of the crap I hate about React. To be fair, it does have the same gross file based routing conventions as Next.js, but I'm willing to overlook that for the joy of working with Svelte.\n\nOne thing I love about sveltekit is how much inspiration it obviously took from Remix. The api is very similar. Loaders load data and pass it to the page as props, actions handle form submissions, and you can even have multiple actions per page (a subtle but very important distinction in my opinion). Additionally, SvelteKit supports Restful api routes just like Next.js Route handlers or Remix's resource routes enabling you to build a REST API alongside your frontend.\n\nOn top of that, their compiler works wonders with typesafety between the server and client code. I've found that I am writing around 50-60% fewer types in my SvelteKit codebase than I would in any of the other frameworks I've used.\n\nWhat's crazy here is that between the server side abstractions, and Svelte actions (which deserve their own article entirely), I've found myself writing wayyy fewer Components than I ever had before. It's a weird realization, that I DON'T need to abstract away so much. The bottom line is that I'm able to write some shared logic and behaviors, but the actual UI is mostly just raw HTML with a few svelty bits sprinkled in.\n\n## Conclusion\n\nA few years ago I would have told you React is the standard, and it always will be. Now I'm realizing it's starting to feel more comparable to the Java of the frontend world. Previously I would have given a much more modern sentiment. It's still extremely relevant and I'd imagine it will be for the next 20 years (much like Java), but I no longer think it is the best framework out there. I've only been working with Svelte for about a couple of months now, but I've found that I'm feeling more productive than I have in a long time. We'll see if it sticks, but as of right now I'm all in!\n","root","routes/_layout.blog","actionData","errors"]

Articles

Why I left Next.js in the dust

You're using useRef wrong

You probably never needed Zustand

I might be ditching React 🤯