Javascript

State of Meta Frameworks Recap

Published Jul 28, 2023

Updated Jul 28, 2023

12 min read

In this State of Meta Frameworks event, our panelists discussed the current State of Meta Frameworks.

This wrap-up covers the panel discussion on the ever-evolving state of meta frameworks in the digital landscape. Our expert panelists delved into the latest trends, advancements, and challenges faced by developers and businesses in adopting and utilizing meta frameworks effectively.

You can watch the full State of Meta Frameworks event on the This Dot Media YouTube channel. Here is a complete list of the host and panelists that participated in this online event.

Hosts:

Dustin Goodman, Engineering Manager, This Dot, @dustinsgoodman
Mattia Magi, Senior Software Engineer, This Dot, @mattia_magi

Panelists:

Ryan Carniato , Author of the SolidJS UI library and MarkoJS Core Team Member, @RyanCarniato
Ben Holmes, Software Developer, Astro, @BHolmesDev
Maya Shavin, Senior Software Engineer, Microsoft, Nuxtjs ambassador, Google Developer Expert , @MayaShavin
Andreas Ehrencrona, Head of Crown Framework Development at Hyperlab | Svelte Maintainer, ehrencrona
Amy Dutton, Lead Maintainer on the RedwoodJS Core Team, @selfteachme

In 5-10 years, where do you think web application development and meta frameworks are heading with the current trend of experimentation?

The discussion got off to a quick start, and there seemed to be a consensus that the web development ecosystem is currently going through a phase of experimentation, with numerous frameworks and tools popping up and evolving rapidly. This creative and innovative environment allows developers to explore various solutions, leading to a wide array of choices.

Looking ahead, it's difficult to predict the exact form of an ideal development environment in 5-10 years. However, there is an expectation that the web development community will eventually converge on some consensus regarding best practices and tools. Some current practices, like hydration (the process of converting server-rendered HTML into a fully interactive application on the client-side), might be considered wasteful in an idealized future and could be replaced with more efficient approaches.

One significant consideration for the future of web development is competition between web applications and mobile apps. While the web has advantages in terms of faster initial loading and no need to download large app files, mobile apps are often perceived as having better user experiences. Closing the gap between web and app experiences will likely be a focus in the coming years.

The ease of creating meta frameworks is seen as a positive aspect of the current ecosystem. The availability of bundlers and underlying tooling has made it possible for developers to build their frameworks on top of existing libraries and tools. This ease of creation has led to an explosion of ideas and innovation in the space.

However, the growing complexity and the abundance of choices can also be overwhelming for newcomers to web development. The abundance of frameworks and tools may make it challenging for beginners to know where to start. Simplifying the development process and making the technology more approachable for new developers will likely be a concern for the future.

There's also a cautious perspective regarding abstracting complexity too much. While meta frameworks and high-level abstractions can make development easier and faster, there's a risk of losing touch with the underlying technology and ending up with monolithic solutions that become difficult to maintain and replace.

In summary, the web development landscape is currently characterized by experimentation and rapid evolution. As the community continues to explore and innovate, it is expected that the industry will eventually converge on more standardized practices and tools. Finding the right balance between abstraction and maintainability will be crucial for the future of web application development.

Will other tech stacks follow Next.js in adopting server-first approaches with React's server components?

The discussion revolves around Next.js adopting React's server components, which indicates a shift towards server-first approaches in their development. The conversation contemplates the potential impact of this trend and whether it might lead to similar shifts in other tech stacks.

React's server components are viewed as a new and hot trend in the React ecosystem, with no similar implementations currently in other tech stacks. The participants discuss how web development has evolved over the past years, from server-rendered PHP and Rails applications to the rise of JavaScript and single-page applications (SPAs), and now the current move back towards server rendering and server component rendering.

Opinions differ on the real benefits of server components compared to more established server-side rendering approaches. Some participants express support for server components, appreciating the server-first philosophy and the idea of shipping HTML from the server to the client. Others question the advantages of introducing server components when client-side models are already highly capable and suitable for building dynamic apps.

The conversation touches on the challenges of adopting new approaches and integrating them with existing ecosystems. Legacy concerns and the need for education within the React community are mentioned as potential obstacles to widespread adoption.

However, it's acknowledged that some frameworks have already taken the path of starting with server rendering and then adding client-side functionality later. The debate continues, with participants emphasizing the ongoing innovation and experimentation in reducing JavaScript costs and execution in the browser.

