Svelte

Svelte 4 Launch Party Recap

Published Jun 30, 2023

Updated Oct 12, 2023

12 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

In this Svelte 4 Launch Party event, our panelists discussed the release of Svelte 4.

In this wrap-up, we will talk about panel discussions with Svelte core team members, which is an in-depth exploration of the Svelte 4 release, highlighting its key features and performance enhancements. You can watch the full Svelte 4 Launch Party event on the This Dot Media's YouTube channel.

Here is a complete list of the host and panelists that participated in this online event:

Hosts:

Tracy Lee, CEO, This Dot, @ladyleet
Rob Ocel, Team Lead & Software Architect, This Dot, @robocell

Panelists:

Geoff Rich, Svelte Core Team, @geoffrich_
Simon Holthausen, Full-time Svelte maintainer, @dummdidumm_
Puru Vijay, Svelte Core Team, @puruvjdev
Benn McCann, SvelteKit Maintainer, @BenjaminMcCann

Introductions

Geoff, one of the Svelte maintainers, started the introductions. He expressed his excitement about the new major version of Svelte and shared his years of experience using the framework. In his day job, Geoff is a Senior Software Engineer at Ordergroove.

Simon, a full-time Svelte maintainer working at Vercel, was busy preparing and finally releasing Svelte 4. He happily noted that there were very few bugs, and everything seemed to be working smoothly. Simon's dedication to maintaining the framework has contributed significantly to its success.

Puru, a college student, showcased his impressive skills by working on the website and the REPL for Svelte. Balancing his studies with web development, Puru demonstrated his passion for Svelte and his contributions to its ecosystem.

Ben primarily focuses on Svelte Kit, but also pitched in with Svelte 4. Besides his work on Svelte, Ben is an entrepreneur, adding an extra dimension to his diverse skill set. His contributions to the Svelte community have been invaluable.

What Should Everyone Be Excited About in Svelte 4?

Svelte 4 has arrived, and while it may not be packed with mind-blowing features, there are several neat little improvements that are worth getting excited about. The main focus of this release was on maintenance and cleaning up the framework to pave the way for the big Svelte 5 release. So don't worry, there are bigger things in the pipeline!

One of the first things to note is that file sizes in Svelte 4 have significantly decreased by about 10 to 12 fold. This means that your website will load much faster, thanks to the reduced bundle size. Additionally, improvements have been made in hydration, which affects the speed at which pages hydrate. The core around hydration has become smaller, resulting in improved performance.

Another noteworthy enhancement in Svelte 4 is the complete overhaul of custom element support. This change, although technically a breaking one, introduces a new wrapper approach. Previously, in Svelte 3, you had to use every Svelte component as a custom element, even if you wanted to keep certain components as internal implementation details. With the wrapper approach, you now have the flexibility to use components as regular Svelte components internally, fixing a range of bugs and fulfilling numerous feature requests. This change proved to be a tremendous success, resolving multiple issues in one fell swoop.

Svelte 4 brings value to your day-to-day development experience. For example, the improved type generation and autocomplete have made working with Svelte components a lot smoother. The autocomplete feature now grabs the correct import, eliminating the frustrations of navigating to the wrong files. Additionally, the introduction of declaration maps allows you to see the actual source code, providing a better understanding of the inner workings of Svelte.

There's also good news for those who want to contribute to the Svelte codebase. In Svelte 4, the entire codebase has been converted from TypeScript to JavaScript with JS Docs. While type checking is still in place to ensure error-free development, this change simplifies the process of working with the source code. Developers can now directly edit the source and test changes without worrying about the mapping between TypeScript and JavaScript.

In terms of performance, the reduction in bundle sizes has made a significant impact. Although the size reduction percentage may have been misunderstood by some, primarily referring to the compiler size rather than the runtime bundle, it has tangible benefits in scenarios like online tutorials and interactive experiences.

Beyond the technical improvements, Svelte 4 also brings updates to the documentation site and the main website. The team has put in considerable effort to enhance the user experience, making it easier to navigate and find the information you need.

