Tagged “webdevelopment”

1. [UPDATED!] Seamless Forms with shadcn/ui and TanStack Form

   felipestanzani@blog ~ ~ cat "[UPDATED!] Seamless Forms wi"~ cat post << 09-29-2025

   

   In my post, "Life after Next.js: A New and Sunny Start," I talked about my journey migrating to TanStack Start and the freedom it brought. One of the loose ends I mentioned was the form situation. I'm a big fan of the aesthetics and developer experience of shadcn/ui, but its default form component is built on react-hook-form. As I'm going all-in on the TanStack ecosystem, I naturally wanted to use TanStack Form.

   This presented a classic developer dilemma: do I stick with a component that doesn't quite fit my new stack, or do I build something better? The answer was obvious. I couldn't find a clean, existing solution that married the beauty of shadcn/ui with the power and type-safety of TanStack Form. So, I decided to build it myself.

   Today, I'm excited to share the result: a component that seamlessly integrates shadcn/ui with TanStack Form, preserving the core principles of both libraries. It's type-safe, easy to use, and maintains that clean shadcn/ui look and feel.

   You can check out the component's website and find the full source code on the GitHub repository.

   Why Bother?

   TanStack Form offers incredible power with its framework-agnostic, type-safe approach to form state management. shadcn/ui, on the other hand, provides beautiful, accessible, and unopinionated components. The goal was to get the best of both worlds without any compromises. This component acts as the bridge, giving you:

   • Full Type-Safety: Infer types directly from your validation schemas (like Zod, Valibot, etc.).
   • Seamless TanStack Integration: Leverage TanStack Form’s state management and validation logic.
   • Consistent shadcn/ui Styling: Use the form components you already know and love.

   Continue reading...

2. JavaScript 2025: New Stable Features to Boost Your Code

   felipestanzani@blog ~ ~ cat "JavaScript 2025: New Stable"~ cat post << 07-18-2025

   

   Hey there! JavaScript became 30 years old in 2025. Despite being created for browsers’ front-end code, it gained more space than expected in the backend. ECMAScript 2025 (ES16), released in June, brought a handful of stable features that make coding smoother without forcing you to kneel before the latest framework altar. In this post, I’ll walk you through the standout additions with practical examples, and for each, I’ll show how you’d do the same thing the old-school way — pre-ES2025. Spoiler: the new features save you some headaches, but the fundamentals still hold strong. Let’s dive in, no fluff, just code!

   1. Iterator Helpers: Functional Programming Without the Headache

   What’s New: Iterator Helpers introduce a global Iterator object that lets you chain operations like .map() and .filter() on any iterable (arrays, sets, generators) in a memory-efficient, lazy way. It’s functional programming without the bloat of intermediate arrays.

   Example with Iterator Helpers: Filtering and transforming a leaderboard of scores.

   //
   // Before
   //
   const scores = [100, 85, 90, 95, 70];
   const topScores = scores.filter((score) => score > 80).map((score) => `Score: ${score}%`);
   console.log(topScores); // ["Score: 100%", "Score: 85%", "Score: 90%", "Score: 95%"]*
   
   //
   // After ES2025
   //
   const scores = [100, 85, 90, 95, 70];
   const topScores = Iterator.from(scores)
   	.filter((score) => score > 80)
   	.map((score) => `Score: ${score}%`)
   	.toArray();
   console.log(topScores); // ["Score: 100%", "Score: 85%", "Score: 90%", "Score: 95%"]*
   

   Continue reading...

3. Life after Next.js: A New and Sunny Start

   felipestanzani@blog ~ ~ cat "Life after Next.js: A New an"~ cat post << 06-20-2025

   

   A few weeks ago, I posted about my decision to move away from Next.js and the reasons behind that choice. Since projects can't just halt, I couldn't dwell too long on my decision. I had to consider several requirements for my new stack, including:

   • Using React as the frontend library.
   • Support for Server-Side Rendering (SSR).
   • Server-side functions.
   • Middleware support.
   • Enough flexibility to integrate libraries like React-Hook-Form and Axios.
   • A caching mechanism independent of the REST library.

   Initially, I was torn between Remix and TanStack Start. However, Remix lacks middleware support, which would necessitate significant architectural changes and a less ideal way to manage route access. Furthermore, in recent weeks, the Remix project announced a substantial shift in direction for its V3 version. While this new direction appears very promising, it would eventually mean I'd have to rewrite everything again, and that's definitely not something I want.

   TanStack Start, on the other hand, is currently in beta. Yet, it meets all my project's requirements and is built on Vite, making the project far more flexible and independent. Beyond what I've already outlined, the TanStack libraries have an excellent reputation, and this point deserves a small digression:

   Utah probably isn't the first place you'd pick to catch a tan, but if your name is Tanner and you have a good sense of humor, you might just call your TypeScript library stack "TanStack." This textual detour is about him: Tanner Linsley is a programmer renowned for his profound commitment to the open-source community, developer experience, and type safety. TanStack libraries are used by hundreds of thousands of developers and adopted by everyone from startups to Fortune 500 giants. This alone lends significant credibility to TanStack Start, which, at least for me, weighs heavily in my decision for a long-term project.

   Getting back on track, despite its beta status, the development team is now focused on stabilizing the framework rather than building new features, so no breaking changes are expected anymore.

   Still, you might argue that adopting a beta framework for my project carries a high risk, and I agree. However, there are other valid points to consider for my project's current stage. As I've already explained, including in the previous post, going with a no-framework approach would demand a massive effort. Staying with Next.js under Vercel's grip was out of the question. This left me with Remix, which I've already discarded, and TanStack Start, which was my choice. And here's the unexpected upside for me: working with a beta framework also has its advantages.

   As soon as I ran into the first development hurdles, I was directed to the TanStack Discord server. There, numerous developers exchange information and answer questions about the libraries. The project's own developers actively respond to queries, report bugs, ask for new issues to be opened, etc. Even Jack Herrington is there, participating actively!

   Continue reading...

