General

Testing Tesla.com with PerfBuddy: The Easy to Use, Free Performance Testing Tool from This Dot Labs

Published Jan 19, 2022

Updated Feb 13, 2023

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

We are encountering a peculiar time in the history of web development. Never have there been so many unique technologies, and advanced digital assets, all simultaneously converging to deliver the user experiences that the contemporary market demands.

Not only are our codebase systems more customizable and extensible than before, but the rapid expansion of new development technologies is affording web platforms the opportunity to shape what customers will come to expect from their online browsing experiences.

However, as our codebases become more complex, development teams will need to direct as much, if not more attention, to site performance as they do to functionality. Fortunately, This Dot Labs, is helping these teams quickly look under the hood with PerfBuddy, the free and easy-to-use browser-based performance testing tool.

Getting Started With PerfBuddy

You can begin testing your site’s performance with just one click! Simply copy/paste the page you are interested in testing, and press the “Start Test” button. No need to register or provide any further information!

After a few moments, PerfBuddy will make your report available in the browser. The reports will show distinct metrics for both mobile and desktop, and include 1-100 point scores in the areas of Performance, Best Practices, Accessibility, & SEO. Below, you can find the clear and easy-to-read report for Tesla.com.

As you can see, Tesla’s desktop website is operating smoothly, but there are some areas where the site falls behind industry averages, resulting in suboptimal performance. This may not be as significant of an issue for a site that offers information about a very specific topic/product, but with many companies competing for the attention of the same potential customers, lower than average performance and SEO metrics can result in lost business!

We were surprised to see the challenges facing Tesla’s mobile website, though their Best Practices score was perfect, and their Accessibility score was significantly higher than average.

Site Loading Metrics

As users continue reviewing their report, they can view site loading metrics for both desktop and mobile. Below, you can see metrics for desktop:

And site loading metrics for mobile as well:

Along with all of these metrics, users can look at simple definitions of each metric, with the option to learn more by following a link to explore external resources the developers found helpful and relevant.

Performance Score

Following site loading metrics, users can review specifics about their desktop site’s performance score, as seen below:

And users interested in learning details about their score can review more specific metrics in the “Performance” section of the report where they can expand each metric to learn more and discover resources for increasing their performance metrics.

And users can review the same metrics for their mobile performance as well:

Best Practice Score

Best practice scores, which evaluate performance optimizations against their potential impact on user experience, are made available for both desktop and mobile, and provides resources for optimizing site maps for large first-party JavaScript.

Accessibility Score

A site’s accessibility by web users with diverse abilities is a crucial aspect of optimal web performance. When thinking about Accessibility, we consider a site’s usability for those with vision, as well as motor-ability differences, including those using adaptive technologies to interact with a user interface. Fortunately, PerfBuddy evaluates a site’s accessibility, providing metrics that allow users to identify pain points that impede its performance for the widest possible user base.

First, users can see an overall score for both desktop and mobile:

As well as specific impediments that developers can improve in order to raise their accessibility score. In Tesla’s instance, both desktop and mobile suffer from the same nonoptimal features:

SEO Score

Finally, users can review their site’s Search Engine Optimization score, which provides specific site features that may be improved to increase their site’s search relevance for both desktop and mobile:

And below these scores, users can expand various boxes to review the specific site features that can be changed to improve SEO as well as links to resources for how to effect these changes:

PerfBuddy is Here to Help

PerfBuddy was designed for developers by developers, and This Dot Labs is thrilled to make this accessible tool available to the web development community for free and without any commitments.

It is our hope that developers are able to use PerfBuddy to improve their websites by leveraging the resources made available to them in their unique web performance reports, or utilize the reports’ clear and concise language to advocate for performance investment within their own organizations. However, some users may find that they need help implementing the improvements needed to boost their performance scores and improve the experience of their users, and so users are encouraged to reach out to the team at This Dot Labs if they need any help understanding their reports or implementing performance optimizations.

Though there is a form for contacting the team on every report, users may also contact the team for further assistance by emailing hello@thisdot.co.

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)

Tracy Lee
Partner, This Dot Google Developer Expert (Angular, TC39, Web) RxJS Core Team & Lead for RxJS Learning Team Contributor to Angular, RxJS, EmberJS

