DEV Community: Elves Vieira

Vercel is Investing in Mobile with React Native

Elves Vieira — Tue, 11 Mar 2025 17:41:17 +0000

The company behind Next.js recently made a strategic move signaling its increased commitment to the React Native ecosystem by welcoming Fernando Rojo as Head of Mobile. Known widely in the React Native community, Fernando has been pivotal in driving innovations that bridge mobile and web experiences.

Fernando is best known for open-source projects like Dripsy, which provides responsive UI components that seamlessly adapt between mobile and web, Expo Router, a game-changer that introduced file-based routing inspired by Next.js to React Native apps, Solito, enabling unified web and mobile navigation and code sharing, and Moti, which greatly simplified creating complex, fluid animations in React Native. Beyond these, Fernando has actively contributed to Expo’s tooling improvements and frequently engages with the community by sharing insights and leading discussions on the future of mobile development.

This appointment highlights Vercel's vision of enhancing mobile experiences, suggesting deeper integrations between Next.js, React Native, and Expo.

This is exciting news for anyone working in the React and React Native ecosystems, signaling a promising future ahead.

Types Proposal for JavaScript May Take Longer Than You Think

Elves Vieira — Sun, 16 Feb 2025 13:08:39 +0000

The "Types as Comments" proposal for JavaScript, which aims to allow type annotations without requiring a build step, has been under discussion in TC39 for several years. While many developers are eager to see native type support in JavaScript, the proposal faces significant challenges that may delay its progress for a long time—or even prevent its adoption altogether.

The Proposal

The goal of "Types as Comments" is to give developers the ability to write type annotations directly in JavaScript while ensuring that they are completely ignored by JavaScript engines at runtime. This means that they do not introduce new runtime semantics and remain purely for tooling purposes.

The proposal aims to provide an ergonomic way to declare types without requiring transpilation, making type annotations more accessible without adding extra complexity to the language itself. If accepted, this would mean developers could write code like this and run it directly in a JavaScript engine:

function add(a: number, b: number): number { return a + b; }
The types would act as comments and be ignored by the JavaScript runtime, but they would still be available for type checkers like TypeScript and Flow.

Discussions

March 29, 2022 (Initial Presentation)

The proposal was first introduced by Daniel Rosenwasser from the TypeScript team and quickly gained strong support from the TypeScript community. However, concerns emerged regarding its scope and potential impact on JavaScript. One of the main objections was that the syntax was heavily influenced by TypeScript, raising questions about whether it would be truly neutral. Additionally, the proposal introduced a significant number of new grammar rules, which some committee members feared could fragment the language. As an alternative, suggestions were made to explore other ways to support TypeScript in JavaScript environments, such as enabling TypeScript parsing directly in developer tools instead of modifying the language itself.

March 31, 2022

The proposal advanced to Stage 1, but only after its scope was clarified. The committee agreed to explore a simpler syntax while ensuring that it remains neutral to existing type systems like TypeScript and Flow. Additionally, there was an ongoing debate about whether this could serve as a long-term step toward unifying JavaScript and TypeScript, or if it risked fragmenting the language even further.

March 22, 2023

Further discussions revealed significant ambiguities in the proposed syntax, making parsing more complex than initially expected. One example that caused issues was:
async as (x: y) => z;
In this case, it was unclear whether as was being used as a function name or as a type assertion, highlighting the difficulty in distinguishing between type annotations and regular JavaScript expressions.
To address these concerns, some members suggested introducing an explicit opt-in mechanism, such as:
"use types";
This directive would indicate that a file contains type annotations, helping to prevent conflicts with existing JavaScript syntax. However, this idea sparked further debate on whether such an opt-in approach would be necessary or if a more seamless integration could be achieved.

September 27, 2023

During this meeting, discussions shifted towards the broader implications of integrating type annotations directly into JavaScript. Some members questioned whether this proposal would truly simplify development or if it would introduce additional complexity. Concerns were raised about potential misunderstandings from developers who might assume the annotations would enforce runtime type checking, similar to statically typed languages. Additionally, the debate continued on whether JavaScript engines should allow some form of optional runtime type reflection in the future, though this was largely dismissed as being out of scope. There was also renewed discussion on whether an opt-in directive such as "use types"; could mitigate syntax ambiguities, but consensus remained elusive.

Current Status

The proposal remains in Stage 1 with no clear path forward. Grammar ambiguities persist, making it difficult to reach consensus on how type annotations should be structured. A major point of contention is whether JavaScript should adopt TypeScript’s syntax or develop a completely new annotation format that is more neutral. Additionally, discussions continue around the possibility of enforcing an explicit opt-in mechanism, such as a "use types" directive, to prevent unintended conflicts with existing JavaScript syntax. Despite ongoing debates, no concrete resolution has been reached, and opposition from some committee members remains strong.