Puru Does a Run Through of the Updates to the Svelte.dev Site

Puru shares exciting news to share about the overhaul of the svelte.dev website. First things first, let's talk about the star of the show: dark mode. It's finally here, and it's a game-changer. They’ve given the entire site a fresh redesign, taking inspiration from the sleek look of kit.svelte.dev. You'll notice some similarities, but they’ve added their own unique touch to make it shine. They’re now linking to the improved tutorial on learn.svelte.dev, which is definitely worth checking out.

Now, let's dive into the docs. They've made some significant changes to make your browsing experience a breeze. Instead of a single page, they've divided everything into multiple pages, making it super easy to find what you're looking for. Each component, logic block, and style module has its own dedicated page. It's all organized and up-to-date, thanks to the auto-generation from the source code. Say goodbye to outdated information and hello to hassle-free browsing.

They've introduced some fantastic new features that you're going to love. In the REPL, they've added multiple cursors, making coding even more efficient. Plus, they've created a REPL User Guide, packed with handy shortcuts and nifty tips and tricks. And here's the best part: our code snippets now support TypeScript. Just a simple click, and you'll have the TypeScript equivalent at your fingertips. It couldn't get any easier to level up your coding game!

So, head over to the new website, immerse yourself in the revamped docs, and enjoy all the fantastic updates we've made. And don't forget to check out the blog section for more in-depth information. Happy browsing, and get ready to experience the best of the new and improved website!

Upgrading from Svelte 3 to Svelte 4

Well there are a few things you need to know. But don't worry, it's not too complicated. First off, you'll find all the breaking changes highlighted and summarized on the migration Doc Page. So, if something breaks, you can check it out there.

If you're still on Svelte 3, the best way to start is by using the migration script. Just type in npx svelte-migrate svelte-4 in your command line, and it will go through your code base and automatically update things like tightened up types and local transitions. The migration script will even ask you if you want to migrate your global transitions or not. It's like a little questionnaire to make sure everything goes smoothly.

The migration script does a lot of the heavy lifting for you, updating dependencies in your package.json and ensuring peer dependency versions match up. It takes care of most things, but there might be a few other changes you'll need to handle. That's where the migration guide comes in handy. It covers all the other changes and helps you navigate through them.

Now keep in mind that upgrading to Svelte 4 might require at least Node 16. So, if you're using older dependencies that are holding you back from upgrading Node, it's time to poke your manager or tech lead and emphasize the need to stay current. After all, using outdated versions can pose security vulnerabilities. So make a strong case for the upgrade and let them know it's time to invest in keeping things up to date.

Geoff talked about how he has already upgraded a few sites to Svelte 4, and honestly, just upgraded the dependencies, and it worked like a charm. He didn't even bother running the migration script himself. Different projects may have different needs, so it's always good to be aware of any potential obstacles. Stay up to date and remember, keeping things secure is a top priority!

Svelte 4 and How It Works with Svelte Kit

If you're using Svelte Kit and thinking about upgrading to Svelte 4, here's what you need to know. The good news is that you can stick with your current version of Svelte Kit if you want, but there will be a warning about the peer dependencies not matching up. We made a small change to officially support Svelte 4 within Svelte Kit. But other than that, not much else has changed.

One important thing to remember is to upgrade the plugins file that Svelte Kit uses. You can do this by updating your lock file or simply upgrading to the latest Svelte Kit, which will take care of it for you. The migration script handles all the necessary updates, so running it will ensure everything works smoothly.

When it comes to impact, Svelte 4 brings some improvements. Your hydration code will be smaller, and the hydration speed will be faster, which means your final app bundle could be around 10% smaller. We've been working on even more performance enhancements, and using the Chrome performance tab in the developer tools can help you identify areas that need improvement.