Key Strengths:
- Teaching developer relations strategies
- Influencer marketing
- Developing brands
- Community strategies and maintenance
- Creating product launch strategies
- Leading marketing operations efforts & standards
- Effective conference presence & speaking strategies
@ladyleet @ladyleet

Introduction to Zod for Data Validation

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

Nov 15, 2024

7 mins

JavaScriptZod

Fly.io for Easier Cloud Deployment with Annie Sexton

Annie Sexton, Developer Advocate at Fly.io, to discuss Fly.io’s approach to simplifying cloud deployment. Annie shares Fly.io's unique position as a public cloud that offers the flexibility of infrastructure control with a streamlined developer experience. They explore Fly.io’s private networking and distributed app capabilities, allowing developers to deploy applications close to users worldwide with ease. Annie also addresses common challenges in distributed systems, including latency, data replication, and the balance between global reach and simple, single-region projects. Chapters: - 00:00 - 01:32 Introduction to the Modern Web Podcast and Guests - 01:33 - 04:00 Overview of Fly.io and Annie’s Role as Developer Advocate - 04:01 - 06:35 What Makes Fly.io Stand Out Among Cloud Platforms - 06:36 - 08:57 Distributed Applications: Benefits and Use Cases - 08:58 - 11:28 Understanding Distributed Web Servers and Private Networking - 11:29 - 13:49 Challenges in Distributed Data and Replication Techniques - 13:50 - 16:12 Fly.io’s Unique Solutions for Data Consistency - 16:13 - 18:34 When to Consider a Distributed Setup for Your Application - 18:35 - 20:35 Tools and Tips for Evaluating Geographical Distribution Needs - 20:36 - 22:22 Simplifying Global Deployment with Fly.io’s Command Features - 22:23 - 24:18 Considerations for Latency and Performance Optimization - 24:19 - 26:45 Balancing Simplicity with Advanced Control for Developers - 26:46 - 29:04 Easy Deployment for Hobbyists and Smaller Projects - 29:05 - 31:27 Getting Started on Fly.io with Fly Launch - 31:28 - 33:48 Developer Advocacy and Meeting Diverse Needs in the Cloud - 33:49 - 36:15 Catering to Beginners and Experienced Developers Alike - 36:16 - End Closing Remarks and Where to Find Fly.io and the Hosts Follow Annie Sexton on Social Media Linkedin: ⁠https://www.linkedin.com/in/annie-sexton-11472a46/⁠ Github: ⁠https://github.com/anniebabannie⁠ Sponsored by This Dot: thisdot.co...

Nov 6, 2024

2 mins