Despite the differing approaches taken by underlying libraries and frameworks, there seems to be a degree of consolidation and agreement among metaframeworks in terms of handling progressive enhancement, server functions, file-based routing, and other patterns.

React server components are considered a special addition to the Redwood framework, which already incorporates a back-end component, mainly focused on GraphQL. The advantages of back-end flexibility and server-side rendering, particularly for tasks like handling Open Graph meta tags, are highlighted.

In conclusion, the participants express various viewpoints on the adoption of server components and server-first approaches. While there are differing opinions on their benefits and practicality, the conversation suggests that innovation and experimentation in web development will continue to shape the direction of tech stacks in the future.

What advice would you give to developers just starting to learn a new meta framework, and what are the learning curves typically associated with them?

For developers starting to learn a new meta framework, the panel suggests considering the purpose of their project and what they want to achieve. For simple projects like personal blogs or static sites, options like WordPress or templating with Astro may be more straightforward. However, for dynamic applications or job prospects, learning a popular component framework like React is recommended due to its extensive documentation and community support.

The importance of having a strong foundation in JavaScript, HTML, and CSS is emphasized before delving into meta frameworks. For beginners, learning the fundamentals is key, and then they can progress to using a meta framework that aligns with their interests and goals.

The panel acknowledges that the choice of framework might not be as crucial as many believe. The important thing is to pick one that feels comfortable and appealing, as the skills and patterns acquired will be transferable to other frameworks if needed.

Job market prospects can be enhanced by being well-versed in cutting-edge frameworks, as companies using less common technologies may highly value developers with expertise in those areas.

Ultimately, the advice is to avoid getting paralyzed by the fear of making the "wrong" choice and to focus on finding a framework that resonates with personal preferences and aligns with project requirements. Being adaptable and willing to learn new technologies will make a developer stand out in the job market and as a valuable consultant.

What are each of you using for deployments and what is blocking other platforms?

When it comes to deployments in different ecosystems, the panelists shared their experiences and challenges. They discussed the adoption of adapters to simplify deployment processes across various platforms. Some mentioned using AWS S3, Netlify, and Parcel for static sites, while others emphasized the importance of considering the platform's limitations and performance.

The conversation touched on serverless functions and edge deployments, with mixed experiences across different frameworks. While some found serverless functions efficient and fast, others encountered configuration challenges and a lack of clear documentation. Overall, the panelists highlighted the ongoing experimentation and search for optimal deployment solutions, with open-source collaborations being key to driving progress in this space.

What are some common misconceptions or misunderstandings about your respective frameworks?

The panelists addressed common misconceptions and misunderstandings about their respective frameworks. Redwood was mistaken as a new framework, but in reality, it has been stable and established for over four years. They emphasized their focus on startups and core infrastructure, partnering with incubators to support end-users in that market.

Astro clarified that it is not limited to static sites and can handle dynamic single-client rendered apps with its flexibility in mounting components. SolidJS emphasized its goal of raising the baseline of primitives in the ecosystem, encouraging the use of existing libraries and promoting a future without lock-in frameworks. Crown showcased its selling point of partial hydration for optimal performance but acknowledged the challenge of explaining the concept to potential customers. Lastly, Nuxt was differentiated from Next, and it was clarified that Nuxt is optimized for performance, aims to simplify developer experience, and is not just the "next" version of Vue.

The panelists agreed that maintaining a meta framework is not easy and often involves complex version upgrading and bug fixes. Overall, the conversation shed light on the unique strengths and goals of each framework, debunking common misconceptions and providing insights into their usage and focus areas.

What's causing the shift away from first-class testing in libraries and frameworks, and will we see a return to testing-first tooling?

In this candid conversation, the panelists discussed the changing landscape of testing in libraries and frameworks. They acknowledged that many new releases are moving away from first-class testing in favor of end-to-end testing tools like Cypress and Playwright. Some frameworks, like Redwood, continue to support unit testing with Jest and JavaScript testing library, while others, like Svelte Kit, are shipping with Playwright out of the box. The shift seems to be driven by the complexity of modern applications, where bugs often emerge in the integration of various components and data sources.

The panelists emphasized that testing needs to address the actual complexity of the application, and in some cases, end-to-end testing proves more effective in detecting bugs and ensuring the overall system works as intended. However, they also acknowledged that there are still benefits to unit testing and emphasized the importance of having both types of testing in a robust application.