So...

The proposal faces several challenges that could delay its adoption for a decade. These include syntax conflicts, as type annotations closely resemble regular JavaScript code, making them difficult to parse unambiguously. There are also standardization challenges, as TC39 must balance the needs of TypeScript, Flow, and other type-checking tools while ensuring backward compatibility to avoid breaking existing codebases. Performance considerations are another factor—while type annotations would be ignored at runtime, parsing overhead must remain minimal. Finally, opposition from some committee members remains strong, with some TC39 delegates arguing that the current approach is fundamentally flawed and could create confusion.

If you're expecting this to become part of JavaScript soon, you may need to be patient. Given the current state of discussions, it may take several more years before it becomes a reality.

React Core Team Moves to Officially Deprecate Create React App

Elves Vieira — Thu, 30 Jan 2025 10:26:02 +0000

The React Core Team is taking steps to officially deprecate Create React App (CRA), a tool that has been central to starting React projects for years. While CRA was once the go-to solution for bootstrapping React applications, it has been unmaintained for over two years and is now struggling to keep up with the evolving ecosystem.

The team has acknowledged ongoing issues with CRA, particularly its incompatibility with React 19. The primary problem lies in outdated dependencies, such as @testing-library/react, which cause peer dependency mismatches during installation. These errors have made CRA difficult to use, especially for new developers.

What Are the Alternatives?

As CRA’s role diminishes, developers are encouraged to adopt modern tools like Vite. Vite has become the top choice for creating new React projects due to its speed, simplicity, and compatibility with the latest React features.

Unlike CRA, Vite offers instant hot module replacement (HMR) and minimal configuration, making it ideal for both beginners and experienced developers.

What’s Next?

The React Core Team plans to release the updates to CRA soon, which will include both the compatibility fixes for React 19 and the deprecation notices. They also aim to address the high search engine ranking of CRA’s legacy documentation, redirecting users to modern tools and best practices.

Stay tuned for updates as CRA’s deprecation becomes official: ISSUE.

What You Should Know Before Using Route Handlers in Next.js

Elves Vieira — Fri, 26 Jan 2024 15:05:29 +0000

In the evolving landscape of Next.js development, Route Handlers play a pivotal role. They are not merely a substitute for API routes; they offer a nuanced approach to handling HTTP requests within the Next.js framework. This detailed guide aims to demystify Route Handlers, highlighting their differences from API routes and best practices for their effective use.

1. Understanding Route Handlers vs. API Routes

Understanding the distinction between Route Handlers and API routes is fundamental to their proper utilization in Next.js.

Similarities and Differences: At first glance, Route Handlers might seem akin to API routes, as both handle HTTP requests. However, while API routes are designed for standalone server-side endpoints, Route Handlers are deeply integrated into the Next.js routing system, offering a more fluid interaction with pages and components.
Appropriate Use: The key to using Route Handlers effectively lies in recognizing their purpose. They excel in scenarios where HTTP methods need to be handled directly within the context of a page or a component, such as intercepting webhooks or custom server-side logic.

2. When to Use Route Handlers

Identifying the appropriate scenarios for Route Handlers can significantly optimize your Next.js application.

Ideal Scenarios: Route Handlers are particularly useful for handling webhooks, custom API integrations, and form submissions directly within the application's flow. For example, a Route Handler can efficiently manage a POST request from a form submission, process the data, and provide an immediate response without the need for a separate API endpoint.
Common Misconceptions: A common mistake is using Route Handlers for internal data fetching operations. In many cases, these operations can be more efficiently handled within server components or through direct API calls, thereby simplifying the application architecture and improving performance.

3. Accessing Data Directly in Server Components

Direct data manipulation within server components is a powerful feature of Next.js, often overlooked in favor of Route Handlers.

Benefits: Accessing and manipulating data directly in server components leads to cleaner and more maintainable code. It eliminates unnecessary network requests and reduces server response times.
Practical Examples: Consider a scenario where you need to fetch user data from a database. Instead of creating a Route Handler to perform this operation, you can directly call a database query function within your server component. This approach streamlines the data flow and reduces the complexity of your application.

4. Performance and Code Simplification

Optimizing performance and simplifying code are key benefits of judicious use of Route Handlers.

Optimization: By reducing the reliance on Route Handlers for operations that can be directly handled within server components, you can significantly enhance the performance and scalability of your application.
Best Practices: Encourage a minimalist approach to using Route Handlers. Prioritize direct data manipulation in server components and resort to Route Handlers only when direct interaction with HTTP methods is necessary.

Route Handlers in Next.js are a potent tool when used correctly. Understanding their role, capabilities, and limitations is essential for any developer looking to leverage the full power of Next.js.

Feel free to contact me: https://www.linkedin.com/in/elves-silva-vieira/