Software EngineerJavaScript

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Although Developer Relations (DevRel) defies traditional marketing strategies, prioritizing enhancing developer satisfaction ahead of promoting numbers that contribute to a sales funnel, it is still possible for DevRel teams to fail at delivering desired business objectives. And unfortunately, more often than not, this leads to the dissolution of DevRel efforts, and sometimes even role elimination. Below, I’ve compiled a list of five of the top reasons why DevRel teams fail. 1. Lack of Leadership Buy-In DevRel requires buy-in and support from executives and stakeholders within the company. Without buy-in, being able to work cross-functionally across the organization, get access to data needed for measuring success, have the ability to influence change within the organization, or get the budget for necessary activities to engage developers will be impossible. I asked Jason Lengstorf, the host and founder of Learn With Jason and previously on the Developer Relations team at Netlify and Gatsby, where he has seen companies fail at DevRel before: “Companies that want to invest in DevRel can collect as many well-known developers as they can, but giving them zero dollars and zero autonomy will force teams to rage quit or become content farms because that’s all you can do with no budget.” Other examples are departments not willing to share or give data that helps enable DevRel to understand the metrics they need to effectively baseline and track the success of their efforts. By not doing so, the DevRel team will not be able to justify their work to leadership, which will lead to those positions being cut first when budget cuts come around. Chris Woodruff, Founder of Advocatus, a Developer Relations consultancy, says “DevRel is seeing a lot of layoffs. It’s the easiest team for management to let go because they don’t fully understand the ROI and metrics. These are the holy grails of DevRel, and because they do not understand, they will always be the first teams to let go if management can’t see the actual return or how it affects the bottom line.” 2. Company Culture Fit If an organization's culture does not value collaboration and resists the presence of a DevRel team, DevRel will not be able to effectively advocate for developers or help teams be more successful with their target audience. Francesco Tisiot, Senior Developer Advocate at Aiven, an open-source data platform that makes setting up cloud databases simple, shared one of his experiences in his Developer Relations career. “I was one of the first DevRel hires in a company and we were in the marketing organization. Initially, there was pushback from engineering and product teams on our product feedback and feature requests since we weren't seen as experts. But, DevRel is about breaking barriers and building bridges, so, in leading by example, we demonstrated our technical knowledge and now have a strong impact on all the teams.” Michael Liendo, Senior Developer Advocate at AWS, an online platform by Amazon that provides scalable and cost-effective cloud computing solutions, shared how he was able to find the company culture fit within organizations he has served in the past. Being in a position of Developer Advocacy, and quite literally trying to advocate for developers that use the platform, he says, “Some of the biggest challenges for DevRel are actually internal. Engineers at many companies often focus on one piece of the product. As they're testing features, they may be creating workarounds without realizing they're workarounds. This means they often miss what a proper Developer Experience flow looks like. I've had to push for them to include me in design meetings, and get them to understand that I'm the Lorax--I speak for the community! A phrase I have been known to say is ‘this solves the problem, but it's not a solution’. I'm known for having a high bar for what is considered ‘good enough’ and though the end result is accumulated trust, it's a challenge to get there.” 3. Operating in Isolation DevRel cannot operate in isolation without integration with development, marketing, product teams, sales, or a subset of these. The team will struggle to make a significant impact. DevRel requires a collaborative approach and alignment and synergy with other teams. Francesco Ciulla, Developer Advocate at daily.dev, a professional network for developers that provides the latest tech news and articles, shares his thoughts on how DevRel organizations can be successful within larger organizations: “DevRel organizations can thrive within larger organizations by establishing clear communication channels and fostering meaningful collaborations. They must align their objectives with the company's goals and illustrate their value by sharing tangible outcomes from developer engagement.” 4. Lack of Strategy Proceeding into DevRel without a clear strategy will make it difficult for a DevRel team to establish its purpose within an organization and set priorities that will make an impact. There will not be a clear vision the team can drive towards, leading to wasted efforts and the inability to produce tangible outcomes. If DevRel does not have any goals set, they can only do their best to assume what efforts they should invest in to provide value to the organization. Worst yet, if they do not have any goals set, they may not choose to focus on providing value to the organization, but to a community that the organization has no interest in. Many DevRel experts have seen this happen time and time again in the community, and are always left scratching our heads. Many times, the “strategy” for an organization is to hire DevRel, but that is where the strategy stops. Decision-makers want DevRel professionals to come in and just “do what they do best”. Unfortunately, when decision-makers say this, they typically have an idea of what outcomes they want DevRel to drive, but don’t want to share those thoughts because they feel like DevRel professionals should know what to do. Expectations left open to interpretation often lead to a poor impression of the performance of the DevRel team by decision-makers, and those teams are never able to establish a sense of trust or direction within that organization. Jeremy Meiss, former Director of Developer Relations at CircleCI, says, “One of the biggest problems we have seen in this industry is the startups that were counseled by their VC, founders, or board that they need a DevRel team because the other similar companies had one and it was great for them. They push for it, and one of the early hires is DevRel. Generally, that DevRel hire is someone relatively new in the industry, so you can coax them to start at a new company without clear goals or objectives. New hires like this come in without a lot of experience in the field of DevRel and have not experienced it at different levels of companies. They are heavily pushed by marketing, the CEO, the CTO, and other departments into thinking DevRel should look a certain way, but don’t have the foundational knowledge to be able to push back because they are not yet in this area.” Jeremy’s illustrative explanation of why a lack of strategy ultimately results in the failure of a DevRel team within an organization is one that is common across many devtool startups that have popped up in recent years. 5. Lack of Metrics and Reporting A well-rounded set of DevRel metrics typically comes from multiple areas of the organization, whether that be marketing, sales, product, customer success, or customer support. Without free access to cross-functional team data, it is difficult to show the value and ROI of DevRel. Establishing a baseline set of metrics if you’re new within an organization, or understanding the baseline metrics that currently exist is critical in ensuring the success of your job in DevRel. Tessa Mero, Head of Developer Relations at Appwrite, has a very specific set of metrics her team focuses on. She shared a few of those metrics: - Growth of our GitHub Repo (stars) - Growth of our Discord Community - Improved engagement in Discord community - Growth of our Twitter followers and engagement - Growth of our Appwrite Cloud developers - Number of views or impressions on any video and written content, whether it's internal or externally created - Amount of content created weekly (written or video) - Number of projects created with Appwrite for Hackathon sponsorships - Number of attendees / questions at a conference talk - Number of connections at conferences - Number of community support questions answered, improving rate of responses AND rate of how fast we respond, in all public forums - Number of support tickets responded to - Number of community feedback taken and moved into our DX/Product discussions - Number of feedback from UI/UX perspectives and working with design team to follow up with the devs/users with what we did with the feedback - Number of engagement/activity from our Appwrite heroes/ambassadors This is just one example of and a subset of metrics a DevRel team should consider tracking, but what you track and how you track it is dependent on your goals and the product. Metrics and what your leadership considers a good ROI can vary greatly from organization to organization. I spoke to another Developer Relations expert in the industry and she shared her experience with the company she just left and the reason she left - and it was focused around metrics. She was initially interested in joining the team because of the lack of metrics. However, over time, as she got more experience and as she became more visible, her workload became difficult to prioritize. Since there were no metrics, there were no objectives to measure against to say what was good and what was bad. She felt like she didn’t know what she was doing well or not doing well. Once metrics began to be implemented, the company started pushing her to do more, and she had nothing to push back with because the high-level goals were not there. There was no way to prioritize the workload. The company started tracking things like page hits, unique visitors, unique views of videos, number of subscribers, activity on twitter, and other similar numbers, but it was hard to tie any of these back to the ROI for the company. How do you quantify and determine if 100 new subscribers on YouTube is better than 100 new subscribers on twitter? If you can’t quantify it, how do you prioritize it? What Successful DevRel Teams Do Differently With the nature of DevRel and the multitude of levers and factors that determine success and failure, it’s important to allow space for a team or set of individuals to experiment and iterate before making judgment calls. One company that serves millions of developers on its platform is starting up a new meetup program and testing the ROI of sponsoring meetups around the world. Since they are in the testing and experimentation phase, they don’t yet know how to measure success, and that is clear to leadership. The current strategy is sponsoring local meetups for a few months and seeing what the result is. Why are they so seemingly laid back in their approach? Is it the right approach? The reason for the relaxed nature of the testing phase is that they don’t want to be pushy to the meetup organizer to find something out or measure something. They are not expecting anything, but will evaluate what metrics they could use to establish success criteria. This approach is a thoughtful and empathetic one, and clearly, the DevRel team has an understanding of how to approach community members in a way that will not turn them off. Internally, the simple numbers they are looking at are the number of RSVPs, the number of attendees that show up, and the difference between the two. DevRel is naturally iterative and requires a team to experiment, test, and refine their strategies. Effectively engaging developers is not black and white, and a strategy that works for one community or company may not necessarily work for another. Furthermore, building domain expertise and gaining a deep understanding of the developer community they serve takes time. Experimentation and iteration help teams refine their knowledge, identify patterns, and develop strategies that resonate with developers. This expertise becomes an asset in driving long-term success. It’s also important to acknowledge that building domain expertise within a segment as well as building relationships and trust with developers in that segment takes time. The technology landscape changes quickly and new technologies are being released weekly. Developer sentiment is fickle and changes just as quickly regarding favored approaches and products. That being said, the above pitfalls remain common causes for DevRel teams to fail, and by remaining mindful of and vigilant against them, DevRel teams both new and old can succeed in supporting key business objectives like developer retention, community growth, and product development....