The challenge lies in finding the right balance and tooling to suit different types of frameworks and projects. The diversity of opinions and preferences within the community makes it difficult to prescribe a one-size-fits-all approach to testing. Some frameworks prioritize ease of use and simplicity for beginners, while others lean towards comprehensive end-to-end testing for complex applications.

Overall, the future of testing-first tooling remains uncertain. While there may be a shift back towards unit testing in some cases, it seems that the focus will be on finding the right combination of testing approaches that best suit the specific needs and complexities of individual frameworks and applications.

Q&A

What are the panelists thoughts on Docusaurus?

The panelists discussed their thoughts on documentation tools, particularly Docusaurus. Some mentioned using their own custom solutions or other frameworks like Vpress and VuePress in the Vue ecosystem. Astro introduced their own documentation starter called Starlight, which aims to bring Docusaurus-like features to static templating languages open to any framework.

The panel also mentioned Next.js and how the React 18 documentation process used custom React components rather than Docusaurus. The focus on partial hydration was highlighted as a key factor that can make documentation sites even better.

Overall, the discussion reflected a diverse range of approaches and preferences when it comes to maintaining documentation for projects.

Is transpiling a necessary technique anymore, and what are the panelists’ thoughts on infrastructure as code?

The panelists had an interesting discussion about transpiling and infrastructure as code. Regarding transpiling, there was a consensus that while modernizing code to ESM (ECMAScript modules) is becoming more accessible, transpiling will still be necessary for a variety of reasons, including ensuring optimal performance and compatibility with different environments. The panel acknowledged that build tools and compilers are still widely used and will likely remain integral to the development process.

On the topic of infrastructure as code, the conversation centered around how frameworks are starting to offer more opinionated solutions for deploying applications seamlessly. Next.js, for example, automatically infers whether a page should be deployed as serverless or static based on code patterns and fetch calls. However, there were also concerns about the potential challenges and risks of overly automatic decisions when it comes to deploying and managing infrastructure. Astra's approach of explicit configuration and allowing developers to set defaults for routes was noted as a more conservative and safer option.

The discussion highlighted the ongoing evolution of these practices and how different frameworks are approaching the challenges of modern web development, providing varying degrees of automation and flexibility for developers. The general consensus was that while transpiling and infrastructure as code practices are continuously improving, they will still be essential components of web development for the foreseeable future.

Can you discuss a challenging problem you encountered while developing your meta framework and how you solved it?

During the discussion, the panelists shared challenging problems they encountered while developing their respective meta frameworks and how they approached solving them. One major challenge for Redwood was integrating GraphQL into their framework. While GraphQL can be powerful, not everyone is comfortable using it. Redwood aimed to simplify the process by providing conventions and handling complexities, making it easier for developers to work with GraphQL. This allowed applications to scale better, addressing over-fetching and waterfall issues.

In the Crown framework, caching was a primary focus due to the heavy reliance on third-party data sources that were not always fast enough. To tackle this, they implemented various caching mechanisms, including in-memory caches, persistent caches (e.g., Redis), and HTTP caching. They utilized decorators to specify which data should be cached and employed patterns like "reusing stale while revalidating" to ensure fresh data while maintaining fast response times.

For another panelist, the most challenging aspects of their meta framework were related to adapters and runtime components. They faced difficulties in balancing a generic interface for deploying apps anywhere while leveraging specific features of different platforms. Integrating platform-specific features without making the framework feel too platform-dependent was a considerable challenge. They explored the potential of generalizing certain aspects, such as key-value stores, to address common needs across platforms.

The panelists emphasized that navigating the ever-evolving landscape of serverless and edge computing, and integrating the innovations from various platforms without compromising the core functionalities of their frameworks, required careful consideration and creative problem-solving. Overall, the discussion shed light on the complexities and ongoing efforts to build user-friendly and powerful meta frameworks in the dynamic world of web development.

What are some of the most innovative or unexpected ways you’ve seen your frameworks being used?

During the lively discussion, the panelists shared some unexpected and innovative ways their frameworks have been used in real-world scenarios.

For instance, with Astro, they were pleasantly surprised to see Bloomberg experimenting with using it to template news articles. It was used alongside their existing framework in A/B tests, demonstrating Astro's versatility and ease of integration with other platforms. Additionally, Astro's middleware mode was another exciting discovery, allowing it to be deployed as a node server middleware, making it even more adaptable for existing projects.

Redwood, on the other hand, was amazed by the diverse range of use cases their framework supported, from consumer applications to deep vertical SaaS implementations. The community's adoption of Redwood for various purposes showcased its flexibility and robustness.

