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
Svelte 4 Launch Party Recap
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....
Jun 30, 2023
12 mins
State of RxJS Wrap-up
In this State of RxJS event, our panelists discussed the current state of RxJS and the upcoming features and improvements of the highly anticipated RxJS 8 release. In this wrap-up, we will talk about panel discussions with RxJS core team members, which is an in-depth exploration of the upcoming RxJS 8 release, highlighting its key features and performance enhancements. You can watch the full State of RxJS 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 - Ben Lesh, RxJs Core Team Lead, @BenLesh Panelists: - Mladen Jakovljević, Frontend Web Developer, RxJS Core Team member, @jakovljeviMla - Moshe Kolodny, Senior Full Stack Engineer at Netflix, Previous RxJS Lead at Google, @mkldny - Marko Stanimirović, NgRx Core Team Member | GDE in Angular, @MarkoStDev State of RxJS Ben kicks off the discussion by updating everyone on the current state of RxJS. He starts off by recommending those using RxJS v6 to update to the current version 7.4 because it is about half the size of v6, and he says that v8 will reduce the size even further. There are also performance updates with 7.4 where the speeds improved 30 fold. RxJS version 8 is currently in alpha! There are not as many breaking changes with this version. The major breaking change in this version is that they are removing the long deprecated APIs. They are really wanting people to try things in the alpha version, especially the 408 loops to subscribe to observables. It is an interesting way to consume observables that use the platform, and may work really well with other people’s async await usage. Operators The team is currently trying to figure out a way to show people how they develop operators by giving them the means of developing operators. They currently have a problem where they externally tell people to develop an operator with this, you subscribe, and then you give this kind of hand rolled Observer there. Internally, they have a createOperatorSubscriber which replaces the operate function. They want a reference where you can see how to develop an operator using the ones already there to build your own. There is also a plan to make sure that the RxJS library works as a utility library to work with any Observable that matches the contract. Docs Mladen gives an update of the docs for RxJS. He explains that there aren’t a lot of updates currently with the docs. He explains that there were some issues in the past with exporting operators from two places. There was also an issue with the Docs app build running in the pipeline. He explains that these issues should now be resolved, and that there hopefully won’t be any more issues there. Pull requests are always welcome when working with RxJS docs. They try to stay on top of merge requests as well. NgRx Marko talks about NgRx and RxJS. He explains that RxJS is the main engine of NgRx for almost all of the libraries, especially State Management. A few packages, like direct store, implements a Redux pattern, but uses RxJS under the hood. Pipe Moshe brings up the typings for pipe. All of RxJS’s pipe methods and functions, including the new RxJS function, will work with any unary function. General Questions One of the first questions brought up was if RxJS should not be associated with Angular anymore. Ben brings up the fact that recently, there have been a lot of React people downloading RxJS. Another question was why NgRx is switching to Signals. Marco talks about how NgRx is a group of libraries that is used in Angular. NgRx needs to be in accordance with Angular. One main reason is because of the performance improvements with the change detection strategy. There were also other questions about contributing to RxJS and coming up with a way to utilize the docs for that. There are also questions about the RxJS community, and that there currently isn’t a discord or anything like that for it right now. Conclusion The panelists were very engaged, and there was a lot of dialogue about RxJS and the future that is to come with it. The question and answer portion at the end covered some great material that all the panelists took part in answering. You can watch the full State of RxJS event on the This Dot Media Youtube Channel....
May 22, 2023
4 mins
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
State of Node.js Wrap-up
In this State of Node.js event, our panelists discussed updates, LTS releases and APIs with Node.js maintainers, technical steering committee members and collaborators, and much more. In this wrap-up, we will take a deeper look into these latest developments and explore what is on the horizon for Node.js. You can watch the full State of Node.js 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 - James Snell, Node.js Foundation Technical Steering Committee, @jasnell Panelists: - Beth Griggs, Senior Software Engineer, Red Hat, Node.js TSC Member, @BethGriggs_ - Matteo Collina, Co-Founder and CTO of Platformatic.dev, Node.js TSC member, @matteocollina - Michael Dawson, Node.js Lead, Red Hat and IBM, @mhdawson1 General state of Node.js Michael kicks off the conversation saying there are a lot of things happening with Node.js right now. There were over a billion downloads last year alone, and it is continuing to grow. Beth talked about the major release of Node v20 coming out in April. Node 14 end of life is coming at the end of April. Matteo talked about two micro conferences happening this year for Node.js. One will be in North America in Vancouver in May, and the other one is in September in Bilbao. Updates from specific working groups Michael talks about spinning up a uvwasi team. The wasi is the web assembly system interface. It’s not only used in Node, but in other projects like grain. It’s a key component of wasm support. Michael also talks about how the Node.js API team has been great for building long term contributors. If you’re interested in add-ons and native code, it is a friendly group to get involved with. Beth talks about other ways folks can contribute to Node.js. She talks about a redesign of the website that happened recently. The main website has been migrated over to Next.js. Matteo talks about a massive PR that is open right now about the new loader API. There is a lot of effort being put into this with a lot of contributors. This new loader will replace the - - hack. New Features Michael talks about the single executable application that enables bundling code into the Node.js binaries without having to build it. He also mentions process permissions. These are two big new experimental features right now. Beth talks about the built-in test runner. It allows you to throw some scripts together, and get some simple tests without having to deal with dependable warnings for a mod. End of Event Each panelist takes time to go over what they are currently doing on their own. Beth is working in security for releases, and takes time to talk about everything there. Michael is working with the Node API, which is a long-term working project. James is work on standard APIs and also bringing interoperability with Node, Bun, and Dino. Finally, Matteo is working on getting Platformatic going. Conclusion The conversation went in depth about the state of Node.js, and what is being done in the new releases as well as experimental updates. The panelists were very engaged, and were great at bringing up ways to get involved with the Node community. You can watch the full State of Node.js event on the This Dot Media Youtube Channel....
Apr 10, 2023
3 mins
State of Web Performance February 2023 Recap
In the most recent State of Web Performance event, our panelists discussed the current trends in web performance, the applicability of SPA architecture, the Performance Inequality Gap, how development teams can get better at testing on more devices, and much more. In this wrap-up, we will take a deeper look into these latest developments and explore what is on the horizon for web performance. You can watch the full State of Web Performance 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 - Henri Helvetica, Dev. Community Manager, WebPageTest by Catchpoint Panelists: -Alex Russell, Product Manager on Microsoft Edge -Sia Karamalegos, Web Performance at Shopify -Estela Franco, Web Performance Specialist at Schneider Electric -Yoav Weiss, Software Engineer, Google Chrome's Speed Metrics team Updates from Panelists and What They Are Currently Working On The event started off with great conversation by getting updates from our panelists, and what they are currently working on. Our co-host Henri started by talking about how he likes to make sure developers are leveling up in their abilities. He stresses that performance literacy is of utmost importance. Estela continued the conversation by talking about how she is working to improve the web performance culture at her current company, and that she is trying to improve the web performance processes. Yoav talked about how he is excited about measuring soft navigations in SPAs. Sia just finished an internal hackathon at her place of employment. She mostly works with trying to make merchant websites faster. Alex spent about half his time on performance oriented things, and the other half is spent with first party teams at Microsoft trying to improve the state of web apps. After introductions, the conversation pivoted to the talking points for this event. Web Performance Culture Inside a Company Estela talked about working at Schneider Electric, and how she was brought in by management to improve web performance. The company is aware of the impact of web performance for users and customers. It helped her when getting involved with the different dev teams there. Having the management vision to work on that was really helpful. However, there was a struggle to keep different dev teams involved. A lot of the teams were aware of the importance of web performance, but web performance is more than just a performance score, and making sure the teams were aware of all that was involved was difficult at times. The environment overall has been beneficial by being the point of contact for changes made that may affect web performance. Sia saw that changes were more willing to be made on performance when it started to affect SEO. She was happy that it made them want to get on board no matter what the cause was. Innovations with Web Performance Yoav started this off by talking about aligning incentives. He spoke about how core web vitals creates a shared language that enables everyone to talk about the same things. It also aligns the long-term incentives of the platform with the short-term incentives of developers. He also talked about the concept of the "rage click", and how it isn’t a metric that is necessarily measured, but it is something that users can have a frustration with when the web performance affects how they interact with a site. Hardware and Web Performance Alex talked about how web performance doesn’t control the customer’s device, or the user’s hardware. It is also hard to detect software and it is often a poor response when it comes to software that isn’t liked. He explains that the web is the additive errors of a bunch of really hard problems coming together. He focuses on the complexity of what is coming down the wire. Frameworks and Web Performance Yoav talked about how people buy into a framework prematurely without knowing what the consequences would be for web performance. It usually happens that they are two years into using a framework, and then realize that a rewrite they did is a disaster from a performance perspective. He describes how it would be beneficial to protype in different stacks to see performance, but it isn’t being done. Sia added that a lot of this happened before people started really caring about web performance. She thinks that maybe now people may pause and consider the implications of some of the initial decisions being made. Estela agreed that teams don’t try different Frameworks first and pick the proper one because Frameworks are becoming more and more complex. It’s also hard to switch to a different technology in a timely manner. Browsers and Web Performance Alex spoke about his disappointment for the way browsers have behaved. Core vitals is a step up because it indicates that we are closing the circuit between what users actually experience. He talks about how the browser lacks in being the guarantor of solidarity between the decision-making wealthy class, and the people who are going to be excluded from these services. Yoav agreed that we could do a lot to incentivize developer behavior in the browser. Solutions to Support Web Performance Sia spoke about how performance would make you into a multi-million dollar company, but it could change how many extra millions you get. If you’re a Dev shop, there isn’t any prioritization on performance because they’re trying to get the client to pay for that feature. The client is the one who has to care about performance. Senior leadership in a large company has to care as well. Alex talked about HTML over the wire is really great for helping with web performance. He also mentioned SvelteKit, and how they are very responsible when it comes to web performance. Closing The conversation went in depth about the state of web performance, what is being done to help bring more awareness to it, and also how it can be improved. The panelists were very engaged, and brought many ideas to the table. It is always good to continue to have these discussions in order to stay current or talk about what needs to be done to keep things moving forward for the future of web performance. You can watch the full State of Web Performance event on the This Dot Media Youtube Channel....
Mar 3, 2023
5 mins
State of React Ecosystem Wrap-Up January 2023
In this State of React Ecosystem event, our panelists discussed the React Roadmap, Best Practices, Redux, Styling Libraries and techniques, Nextjs, and community initiatives! In this wrap-up, we will take a deeper look into these latest developments and explore what is on the horizon for React. You can watch the full State of React Ecosystem 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 - Adam L. Barrett, Senior Software Engineer, This Dot, @adamlbarrett Panelists - Mark Erikson, Senior Front-End Engineer, Replay, Redux maintainer @acemarke - Tanner Linsley, VP of UI/UX, nozzle.io, TanStack Creator, @tannerlinsley - Dominik Dorfmeister, TanStack Query Maintainer, @TkDodo - Ben Ilegbodu, Frontend Architect, Stitch Fix, @benmvp - Chantastic, DX Engineer, Chromatic, @chantastic - Kathleen McMahon, Senior Design Systems Engineer, Northwestern Mutual, @resource11 Updates from Panelists and what they are currently working on The event started off with great conversation by getting updates, from our panelists, on what they are currently working on. Mark Erikson was first, and he talked about how Redux Toolkit 1.9 was shipped back in November 2022. It had new options for RTK Query as well as forms improvements by optimizing the internals. Redux Toolkit 2.0 is currently being developed! It will have breaking changes, and there are some big things coming with the release including modernizing the build output, and updating the package to be fully es module format package defined, and much more! Redux Toolkit 2.0 alpha 1 has already been shipped, and he is asking for users to try it out, and give feedback. Kathleen McMahon was next, and talked about how she has been with Nortwestern Mutual and is currently working on standing up their design tokens system as part of the Lunar Design system. She has been enjoying the work of trying to get things into a very big Enterprise level system. She also got the opportunity to give a couple talks last fall at React Brussels and React Verona where she talked about feature flagging, accessibility, and how to make some widgets accessible. She will be giving a similar talk at React Miami. Tanner Linsley gave a quick update that he is currently working on Type Safe Routing and has been for over a year learning about the intricacies of how all of that works with type safe everything. He mentioned that there is also going to be a lot of new TanStack packages to play around with. He has also been recently trying to rebuild all the reactivity engine using SolidJS, and he is working on some smaller libraries at TanStack that are going to be headless. Dominik Dorfmeister gave an update about what is coming for TanStack Query. In a recent update, they added a Svelte query adapter for TanStack Query. They have pretty much completed the cycle of having one adapter for all the major frameworks. He takes time to share a video that shows Astro with the same query client shared with four different components with each one in a different framework. It shows what you can do when everything works together with the same query client. He also goes over the roadmap for getting to TanStack Query v5 with it hopefully coming out sometime this year. Ben Ilegbodu is a Frontend Architect at Stitch Fix on the frontend platform team. He is part of a team that builds out all the platforms and design systems that other teams use to build a site. He has been helping build out the design system using React while documenting in Storybook. He also talks about how the team has been building a development platform for all the teams to build their apps. They are in the process of moving from Rails to NextJS using a wrapper. He finishes up by talking about working on a monorepo for all of their libraries. Chantastic talks about how he has been trying to do a little more with Youtube this year. He works at Chromatic which is a company that maintains StorybookJS. They are all working to get to Storybook day which is March 14, 2023. It’s an event that is going to be going over everything that is happening with Storybook 7. This concluded introduction as the event moved into general questions for the panel. Panel Questions Adam got the conversation going to this next part of the event by asking right if React is dying? The panelists got on this topic and maintained it throughout the rest of the event. Each panelist took the time to explain how it is either frustrating or misunderstood. There is still growth and evolution within the React ecosystem. With new frameworks and libraries comes a betterment for the community as a whole. They also brought up how the same sorts of things were said about other frameworks like Angular. Overall, there was agreement that React is not dead, but in a time where it is growing to be a better product overall. Conclusion The one question that was asked helped bring out an incredible conversation on where React is and where it is going. It is always good to continue to have these discussions in order to stay current or talk about what needs to be done to keep things moving forward for the future of the library. You can watch the full State of React Ecosystem event on the This Dot Media Youtube Channel....
Feb 8, 2023
4 mins
State of Vue July 2022 Wrap-up
At the latest State of Vue event from This Dot Labs, our panel of Vue contributors and library authors gave us insights into some pretty large changes coming to Vue. There are some updates coming in Vue 3.3 very soon. In this wrap-up, I'll summarize our State of Vue event with key takeaways and things to look forward to in the future! If you'd like to see the event in full, check it out on Youtube. Vue 3.3 Evan You kicked off this session by talking about what to look forward to in Vue 3.3. It is currently in its early phase. There are plans to make features like stable. There are also updates to Reactivity Transform. There have been several iterations of that feature in the past, but the current version is a good place to finalize it. These are the two major features that are going to be made stable for the 3.3 release. There are other smaller features like support for external types and built-in lazy hydration. He also talked about a number of bags of issues that could potentially make their way into the release as well, such as issues related to Keep Alive and providing more fine-grained controls of the lifespan cache components. These are the two major features that are going to be made stable for the 3.3 release. There are other smaller features like support for external types and built-in lazy hydration. Evan goes over how that would work using async components as code split points, meaning if an async component is not used on the initial page it will not be loaded, but it does load when it is used on the page. Questions from panelists about 3.3 Resources Jessica Sachs brings up questions about resources to find more focus points on what is being released in 3.3, and Evan says that resources are being aggregated, and a collection is currently in a draft. But it is still being organized, and it will come out soon. SSR Simone Cuomo asks about SSR if the changes are being made by their own assumptions or by the extensive use of SSR with the current version of Vue.js? Evan goes on to talk about the needs arising from Nuxt from production use cases of Nuxt 2, and they expect that a very decent chunk of users will be opting for a full stack meta framework when they are building applications this way. SSR optimizations are going to be super important. Suspense API Abdelrahman Awad asks about suspense API since it recommends using async setup hook. He mentions there is an annoying issue where you try to inject something, and it breaks since it can’t recognize the current component. Evan mentions that it has technically already been solved in script setup. When you await, the script setup compiler automatically saves the contacts before they await and then restores it after the await. If you are using script setup, then you don’t need to worry about that problem anymore. Lazy Hydration Bjorn Lu asks about async component lazy hydration because it seems like a very interesting new approach, and he wonders if it could be used with something similar like Astro. Evan goes more into detail about how this process would be a very simple addition to the existing component API view. It wouldn’t just benefit SSR applications because you can use lazy hydration to delay the loading of that block as well. The benefit of delaying the loading of the block is not like delaying the hydration work itself because hydration is strictly based on the CPU time that’s blocking the main thread. However, loading a JavaScript block without evaluating it is not that bad because it saves the time when the user actually starts interacting with it. It would benefit anything that’s built on top of Vue, including Astro or anything similar to it. Reactivity Transform Thorsten Lünborg asks about the time frame concerning reactivity transform. Evan said the plan is to ship it as stable in 3.3. He says that they may rename the $$() to make it more descriptive, but that is about the only major feature changing with reactivity transform. He goes over the main concern about how it would be introduced and how it would be documented throughout the docs. His current idea is to ship it as stable, but keep it as an opt-in feature for people who want to use it. Continuing Discussion Evan goes through cases on how to decide what gets released when, and how to implement those changes because there are all types of users out there. Some are early implementers, while some wait for a stable release, and others wait until there is documentation going over what the new features are and what they do. He explains that they try to release something that’s stable to try, but it wouldn’t completely change the old way of doing things. That way it keeps new ideas moving forward without completely changing the whole system, and simply adds new options. The discussion continues on this subject with the panelists all having inputs during this discussion. Audience questions Evan takes this time to answer questions from the audience watching, which covered topics like 2.6 to 2.7 migration. He also addresses what he would change from the Vue 3 release, and the different approaches he would implement. Other Interesting Points Quasar Updating to new versions of different product methods. Discussion about having Live Conferences again. Conclusion There is a lot to look forward to with the coming release of Vue 3.3. To reiterate, 3.3 will have updates to , Reactivity Transform, and introduce lazy-loading hydration. With any update, there may be questions that arise along the way. But if you have any further questions, please feel free to leave a comment here. We look forward to seeing you at our next State of Vue!...
Aug 16, 2022
5 mins
Qwik: A no-hydration instant-on personalized web application
We got together with Miško Hevery @mhevery to learn about Qwik during a JavaScript Maration event which you can go and view here Why Qwik? Qwik is a new kind of JavaScript framework with the goal of more quickly starting up applications. Many studies show that if you can deliver the content faster to the user, you'll have better conversions, better profit, and your website will be more highly rated. Existing frameworks have a hard time getting there, and the reason for that is hydration. Qwik focuses on another method called Resumability. Here is a photo to show the process: What is Hydration? Hydration is when your content pre-renders on the server side. Before you interact with the content, you actually have to download your application itself, and then, the application has to execute. When the application executes, it has to do reconciliation. In reconciliation, the application figures out where the listeners are in your page, and attaches the listeners to your DOM. When you navigate to a classical web page, you will see content delivered to you through server-side rendering. Then, a huge amount of JavaScript has to execute before the page is actually interactive. Hydration can be very expensive, and on a mobile device, it can take several seconds before the page is interactive. Qwik Goes for Resumability Resumability aims to deliver HTML, and have the application interactive immediately after delivering the HTML, basically skipping all the work involved with hydration. This allows for faster startups, and Qwik uses this with the same component mental model as other frameworks. When you're developing a Qwik application, you should think about the whole thing in pretty much the same way you would building any other web application up to now. What changes is what happens on the other side with rendering. Rendering with Qwik Existing frameworks usually care about rendering on the client side, and because of that, there are limited kinds of things that they can do. While Qwik does care about rendering on the client, it also cares about rendering on a server, serializing the data, creating and prefetching bundles, and delivering all that content to the client. Qwik tries to think about the problem of rendering end to end, and it can deliver things that other frameworks cannot. Demos Miško goes through some demos to show off the capabilities of Qwik. Simple App He starts with a very simple page: With this simple page, he shows how Qwik will only deliver JavaScript to the client if there is actually a need for it. This, he explains, is "dynamic tree shaking", and it can remove a lot of behavior that you don't normally need with such a simple page. Counter App Since there isn't much rendering to do with a simple page, Miško shows us how a counter app would work. He does this to show how Qwik would work with a more interactive page. What's interesting about this part is when you look at the kind of code that's downloaded, you'll see that the only thing downloaded is only what was necessary to process this particular event. Here, he also shows the difference in how Qwik did this process, and how other frameworks would frontload and execute everything ahead of time. This shows how it is faster at startup than other frameworks. He goes further into this app by showing the importance of Qwik, not only downloading the funciton of what the code is doing, but also, downloading the initial state. This allows Qwik to serialize the information about the button into the HTML, and it knows what piece of code to download and what state to restore. If you look at a normal framework, it lacks any infomation to tell you where the listeners are. Because of this, the framework has to download the application, and figure out where the listeners are. By flipping the way things work around, Qwik is able to serialize the information about which piece of code needs to be downloaded by lazily downloading and executing that piece of code. ToDo App Miško shows a more involved app, and progressively shows how more code downloads as you make changes, and edits within the app. He shows how instead of the code downloading eagerly, it instead only downloads as he makes changes. How does Qwik know to lazy load in the code? Qwik breaks things up into pieces. Let's say there is an app that has to render both a child and grandchild component. It starts by only re-rendering a child component at first and then, two seconds later it re-renders a grandchild component. This is a common theme for Qwik, and a developer doesn't have to write anything specific in order for the app to render in this way. The developer doesn't have to write any lazy loading behavior or relationships between components. The magic happens any time you see a $ inside of the url. It is both a development optimizer, and hint that a lazy loading event should happen. This allows the app to offload huge amounts of work from the client, and makes sure that when we navigate to the application, they have a very quick startup performance. The ways existing systems work Miško goes on to show how other common frameworks use hydration for loading apps. Monolith With this system, you get a pre-rendered application where everything is grayed out, meaning that it's not interactive. Because everything is grayed out, the browser needs to download the application code. Once everything is downloaded, the browser can execute the application, and as it is being executed, it can attach to listeners. The term hydration comes from everything turning blue once you are able to interact with these particular components. Steps two and three in this process can be expensive. So to save time, you want to skip these steps. Lazy Monolith Lazy monolith takes an SSR HTML from the server and renders it to the browser. But instead of downloading everything at once, it creates a lazy loaded boundary. The component is visible on the other side of the lazy loaded boundary, but you still have to download it. The browser has to go back, download even more JavaScript, and execute all the JavaScript. This makes lazy loaded boundaries in existing framworks useful only for components that are not currently visible on a page. If a component is already visible on a page, lazy loaded boundaries are actually detrimental because now you have to make two round trips to the server instead of one. Island There was a framework called Astro that decided to try something different. It wanted to take the application, break it out into smaller chunks, and then delay the hydration until the event happens. This is a great improvement because, intead of having one expensive thing that has to happen all at once, you have smaller things that have to happen later. The downside is that it is still using hydration. The first interaction might still be slow, and there are independent islands. Because of the independent islands, there is no easy way to communicate between them, and so you would need to sovle the island communication problem. Resumable Qwik is different than these other methods. It is still in a server-side mode where everything is pre-rendered, but it's also inactive. However, when you interact with a particular component, Qwik knows how to wake up just that component and nothing else on the page. It allows you to surgically go in and select the specific component and allow it to wake up and nothing else. It also understands relationships. If you go in and interact with a particular component, it knows to wake up another component. As you interact with specific pieces, it downloads just the necessary code and nothing else. Responding to Questions Miško then takes the opportunity to respond to questions that are asked during the streaming event. He takes time to answer the questions by showing how Qwik is different and useful from other common frameworks. Wrapping Up The website for Qwik is a great resource for anyone wanting to learn Qwik. They also have a discord community with lots of examples and tutorials on how to use Qwik. There is also a place to try things out as well. Qwik is a very different approach to how applications are built, and it should have a huge impact on startup performance of existing applications. Are you planning on trying Qwik today?...
Aug 3, 2022
8 mins