So, in a nutshell, upgrading to Svelte 4 is optional for Svelte Kit users. But, it brings benefits like smaller code and faster hydration. Just remember to update the plugins file and use the migration script to handle any necessary changes. Keep an eye on the Chrome performance tab for optimization opportunities.

Are Svelte and Svelte Kit Going to be Paired in the Future in Updates or Stay Independent?

When it comes to updates for Svelte and Svelte Kit, there's a relationship between the two, but they also have their own focuses. The development of Svelte and Svelte Kit is somewhat interconnected, with learnings and improvements transferring between them. While the maintainers tend to focus on one major project at a time to gather feedback and make meaningful changes, they do draw lessons from both and apply them accordingly. For example, the decision to make transitions local by default in Svelte 4 stemmed from insights gained during the development of Svelte Kit.

Although there may be periods of emphasis on either Svelte or Svelte Kit, they are designed to complement each other and take advantage of each other's features. The development teams work on both code bases, ensuring a coordinated approach. While there may be a Svelte Kit 2 in the future, it's important to note that the release of Svelte 5 doesn't automatically mean a corresponding major update for Svelte Kit. The decision to introduce a new version depends on various factors, such as API changes and compatibility with the latest versions of Svelte, Node.js, and bundlers.

Ultimately, the goal is to provide a seamless and optimized experience for developers using Svelte and Svelte Kit. By developing them in tandem and leveraging the benefits of each, the teams behind these projects ensure continuous improvements and adaptability to the evolving needs of the community.

Svelte Dev Tools Repo and Funding for Svelte

So, regarding the Svelte Dev Tools repo, it used to be a community-maintained project led by a contributor named Red Hatter. She developed and published it independently. But more recently, she transferred the repository to the Svelte team so that they could also contribute and provide support. Currently, the team hasn't been able to publish new versions of the extension to the store, so there might still be the Svelte 3 version available. However, they are working on publishing a new version and may ask users to switch over to it for Svelte 4.

Now, let's talk about funding for Svelte. While financial support is definitely appreciated, the team also values something equally important—time. Companies can make a significant impact by allowing their employees to work on Svelte or Svelte Kit, fixing bugs, and contributing their time and expertise to improving the projects. Donations are welcome, of course, but finding skilled developers like Pooria (one of the Svelte team members) can be challenging even with funding available. So, giving employees the time and freedom to work on Svelte-related projects is highly appreciated and can have a significant positive impact. It's not just about money; it's about investing resources, whether financial or human, into the growth and development of the Svelte community.

Getting Involved in Open Source

If you're interested in getting involved in open source for Svelte, the journey can take different paths. One way to start is by creating projects or contributing to existing ones in the Svelte ecosystem. For example, Peru mentioned that he initially created a Svelte version of a tool called MacOS, which gained attention and led to him becoming a Svelte ambassador. Being active in the community, showcasing your work, and advocating for Svelte through speaking engagements or participating in events like Svelte Summit can also help raise your profile.

Becoming a Svelte ambassador or being recognized by the core team doesn't necessarily require direct contributions to the Svelte codebase. You can contribute in various ways, such as creating engaging content like videos or blog posts that benefit the community, maintaining popular Svelte libraries, assisting users on platforms like Discord or Stack Overflow, and participating in GitHub discussions. The core team and community value not only code contributions but also the positive impact and dedication you bring to the Svelte community.

It's worth noting that the journey can be unique for each person. Even if you haven't contributed to the Svelte codebase directly, like the ambassadors Hunter Byte and Joy of Code, you can still make a significant impact and be recognized for your contributions. For instance, Pooria mentioned that his first contribution was focused on creating the Svelte website rather than working on the core Svelte codebase. So, anyone with a passion for Svelte and a willingness to contribute can become a Svelte ambassador and actively participate in the open-source community.

Contributing to Open Source

Contributing to open-source projects like Svelte may seem daunting, but you don't have to understand the entire codebase from the start. Start by looking for beginner-friendly issues labeled as "good first issue" or similar tags. These provide a starting point to dive into the codebase. Follow the code path, use failing tests as guidance, and utilize features like control-clicking to navigate to relevant implementations.