In the case of SolidJS, the team was surprised to find developers using Solid as the foundation for mobile apps and Electron applications. Solid's client-only mode was adapted for these use cases, demonstrating its potential to support mobile development and native-like experiences.

A particularly jaw-dropping example came from the Svelte community, where developers managed to recreate the classic game Wolfenstein 3D in the browser using just DOM elements and CSS 3D transforms. This creative use of Svelte showcased its DOM manipulation capabilities and the powerful potential of modern browsers.

Overall, the panelists were impressed by the ingenious ways developers harnessed the capabilities of their frameworks to solve unique challenges and create unconventional applications.

Conclusion

The overall discussion provided a glimpse into the dynamic and exciting world of meta frameworks and the ever-evolving possibilities they bring to web development. With such remarkable use cases and continuous innovation, the future of meta frameworks looks promising. The panelists expressed their gratitude to the audience for joining and participating in the event, and they all looked forward to meeting again in future events.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Bruce Wiggleston
@brucerw3 @BruceRW3

Exploring Angular Forms: A New Alternative with Signals

Exploring Angular Forms: A New Alternative with Signals In the world of Angular, forms are essential for user interaction, whether you're crafting a simple login page or a more complex user profile interface. Angular traditionally offers two primary approaches: template-driven forms and reactive forms. In my previous series on Angular Reactive Forms, I explored how to harness reactive forms' power to manage complex logic, create dynamic forms, and build custom form controls. A new tool for managing reactivity - signals - has been introduced in version 16 of Angular and has been the focus of Angular maintainers ever since, becoming stable with version 17. Signals allow you to handle state changes declaratively, offering an exciting alternative that combines the simplicity of template-driven forms with the robust reactivity of reactive forms. This article will examine how signals can add reactivity to both simple and complex forms in Angular. Recap: Angular Forms Approaches Before diving into the topic of enhancing template-driven forms with signals, let’s quickly recap Angular's traditional forms approaches: 1. Template-Driven Forms: Defined directly in the HTML template using directives like ngModel, these forms are easy to set up and are ideal for simple forms. However, they may not provide the fine-grained control required for more complex scenarios. Here's a minimal example of a template-driven form: ` ` 2. Reactive Forms: Managed programmatically in the component class using Angular's FormGroup, FormControl, and FormArray classes; reactive forms offer granular control over form state and validation. This approach is well-suited for complex forms, as my previous articles on Angular Reactive Forms discussed. And here's a minimal example of a reactive form: ` ` Introducing Signals as a New Way to Handle Form Reactivity With the release of Angular 16, signals have emerged as a new way to manage reactivity. Signals provide a declarative approach to state management, making your code more predictable and easier to understand. When applied to forms, signals can enhance the simplicity of template-driven forms while offering the reactivity and control typically associated with reactive forms. Let’s explore how signals can be used in both simple and complex form scenarios. Example 1: A Simple Template-Driven Form with Signals Consider a basic login form. Typically, this would be implemented using template-driven forms like this: ` ` This approach works well for simple forms, but by introducing signals, we can keep the simplicity while adding reactive capabilities: ` ` In this example, the form fields are defined as signals, allowing for reactive updates whenever the form state changes. The formValue signal provides a computed value that reflects the current state of the form. This approach offers a more declarative way to manage form state and reactivity, combining the simplicity of template-driven forms with the power of signals. You may be tempted to define the form directly as an object inside a signal. While such an approach may seem more concise, typing into the individual fields does not dispatch reactivity updates, which is usually a deal breaker. Here’s an example StackBlitz with a component suffering from such an issue: Therefore, if you'd like to react to changes in the form fields, it's better to define each field as a separate signal. By defining each form field as a separate signal, you ensure that changes to individual fields trigger reactivity updates correctly. Example 2: A Complex Form with Signals You may see little benefit in using signals for simple forms like the login form above, but they truly shine when handling more complex forms. Let's explore a more intricate scenario - a user profile form that includes fields like firstName, lastName, email, phoneNumbers, and address. The phoneNumbers field is dynamic, allowing users to add or remove phone numbers as needed. Here's how this form might be defined using signals: ` > Notice that the phoneNumbers field is defined as a signal of an array of signals. This structure allows us to track changes to individual phone numbers and update the form state reactively. The addPhoneNumber and removePhoneNumber methods update the phoneNumbers signal array, triggering reactivity updates in the form. ` > In the template, we use the phoneNumbers signal array to dynamically render the phone number input fields. The addPhoneNumber and removePhoneNumber methods allow users to reactively add or remove phone numbers, updating the form state. Notice the usage of the track function, which is necessary to ensure that the ngFor directive tracks changes to the phoneNumbers array correctly. Here's a StackBlitz demo of the complex form example for you to play around with: Validating Forms with Signals Validation is critical to any form, ensuring that user input meets the required criteria before submission. With signals, validation can be handled in a reactive and declarative manner. In the complex form example above, we've implemented a computed signal called formValid, which checks whether all fields meet specific validation criteria. The validation logic can easily be customized to accommodate different rules, such as checking for valid email formats or ensuring that all required fields are filled out. Using signals for validation allows you to create more maintainable and testable code, as the validation rules are clearly defined and react automatically to changes in form fields. It can even be abstracted into a separate utility to make it reusable across different forms. In the complex form example, the formValid signal ensures that all required fields are filled and validates the email and phone numbers format. This approach to validation is a bit simple and needs to be better connected to the actual form fields. While it will work for many use cases, in some cases, you might want to wait until explicit "signal forms" support is added to Angular. Tim Deschryver started implementing some abstractions around signal forms, including validation and wrote an article about it. Let's see if something like this will be added to Angular in the future. Why Use Signals in Angular Forms? The adoption of signals in Angular provides a powerful new way to manage form state and reactivity. Signals offer a flexible, declarative approach that can simplify complex form handling by combining the strengths of template-driven forms and reactive forms. Here are some key benefits of using signals in Angular forms: 1. Declarative State Management: Signals allow you to define form fields and computed values declaratively, making your code more predictable and easier to understand. 2. Reactivity: Signals provide reactive updates to form fields, ensuring that changes to the form state trigger reactivity updates automatically. 3. Granular Control: Signals allow you to define form fields at a granular level, enabling fine-grained control over form state and validation. 4. Dynamic Forms: Signals can be used to create dynamic forms with fields that can be added or removed dynamically, providing a flexible way to handle complex form scenarios. 5. Simplicity: Signals can offer a simpler, more concise way to manage form states than traditional reactive forms, making building and maintaining complex forms easier. Conclusion In my previous articles, we explored the powerful features of Angular reactive forms, from dynamic form construction to custom form controls. With the introduction of signals, Angular developers have a new tool that merges the simplicity of template-driven forms with the reactivity of reactive forms. While many use cases warrant Reactive Forms, signals provide a fresh, powerful alternative for managing form state in Angular applications requiring a more straightforward, declarative approach. As Angular continues to evolve, experimenting with these new features will help you build more maintainable, performant applications. Happy coding!...