4. Don't Marry Next.js: My Warning from the Trenches

   felipestanzani@blog ~ ~ cat "Don't Marry Next.js: My Warn"~ cat post << 05-27-2025

   

   Choosing the right development stack is a thoughtful decision. While selecting the right stack might not offer immediate, tangible benefits, picking the wrong one can lead to significant challenges. I learned this the hard way, and my advice is clear: don't marry Next.js.

   My initial foray into Next.js, a proof of concept, failed miserably. Though I had some React experience, I was still searching for the ideal frontend framework. I explored Svelte, but was put off by .svelte file extensions, the need to explicitly declare lang="ts" in every TypeScript block, and the co-mingling of TS and HTML in the same file. The ongoing transition from Svelte 4 to 5, with significant changes and deprecations on the horizon, also contributed to my decision to eliminate it as a contender – a decision I now regret.

   Pure React, however, wouldn't meet my needs. I disliked the idea of client-side fetching for backend APIs, especially since using JWTs in such a scenario isn't advised. Indeed, implementing a server-side solution from scratch felt like a significant time and effort investment. I also explored Angular and found it impressive, but noted fewer frontend component options compared to React. As someone who lacks web design talent, this was a substantial consideration.

   The overwhelming hype around Next.js eventually convinced me to give it a try. Next.js 13, with its newly released App Router, seemed like the cutting edge. I could end the story here, but reality had other plans.

   The Cookie Conundrum

   Dealing with cookies proved to be a significant headache. Some requests couldn't even read cookies, despite my understanding that they needed to be set server-side. After countless hours debugging and searching for solutions to client-side requests failing to access cookies, I hit a wall. It was my first major disappointment. I reset the application, deleting the .next and node_modules directories. I scoured the documentation and the web for a solution, quickly realizing many other developers were grappling with the same unpredictable behavior. The solution? I wish I knew: the next day, it simply worked like a charm.

   A few days later, I found myself replacing Next.js's native fetch API with Axios. The API's caching mechanism began to exhibit strange behavior. I can assure you, caching has a personality of its own. Even when seemingly inactive, it delivered unwanted results for requests that never even reached the backend API. Axios eventually solved that problem and allowed me to create an interceptor for JWT token rotation, but then… I started struggling with cookies again.

   At this point, the only workaround I found was to create a POST method within the Next.js application (which otherwise had no endpoints) solely to store JWT tokens. This forced me to implement an API key and restrict service access exclusively to the Next.js application. Ugly.

   Why Am I Still Using This?

   After fighting Next.js for so long – grappling with its poor and obscure documentation, abandoning its native solutions, and adopting alternatives – a stark realization hit me: Why am I still using this?

   Continue reading...

5. The Traditional Web Should Die

   felipestanzani@blog ~ ~ cat "The Traditional Web Should D"~ cat post << 05-12-2025

   

   Call for IT Pros to Rethink Web Technology

   TL;DR;

   Ever spent hours debugging a cross-browser CSS issue only to find it’s an obscure rendering bug? What if the web didn’t have to be this painful? As IT professionals, you confront daily challenges with cross-browser bugs, XSS vulnerabilities, and framework churn. The culprit? HTML, JavaScript, and CSS—an outdated trio. This post argues that it’s time to rethink web technology for a simpler, more secure future.

   The Origins of the Web Trinity

   Throughout the history of the computer, many technologies have been created and evolved. Nevertheless, until now, nobody has faced one of the biggest technology problems: the HTML + JavaScript + CSS Trinity for web applications. HTML has been used beyond more than it was designed for. As a result, these unforeseen uses created unexpected complexity. Not only does this burden the IT professionals, but it also prevents the web from leaping ahead. The HTML+JS+CSS trinity costs companies billions annually in maintenance and security fixes.

   The Birth of HTML

   In 1989, Tim Berners-Lee created the World Wide Web. At that time, the most powerful computer a person could have was an 80386 PC with the impressive Clock Speed of 20MHz. The same computer would come with 16MB of RAM in its more glorious version, and 100MB of HDD space.

   Although the first HTML-based website only came to life in 1991, it supported only static pages. The internet was designed and imagined for computers that couldn't handle a single background weather service that the cheapest smartphones run without any hassles. They couldn't even imagine what HTML would become later.

   The Web Technology Pandora’s Box

   Subsequently, when a NCSA researcher assistant called Rob MacCool, created the Common Gateway Interface in 1993, Pandora's box was opened. CGI was a way to integrate C and Perl with HTML and generate dynamic pages.

   CGI came before the <a> and <p> HTML tags being formalized, which happened only in 1994 with HTML 2.0. It created abilities beyond sharing static documents. Now it would be possible to sell goodies and information through the web. This new idea ran faster than a trail of gunpowder, and new problems emerged.

   Continue reading...

See all tags .