Documentation and contribution guides are valuable resources for newcomers. Svelte Kit, for instance, has focused on making its codebase beginner-friendly. If you encounter difficulties, join the project's Discord channel and seek guidance from experienced contributors. Providing feedback on areas where more documentation is needed can help improve the contributor experience.

You can also contribute to adjacent tools related to Svelte, such as Prettier or ESLint plugins, which are maintained by the core team. These projects are often smaller in size and provide a manageable entry point. Additionally, non-coding contributions like improving project workflows or setting up testing and CI processes are also valuable.

Remember that contributions, regardless of their scale, have a positive impact on the project and the open-source community. Focus on understanding the specific area you want to work on, leverage available resources, engage with the community, and consider contributing to adjacent projects. With these steps, you can jump into contributing to open source and start making a difference.

Closing Thoughts from Panelists

Simon shared his enthusiasm for the future of Svelte, particularly the highly anticipated Svelte 5. The recent addition of Dominic to the team has already made a significant impact, and the brainstorming sessions have been rewarding. Exciting things are on the horizon for Svelte users.

Geoff encouraged everyone to give Svelte 4 a try and welcomes feedback and issue reports as they continue to refine and improve the framework. He emphasized that they are still in the early stages after the release and appreciate the community's support in upgrading their apps and providing valuable insights.

Peru gave a special shout-out to Paulo Ricca, who has been instrumental in resolving issues with the new REPL. With Paulo's assistance, the REPL is now as stable and impressive as before. Peru expresses his gratitude for the collaboration.

Ben extended his appreciation to the ecosystem integrations, mentioning the Storybook team and Jesse Beech, who contributed to optimizing file sizes and ensuring Svelte's compatibility with other JavaScript projects. The Svelte team is open to supporting and collaborating with anyone seeking to integrate Svelte with other tools in the ecosystem.

Overall, the panelists were thankful, excited about the future, and grateful for the community's contributions and collaborations. The energy and positive feedback drove their motivation, and they encouraged everyone to continue exploring and pushing the boundaries of what Svelte can achieve.

Conclusion

In this Svelte 4 Launch Party, the panelists express their gratitude to the vibrant Svelte community for their unwavering support and positive energy. The launch of Svelte 4 and the promising developments of Svelte 5 have generated excitement and anticipation among developers. The core team's commitment to continuous improvement, collaboration with ecosystem integrations, and dedication to addressing user feedback are evident. As Svelte evolves, the contributions of individuals, whether through code, documentation, or community engagement, are valued and celebrated. With the momentum and enthusiasm surrounding Svelte, the future looks bright for this innovative framework and its passionate community.

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

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

A Deep Dive into SvelteKit's Rendering Techniques