Feb 14, 2024

9 mins

DevRel

Svelte 5 is Here!

Svelte 5 was finally released after a long time in development. Fortunately, we've been able to test it for some time, and now it has a stable release. Let's dig into its features and why this is such a significant change, even though Svelte 4 code is almost 100% compatible. Svelte syntax everywhere This is one of my favorite additions. Previously, Svelte syntax was limited to a component element. Refactoring code from a component and moving it to a JavaScript file worked differently. Now you can use the .svelte.js or .svelte.ts extension, which allows you to use the same syntax everywhere. It's important to note that it's a way to express that this is not just JS, and what you write may be compiled to something else, just like .svelte files are not just html even though they look very similar. Runes The introduction of runes is one of the most significant changes in Svelte. Many users felt attracted to variables being instantly reactive in previous versions. ` There was, however, a lot of magic underneath and a considerable amount of work from the compiler to make it behave reactively. $state In Svelte 5, a reactive variable has to be explicitly declared using the $state rune, which brings a clear distinction between what is reactive and what isn’t. ` In the previous code, $state is not an actual function being called; it's a hint for the compiler to do something special with this declaration. Rune names always start with a dollar sign ($) and do not need to be imported. However, there’s much more to the changes than just the way we declare reactive variables. Runes bring a lot of new features that make Svelte 5 a great improvement. In Svelte 5, objects or arrays use Proxies to allow for granular reactivity, meaning that individual properties in an object are reactive, even if they are nested objects or arrays. If you modify a property, it will only update that property and will not trigger an update on the whole object. It also supports triggering updates when methods like array.push are called. In previous versions, an assignment was required to trigger an update: ` To have a similar behavior of svelte 4 (no deep reactivity), use the $state.raw() rune. This syntax of .* is common for related features of a rune: $state.raw() will require an assignment to trigger reactivity. ` Because proxies are used, you may need to extract the underlying state instead of the proxy itself. In that case, $state.snapshot() should be used: ` $derived We will use $derived and $derived.by to declare a derived state. The two runes are essentially the same, except one allows us to use a function instead of an expression, allowing for more complex operations to calculate the derived values. ` $effect Effects are useful for running something triggered by a change in state. One of the things you'll note from the $effect rune is that dependencies don't need to be explicit. Those will be picked from reactive values read synchronously in the body of the effect function. ` Something to bear in mind is that these dependencies are picked each time the effect runs. The values read during the last run become the dependencies of the effect. ` Depending on the result of the random method, foo or bar will stop being a dependency of the effect. You should place them outside the condition so they can trigger reruns of the effect. *Variants* of the effect rune are $effect.pre, which runs before a DOM update, and $effect.tracking(), which checks for the context of the effect (true for an effect inside an effect or in the template). $props This rune replaces the export let keywords used in previous versions to define a component's props. To use the $props syntax, we can consider it to return an object with all the properties a component receives. We can use JavaScript syntax to destructure it or use the rest property if we want to retrieve every property not explicitly destructured.. ` $bindable If you want to mutate a prop so that the change flows back to the parent, you can use the $bindable prop to make it work in both directions. A parent component can pass a value to a child component, and the child component is able to modify it, returning the data back to the parent component. ` $inspect The $inspect rune only works in dev mode and will track dependencies deeply. By default, it will call console.log with the provided argument whenever it detects a change. To change the underlying function, use $inspect.with().with): ` $host The host rune gives access to the host element when compiling as a custom element: ` ` Other changes Another important change is that component events are just props in Svelte 5, so you can destructure them using the $props() rune: ` A special children property can be used to project content into a component instead of using slots. Inside the components, use the [@render[(https://svelte.dev/docs/svelte/@render) tag to place them. ` Optional chaining (?.) prevents from attempting to render it if no children are passed in. If you need to render different components in different places (named slots before Svelte 5, you can pass them as any other prop, and use @render with them. Snippets Snippets allow us to declare markup slices and render them conveniently using the render tag (@render). They can take any number of arguments. ` Snippets can also be passed as props to other components. ` ` Conclusion Some exciting changes to the Svelte syntax were introduced while, at the same time, maximum compatibility efforts were made. This was a massive rewrite with numerous improvements in terms of performance, bundle size, and DX. Besides that, a new CLI has been released, making the whole experience of starting a project or adding features delightful. If you haven't tried Svelte before, it's a great time to try it now....

Nov 27, 2024

4 mins

Svelte

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.

Testing Tesla.com with PerfBuddy: The Easy to Use, Free Performance Testing Tool from This Dot Labs

Site Loading Metrics

Performance Score

Best Practice Score

Accessibility Score

SEO Score

PerfBuddy is Here to Help

Tracy Lee

You might also like

Introduction to Zod for Data Validation

Fly.io for Easier Cloud Deployment with Annie Sexton

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Svelte 5 is Here!

Let's innovate together!

You might also like

Introduction to Zod for Data Validation

Fly.io for Easier Cloud Deployment with Annie Sexton

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Svelte 5 is Here!