Oct 4, 2024

5 mins

AngularJavaScript

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them. However, web browsers now offer a standard dialog element. Why use the dialog element? The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser. This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general. Basic usage Adding a dialog using the new tag can be achieved with just a few lines of code. ` However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it. ` Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat! Accessibility and focus management Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you. By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close element. Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly. Adding forms to dialogs Forms can also be added to dialogs, and there’s even a special method value for them. If you add a element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods. First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form. So given this example form: ` The form element with the example-form id will have its returnValue set to Submit. In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted. You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog. In this case, you can call event.preventDefault() in the submit event listener like so: ` Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog. Enhancing the backdrop The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc. You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working. First, an event listener is needed so that we know when the user clicks away from the dialog. ` Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog. To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple element can do! ` Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue. ` The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed. Conclusion Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options....

Oct 25, 2024

4 mins

HTMLJavaScript

State of Svelte Wrap-up

In this State of Svelte event, our panelists discussed updates, LTS releases, and APIs, with Node.js maintainers, technical steering committee members, and collaborators. In this wrap-up, we will take a deeper look into these latest developments, and explore what is on the horizon for Svelte. You can watch the full State of Svelte event on the This Dot Media YouTube Channel. Here is a complete list of the host and panelists that participated in this online event. Hosts: - Tracy Lee, CEO, This Dot Labs, @ladyleet - Rob Ocel, Team Lead & Software Architect, @robocell Panelists: - Scott Spence, Svelte Society, Developer Relations Engineer at Storyblok, @spences10 - Brittney Postma, Founder Svelte Sirens & Software Engineer Design Systems at Provi, @BrittneyPostma - Geoff Rich, Senior Software Engineer, Ordergroove | Svelte Core Team, @geoffrich_ - Simon Holthausen, Software Engineer at Vercel | Full-time Svelte maintainer, @dummdidumm_ - Kevin Åberg Kultalahti, Co-founder & Technical Community Builder at Svelte Society, Main Organizer at Svelte Summit, @kevmodrome Svelte 4 The chat got off to a great start with a discussion about Svelte 4, and what we can expect with that release. Simon spoke about how it will be more of a maintenance update than anything else. This version of Svelte will raise the minimum required Node version and use newer versions of Typescript as well. There will also be other minor breaking changes, but the release will mainly be focused on internally updating the repository by converting it to a mono-repo. As soon as these updates are done, Simon said they will immediately begin work on Svelte 5. Typescript and Svelte Scott brings up the reasons for not using Typescript in Svelte. Simon said a decision was made to transition the Svelte repository from using Typescript to using Javascript. There were questions about why types and type safety were being taken away from the repository. Simon clarified that the repository will be getting rid of .TS files, but they are not getting rid of type checking with Typescript, and the code will still be fully typed checked at the same level as before. The plan is to do it through JS Docs. JS Docs provides the same level of type safety you get through Typescript, but there is no longer a need for a compile step when using JS Docs. There is also no need to ship any Source Maps, and it should be easier to debug. Kevin also wanted to be clear that Typescript can still be used when building a Svelte app. Why Svelte? Rob notes that the official release of Svelte happened about 4 months ago, and asks the panelists how the launch has been going so far. Kevin goes first, talking about how everyone with whom he has talked about it has been very excited about it. He talks about how the form actions and data loading are very popular. In other frameworks, you have to attach event listeners, and then do the fetching on clients. Svelte simplifies all of that, and allows you to get rid of a lot of code by using the features in Svelte. Svelte REPL Kevin talks about the Svelte REPL, and how it plays into why Svelte is getting so big. Svelte isn’t just easy, it’s the fact that it is social in the fact that you can share a REPL and show someone how to do something with Svelte. If you have an issue, you can usually find a solution in the Svelte REPL. Server and Client Geoff talks about this aspect of Svelte. He says that they were treated as two separate entities, and there was talk about how to make them more interconnected so that it’s easier to use the server data, and get it into components. In SvelteKit, you have a load function in a separate file that defines how that data is loaded. Svelte also calls a JSON endpoint and then that component in the JSON data. State Management Geoff brings up the simple state management model that Svelte has, and they really don’t want to give that up by implementing too many things like short syntax. Simon adds that there is no real reason to bloat the syntax in the Svelte files. He doesn’t want the interoperability that Svelte currently offers. Signals vs Store A question is brought up about Signals vs Store, and if they are the same. Simon talks more about how they are related, but they are not necessarily the same. He explains that the API for Store is a little more settled right now where the API for Signals is a little more in exploration. Usability is also different because Signals is more primitive, and everything is composed of functions which you call in a certain way. With Stores, you wrap a store and map the values that are pushed into something different. How the panelists found out about Svelte The latter part of this event focused on how each panelist found Svelte and got involved with it. It was a very interesting part of the conversation to hear the backgrounds of each panelist, and why they got more and more involved with Svelte and everything that was going with it. It went very in depth, and would be worth exploring more by watching the conversation unfold on the event video. Conclusion The panelists were very engaged, and there was a lot of dialogue about Svelte and the exciting things being done. The panelists also finished by bringing up ways to get involved with the Svelte community. You can watch the full State of Svelte event on the This Dot Media Youtube Channel....

Apr 28, 2023

4 mins

Svelte

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

State of Meta Frameworks Recap

In 5-10 years, where do you think web application development and meta frameworks are heading with the current trend of experimentation?

Will other tech stacks follow Next.js in adopting server-first approaches with React's server components?

What advice would you give to developers just starting to learn a new meta framework, and what are the learning curves typically associated with them?

What are each of you using for deployments and what is blocking other platforms?

What are some common misconceptions or misunderstandings about your respective frameworks?

What's causing the shift away from first-class testing in libraries and frameworks, and will we see a return to testing-first tooling?

Q&A

What are the panelists thoughts on Docusaurus?

Is transpiling a necessary technique anymore, and what are the panelists’ thoughts on infrastructure as code?

Can you discuss a challenging problem you encountered while developing your meta framework and how you solved it?

What are some of the most innovative or unexpected ways you’ve seen your frameworks being used?

Conclusion

Bruce Wiggleston

You might also like

Exploring Angular Forms: A New Alternative with Signals

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

State of Svelte Wrap-up

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

Exploring Angular Forms: A New Alternative with Signals

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

State of Svelte Wrap-up

Introduction to Zod for Data Validation