A Deep Dive into SvelteKit's Rendering Techniques Introduction SvelteKit is a meta-framework for Svelte that allows you to develop pages based on their content. At its core, SvelteKit introduces three fundamental strategies out of the box, each designed to streamline the development process and adapt to the specific needs of your project. These strategies enable you to easily create dynamic, responsive, and highly interactive web applications. These strategies, or as SvelteKit calls them, page options, are: * Prerender: Ideal for static content that doesn't change, making your pages lightning-fast to load. * SSR (Server-Side Rendering): Ideal for rendering full pages with dynamic content from a server. * CSR (Client-Side Rendering): Best for highly dynamic and interactive applications where content updates frequently based on user actions. These page options can be applied to specific pages (when exported from **+page.js or +page.server.js) or to a group of pages (when exported from +layout.js or +layout.server.js). They can also be set across the entire application. You accomplish this by exporting it from the root layout. It's worth noting that child layouts and pages can supersede settings from parent layouts. This means you could activate prerendering for the whole app and then turn it off for certain pages that require dynamic server rendering (SSR). In this blog post, we'll explore these page options and share some insights on how you might use them in everyday web projects. Prerendering Prerendering is akin to taking a snapshot of your web pages when you build your application; you might have heard of this as static rendering. This snapshot is then served to all users, ensuring lightning-fast load times since the server simply delivers the pre-built files without additional processing rather than dynamically generating the files for each request. This method is perfect for content that remains unchanged across visits, such as blog posts, documentation, or landing pages. In other words, pages with no dynamic content. There will be situations where you would like to avoid using this option, though. The rule of thumb is that if two different users will see different content, then this is a no-go. Other reasons are inconvenience for your needs. For example, your build times could drag if you end up prerendering tons of pages. Is that convenient to you? Well, that’s for you to decide! The prerender option is turned off by default, so we need to enable it if we want to start using it. Export the following in the +page.server.js or just +page.js: ` Likewise, if you have a group of pages, you could do the same inside a +layout.js or +layout.server.js . If your app is suitable to be all SSG (Static Side Generation), you could use adapter-static, which will output files suitable for use with any static web server. In cases where you happen to opt-in for this, you could turn off pages that need dynamic rendering: ` Another cool feature about prerendering is that pages that fetch data from server routes can automatically inherit default values during the prerendering process. This feature simplifies data management and enhances the development workflow, especially when dealing with dynamic content that needs to be prerendered with specific data sets. Let's say you have a blog where each post fetches its content from a server route when the page loads. Normally, this would require the user's browser to make a request to the server at runtime. However, with prerendering, you can have this data fetched and embedded into the page at build time. ` In this example, when the blog/[slug].sveltepage is prerendered, it makes a fetch call to /api/posts/[slug], which returns the post data. This data is then used to prerender the blog post page with the content already in place, allowing the page to load instantly for the user, with the blog post content visible even before any JavaScript is executed on the client side. There’s a third and useful option when prerendering: ` Using this option is like telling SvelteKit to make a smart guess about whether to prerender your page in advance. You're saying, "Hey SvelteKit, you decide if this page should be prerendered based on what you find about the page" SvelteKit analyzes your page and if it determines the page can be prerendered without complications, it will automatically generate a prerendered version. This process involves SvelteKit either crawling a link inside an already prerendered page, prerendering entry points or targeting pages that are specifically marked for prerendering set in entries. An example is a blog section where you post articles regularly. The blog section has a main page that lists all your blog posts and individual pages for each blog post. The structure for this might be something like: In this setup, the /blog main entry page will be prerendered automatically. However, individual blog posts at paths like /blog/[slug] will not be prerendered unless linked directly from another prerendered page. For instance, if there’s a link to /blog/some-cool-slug, like: <a href="/blog/some-cool-slug">, SvelteKit will be able to crawl that link and prerender that specific page as well. Now let’s say that you would like to prerender your latest blog post, but there's no link for SvelteKit to crawl to this page. In these cases, you can explicitly add these pages to the prerender entries list. By doing so, SvelteKit will prerender every specified entry, ensuring that the content is immediately accessible to users. You can configure the prerender entries directly in your svelte.config.js file or by exporting an entries function from a +page.js, a +page.server.js or a +server.js belonging to a dynamic route. Here’s how you can do it: ` SSR SSR is similar to prerendering. It ensures that pages are first rendered on the server. This process generates the complete HTML content, which is then sent to the client for hydration). This approach enhances the initial page load performance and SEO, providing a better user experience. Unlike prerendering, where pages are generated at build time, SSR pages are created at runtime. This key difference allows for the generation of dynamic content, making SSR particularly suited for applications that require personalized content for each user or real-time updates, such as user dashboards, e-commerce sites, and social media platforms. Similar to prerendering, SSR comes with its own set of limitations, and there are scenarios where it might not be the best choice for your project: * SSR can be expensive. It can significantly load your server, especially for high-traffic sites, as each page request involves rendering content on the server. If server resources are constrained, this could lead to performance bottlenecks. * Highly Interactive Applications: Applications that rely heavily on user interactions and real-time updates (like games or interactive tools like an admin panel) might not benefit much from SSR. CSR can provide a smoother user experience in these cases, as it minimizes server requests after the initial load. * SEO Is Not YOUR Priority: If search engine optimization isn't a key concern for your project (for example, an internal dashboard or an app behind a login), the SEO benefits of SSR might not justify the additional complexity and server demands. export const ssr = true is the option enabled by default. Thus, we can use its benefits from the start. To execute code exclusively on the server, such as fetching data from a database or an external API, SvelteKit offers a convention using +page.server.js files. This setup is ideal for server-side operations, ensuring sensitive logic and credentials are not exposed to the client. ` Note: When you employ +page.js in SvelteKit, the contained code is executed on both the server and client sides by default. However, if you intend for the code to run exclusively on the client side, you can disable SSR by setting export const ssr = false within your +page.js file. Doing so ensures that the code is only executed in the browser, adhering to client-side rendering principles and turning your app into a SPA. This is useful for cases where you don’t need the load on the server, or you don’t benefit from any of the benefits of SSR. CSR CSR plays a crucial role in making web pages interactive by hydrating them and incorporating JavaScript. JavaScript is crucial for adding interactivity to web pages—everything from animations and video players to form validations and dynamic content updates relies on JavaScript. However, there are instances where JavaScript is unnecessary. Consider a prerendered 'About' page; enabling CSR on this page could be excessive, especially if it lacks interactive elements. In such scenarios, you can streamline your page by disabling CSR that comes enabled by default, which can be done by simply doing this: ` Using this trick smartly can make your web pages load fast because downloading JavaScript is sometimes heavy. The key lies in strategically combining this approach with other rendering techniques to optimize performance and user experience. One factor to consider, though, is that turning off CSR also means you'll lose client-side routing. This requires you to depend on traditional browser navigation instead. Conclusion By thoughtfully applying these strategies, you can craft a SvelteKit application that performs exceptionally and delivers a fantastic user experience tailored to your audience's needs. Wrapping up our journey through SSR with SvelteKit. We discovered how choosing the right way to render pages (like prerendering, SSR, or CSR) is super important and can make a big difference in how well a website works. SvelteKit is awesome because it lets you pick the best method for your website. So, remember, playing with SvelteKit and these rendering methods can make your websites stand out. Use it to build websites that not only work great but are also fun and easy for people to use. Dive in, try things out, and see how your web projects can shine!...

May 1, 2024

7 mins

SvelteSEOJavaScriptWeb Performance

State of Meta Frameworks Recap

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....

Jul 28, 2023

12 mins

JS FrameworkJavaScript

Understanding Sourcemaps: From Development to Production

What Are Sourcemaps? Modern web development involves transforming your source code before deploying it. We minify JavaScript to reduce file sizes, bundle multiple files together, transpile TypeScript to JavaScript, and convert modern syntax into browser-compatible code. These optimizations are essential for performance, but they create a significant problem: the code running in production does not look like the original code you wrote. Here's a simple example. Your original code might look like this: ` After minification, it becomes something like this: ` Now imagine trying to debug an error in that minified code. Which line threw the exception? What was the value of variable d? This is where sourcemaps come in. A sourcemap is a JSON file that contains a mapping between your transformed code and your original source files. When you open browser DevTools, the browser reads these mappings and reconstructs your original code, allowing you to debug with variable names, comments, and proper formatting intact. How Sourcemaps Work When you build your application with tools like Webpack, Vite, or Rollup, they can generate sourcemap files alongside your production bundles. A minified file references its sourcemap using a special comment at the end: ` The sourcemap file itself contains a JSON structure with several key fields: ` The mappings field uses an encoding format called VLQ (Variable Length Quantity) to map each position in the minified code back to its original location. The browser's DevTools use this information to show you the original code while you're debugging. Types of Sourcemaps Build tools support several variations of sourcemaps, each with different trade-offs: Inline sourcemaps: The entire mapping is embedded directly in your JavaScript file as a base64 encoded data URL. This increases file size significantly but simplifies deployment during development. ` External sourcemaps: A separate .map file that's referenced by the JavaScript bundle. This is the most common approach, as it keeps your production bundles lean since sourcemaps are only downloaded when DevTools is open. Hidden sourcemaps: External sourcemap files without any reference in the JavaScript bundle. These are useful when you want sourcemaps available for error tracking services like Sentry, but don't want to expose them to end users. Why Sourcemaps During development, sourcemaps are absolutely critical. They will help avoid having to guess where errors occur, making debugging much easier. Most modern build tools enable sourcemaps by default in development mode. Sourcemaps in Production Should you ship sourcemaps to production? It depends. While security by making your code more difficult to read is not real security, there's a legitimate argument that exposing your source code makes it easier for attackers to understand your application's internals. Sourcemaps can reveal internal API endpoints and routing logic, business logic, and algorithmic implementations, code comments that might contain developer notes or TODO items. Anyone with basic developer tools can reconstruct your entire codebase when sourcemaps are publicly accessible. While the Apple leak contained no credentials or secrets, it did expose their component architecture and implementation patterns. Additionally, code comments can inadvertently contain internal URLs, developer names, or company-specific information that could potentially be exploited by attackers. But that’s not all of it. On the other hand, services like Sentry can provide much more actionable error reports when they have access to sourcemaps. So you can understand exactly where errors happened. If a customer reports an issue, being able to see the actual error with proper context makes diagnosis significantly faster. If your security depends on keeping your frontend code secret, you have bigger problems. Any determined attacker can reverse engineer minified JavaScript. It just takes more time. Sourcemaps are only downloaded when DevTools is open, so shipping them to production doesn't affect load times or performance for end users. How to manage sourcemaps in production You don't have to choose between no sourcemaps and publicly accessible ones. For example, you can restrict access to sourcemaps with server configuration. You can make .map accessible from specific IP addresses. Additionally, tools like Sentry allow you to upload sourcemaps during your build process without making them publicly accessible. Then configure your build to generate sourcemaps without the reference comment, or use hidden sourcemaps. Sentry gets the mapping information it needs, but end users can't access the files. Learning from Apple's Incident Apple's sourcemap incident is a valuable reminder that even the largest tech companies can make deployment oversights. But it also highlights something important: the presence of sourcemaps wasn't actually a security vulnerability. This can be achieved by following good security practices. Never include sensitive data in client code. Developers got an interesting look at how Apple structures its Svelte codebase. The lesson is that you must be intentional about your deployment configuration. If you're going to include sourcemaps in production, make that decision deliberately after considering the trade-offs. And if you decide against using public sourcemaps, verify that your build process actually removes them. In this case, the public repo was quickly removed after Apple filed a DMCA takedown. (https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md) Making the Right Choice So what should you do with sourcemaps in your projects? For development: Always enable them. Use fast options, such as eval-source-map in Webpack or the default configuration in Vite. The debugging benefits far outweigh any downsides. For production: Consider your specific situation. But most importantly, make sure your sourcemaps don't accidentally expose secrets. Review your build output, check for hardcoded credentials, and ensure sensitive configurations stay on the backend where they belong. Conclusion Sourcemaps are powerful development tools that bridge the gap between the optimized code your users download and the readable code you write. They're essential for debugging and make error tracking more effective. The question of whether to include them in production doesn't have a unique answer. Whatever you decide, make it a deliberate choice. Review your build configuration. Verify that sourcemaps are handled the way you expect. And remember that proper frontend security doesn't come from hiding your code. Useful Resources * Source map specification - https://tc39.es/ecma426/ * What are sourcemaps - https://web.dev/articles/source-maps * VLQ implementation - https://github.com/Rich-Harris/vlq * Sentry sourcemaps - https://docs.sentry.io/platforms/javascript/sourcemaps/ * Apple DMCA takedown - https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md...

Nov 21, 2025

5 mins

JavaScript

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.