Javascript

How to add Dark Mode in your Web Application

Published Dec 26, 2023

Updated Dec 26, 2023

9 min read

How to Create Dark/Light Mode in your JavaScript project?

Providing our visitors with the ability to toggle between white and dark themes has become one of the most important features of all time. In this article, we will cover the requirements to develop a persistent theme for your website successfully.

The code provided as part of this article will be technology agnostic and can be used with all major front-end frameworks such as Vue, React, or Svelte.

TL;DR If you are in a rush and just want access to the code, you can grab it from this Stackblitz: Light / Dark theme functionality in Vanilla JS.

What is White/Dark Mode

Before we jump into the code, we should first explain what the meaning behind the feature name "White/Dark Mode is".

This feature was first introduced in our Operating system by allowing users to change their default theme into Dark Mode, After this, Dark Mode has slowly made its way into our most used applications and websites as users expected to have a consistent look from their native application to Web App equivalent.

Providing "White/Dark mode" in your site means giving the user the ability to toggle their theme to either align to the Operating system theme settings or override it from the Web App UI.

The above example shows the feature on thisdot.co triggered by the little toggle button available within the main navbar.

Implementing Dark Mode with Javascript

This feature has two main implementation levels. The first is the ability to assign the theme directly from the Operating System preferences, while the second combines the feature of the first plus the ability to override that feature from the UI.

Some websites just offer the first option and allow the site to emulate the OS preferences, even if this is mostly fine for most users, in this post, we will develop the second option as it is the most complicated approach and, therefore the most complete.

The development of this feature is going to be divided into the following steps:

Ensure CSS variables drive our application
Create a second set of variables for a dark theme
Create logic to read user preferences
Create logic to override the theme preference
Make our theme selection persistent

Let's dive into the code with our first step and initialize our application.

Move all styles into CSS variables

We are going to start our application by initializing a plain VanillaJs Stackblitz. This creates a simple project with an index.js file that includes our HTML and a style.css file that includes our global styles.

To be able to have a good starting point for our post, we are going to add some more elements on the main page of the app and then define some CSS variables to make our example more appealing.

First, we are going to clean our index.js and just leave the style import:

// Import stylesheets
import './style.css';

Then, we are going to change our index.html with the following content:

<body>
 <span>
   <h1>Heading 1</h1>
   <p>Paragraph</p>
 </span>
 <picture>
   <img width="100" src="https://www.thisdot.co/img/header-light-theme.webp">
 </picture>
</body>

And finally, define some CSS variables and styles in style.css:

:root{
 --text-primary:red;
 --text-secondary: grey;
 --background-color: white;
}
body{
 display: flex;
 background-color: var(--background-color);
}
h1 {
 color: var(--text-primary);
}
p {
 color: var(--text-secondary);
}

If you are new to CSS variables, you can read more about them in the MDN docs: Using CSS custom properties. There is one point to clarify regarding CSS variables and their naming convention. Because the color held within our variables will change (for example from red to blue), the variable name should be based on the color "role" (eg primary, shadow, border") and not on the actual color "blue, green".

In our example, we can see this naming convention in action as the variables are called "primary", "secondary" and "background".

The above should output a very simple but colorful design:

Create a second set of variables for the dark theme

Now that our basic application is set, it is time to create a second set of variables to be able to define the difference between the light and dark theme.

As you may notice, the CSS variables are not a must for this to work, but having all the variables set makes the maintenance of the site much easier than having to update color and styles scattered around.

We are returning to our style.css file and updating a few of the CSS properties. These variables will just be updated if the body has a specific class dark associated with it:

:root {
 --text-primary: red;
 --text-secondary: grey;
 --background-color: white;
}
body.dark {
 --text-primary: white;
 --background-color: black;
}

As the above code shows, because we are just overriding the variables, we do not actually need to redeclare them all and we can just declare the variables that we wish to update.

If we would go back and add a class of "dark" to our body in index.html we would see the following output: Example site on dark theme

As you can see, both white themes are fully set up and working. All that is left is creating the logic that can handle the theme toggle, but before we do so, there is one more change to add to our CSS.

In fact, some components, such as form controls and scrollbar, use a property called "color-scheme" to change their theme, to give this a try, we will add an in our HTML:

<body class="dark">
 <span>
   <h1>Heading 1</h1>
   <p>Paragraph</p>
   <input type="text" />
 </span>
 <picture>
   <img width="100" src="https://www.thisdot.co/img/header-light-theme.webp" />
 </picture>
</body>

Then, let's see how this would look in our design:

The input is showing a white theme even if the dark theme is selected, and this is happening because we are not changing the "color-scheme" that is what is used for the form input.

Let's fix this by adding another CSS variable and a CSS declaration within our body:

:root {
 --text-primary: red;
 --text-secondary: grey;
 --background-color: white;
 --color-scheme: light;
}
body.dark {
 --text-primary: white;
 --background-color: black;
 --color-scheme: dark;
}
body {
 display: flex;
 background-color: var(--background-color);
 color-scheme: var(--color-scheme);
}
h1 {
 color: var(--text-primary);
}
p {
 color: var(--text-secondary);
}

With the above code, the "color-scheme" variable will be changed to align with our overall theme, as shown below: Input field showing dark theme

Note that settings can be overridden on a component-by-component level. In fact, if you would like to always display the white theme for a button or field, you can just redeclare the "color-scheme" and apply it to the CSS selection of your choice.

It is now time to move forward and include some JS to make the toggling automatic.

Create logic to read user preferences

It is now time to write some JavaScript and make our application dynamic. In this first logical step, we are going to read our Operating System color preference and use it to toggle the class assigned to our body.

To do so, we are going to use the "matchMedia" method to read the "prefer-color-scheme" just like shown in the code below:

const readSystemColorPreferences = () => {
 if (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) {
   return "dark";
 } else {
   return "light";
 }
}

The next step is to assign or remove the class from our body depending on the preferred scheme:

var preferredScheme = readSystemColorPreferences();

const updateScheme = (overriddenScheme) => {
   if( preferredScheme === "dark" ) {
   document.querySelector('body').classList.add("dark");
   } else {
   document.querySelector('body').classList.remove("dark");
   }
};
updateScheme();

Let's see if this works. If you are on Mac you can change the preferences by following the following steps:

System settings
Appearance
Change the appearance

If you change the preferences and refresh your application, you should be able to see the application changing on the fly.

Create logic to override the theme preference

Having to change the full OS just for a single Website theme preference may be a little bit too much. So, in this step, we are going to enhance our logic to be able to override the preferences.

First, we are going to add a simple button in the HTML called Toggle Theme:

<body class="dark">
 <span>
   <h1>Heading 1</h1>
   <p>Paragraph</p>
   <input type="text" />
   <button>Toggle theme</button>
 </span>
 <picture>
   <img width="100" src="https://www.thisdot.co/img/header-light-theme.webp" />
 </picture>
 <button>Toggle theme</button>
</body>

Now, it is time to update the logic. First, we need to allow a way to override the preferences. We can do this by adding an argument to our updateScheme function:

let selectedTheme;
const updateScheme = (overriddenScheme) => {
 const preferredScheme = readSystemColorPreferences();
 selectedTheme = overriddenScheme || preferredScheme;
 localStorage.setItem("selectedTheme", selectedTheme);
 if (selectedTheme === 'dark') {
   document.querySelector('body').classList.add('dark');
 } else {
   document.querySelector('body').classList.remove('dark');
 }
};
updateScheme();

The above code just adds a global variable called selectedTheme and then, as we previously mentioned, adds a parameter of overrideScheme to our method and finally makes sure we use this variable if available selectedTheme = overriddenScheme || preferredScheme.

The next step requires us to be able to update our selectedTheme on a button click:

document.querySelector('button').addEventListener('click', () => {
 var newScheme = selectedTheme === 'dark' ? 'light' : 'dark';
 updateScheme(newScheme);
});

With the above code added to our application, we could override the system preferences, but unfortunately, our work is not completed. The logic we wrote above is not persistent, and the theme selection will be lost if we refresh the page.

Make our theme selection persistent

In this last step, we are going to save our selectedTheme in localStorage using the documentation provided in the MDN documentation: Local Storage.

First, let's save the selectedTheme into local storage by using localStorage.setItem:

const updateScheme = (overriddenScheme) => {
 const preferredScheme = readSystemColorPreferences();
 selectedTheme = overriddenScheme || preferredScheme;
 localStorage.setItem('selectedTheme', selectedTheme);

 if (selectedTheme === 'dark') {
   document.querySelector('body').classList.add('dark');
 } else {
   document.querySelector('body').classList.remove('dark');
 }
};

Then make sure we read this value on load using localStorage.getItem:

const savedTheme = localStorage.getItem('selectedTheme');
updateScheme(savedTheme);

After the above changes, you should be able to toggle the theme, refresh the page and be able to see the correct theme loaded up for you.

NOTE: Due to the way StackBlitz loads the JS, there will be a small flash, but if you would place this code in the head that flash should be extremely minimal.

What about the images

You may have noticed that we have left the image unchanged between the different themes. This was, unfortunately not by choice, as there is no native way to swap images when using class-based theming.

If you were just to implement the theme based on System Preference, you could declare different images using the media query (prefers-color-scheme: dark). This would allow you to declare images like this:

<picture>
   <source srcset="night.jpg" media="(prefers-color-scheme: dark)">
   <img src="day.jpg">
</picture>

The above code will show day.jpg if your theme settings are light or night.jpg if dark. If you would like to implement something similar with a class-based theme, you will have to create a custom image component in your framework of choice that loads the correct theme, but this is outside this tutorial's scope.

Conclusion

It is now time to conclude this post and leave you to go and apply what we learned in your Web applications. Implementing this feature is quite simple, and it helps to improve your user's experience.

The code we have written above is available on StackBlitz: Light / Dark theme functionality in Vanilla JS. But let's see it in action in:

So, in this article, we have introduced CSS variables and ensured our design colors were driven solely by them. We created an override for this variable using a class-based approach; we then learned how some elements, such as input fields, can change the theme using the "color-theme" property.

We then moved into the JS, where we used the media query "prefers-color-scheme" to read the user Operating System theme preferences and, last but not least, created a live toggle that would create and save a personal preference in LocalStorage.

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)

Simone Cuomo
Software Architect, Mentor, Speaker and Writer. Passionate about all aspect of web development, with a special love for VueJs
@zelig880 @zelig880

How to Truncate Strings Easily with CSS

You'll often need to truncate text when working with user interfaces, especially when displaying content within a limited space. CSS provides a straightforward way to handle this scenario, ensuring that long text strings are cut off gracefully without affecting the overall layout. CSS Truncation Techniques Single-Line Truncation If you want to truncate a single line of text, CSS provides a simple solution. The key properties to use here are overflow, white-space, and text-overflow. ` Explanation of properties: * white-space: nowrap: This ensures the text stays on a single line, preventing wrapping. * overflow: hidden: This hides any content that overflows the container. * text-overflow: ellipsis: This adds the ellipsis (…) at the end of the truncated text. Multi-Line Truncation While truncating a single line of text is common, sometimes you may want to display multiple lines but still cut off the text when it exceeds a certain number of lines. You can use a combination of CSS properties such as -webkit-line-clamp along with the display and overflow properties. ` Live example: Explanation of properties: * display: -webkit-box: This is a legacy flexbox-like display property that works with the -webkit-line-clamp property. * -webkit-line-clamp: Specifies the number of lines to show before truncating. * -webkit-box-orient: vertical: Ensures the box is laid out vertically for proper multi-line truncation. * overflow: hidden: Prevents content overflow. * text-overflow: ellipsis: Adds an ellipsis after the truncated content. Why Use CSS for Text Truncation Over JavaScript Techniques? While it’s possible to truncate text using JavaScript, CSS is often a better choice for this task for several reasons. Let's explore why CSS-based truncation techniques are generally preferred over JavaScript. Performance Efficiency CSS operates directly within the browser's layout engine, meaning it doesn’t require additional processing or event handling as JavaScript does. When using JavaScript to truncate text, the script needs to run on page load (or after DOM manipulation), and sometimes, it needs to listen for events such as window resizing to adjust truncation. This can introduce unnecessary overhead, especially in complex or resource-constrained environments like mobile devices. CSS, on the other hand, is declarative. Once applied, it allows the browser to handle text rendering without any further execution or processing. This leads to faster load times and a smoother user experience. Simplicity and Maintainability CSS solutions are much simpler to implement and maintain than their JavaScript counterparts. All it takes is a few lines of CSS to implement truncation. In contrast, a JavaScript solution would require you to write and maintain a function that manually trims strings, inserts ellipses, and re-adjusts the text whenever the window is resized. Here's the JavaScript Truncation Example to compare the complexity: JavaScript Truncation Example: ` At the example above, we truncated the text to 50 characters which may be 1 line on large screens and 6 lines on mobile and in that case we will need to add more code to truncate it responsively. As you can see, the CSS solution we used earlier is more concise and readable, whereas the JavaScript version is more verbose and requires managing the string length manually. Responsiveness Without Extra Code With CSS, truncation can adapt automatically to different screen sizes and layouts. You can use relative units (like percentages or vw/vh), media queries, or flexbox/grid properties to ensure the text truncates appropriately in various contexts. If you were using JavaScript, you’d need to write additional logic to detect changes in the viewport size and update the truncation manually. This would likely involve adding event listeners for window resize events, which can degrade performance and lead to more complex code. CSS Example for Responsive Truncation: ` To achieve this in JavaScript, you’d need to add more code to handle the width adjustments dynamically, making it more complex to maintain and troubleshoot. Separation of Concerns CSS handles the presentation layer of your website, while JavaScript should focus on dynamic functionality or data manipulation. By keeping truncation logic within your CSS, you're adhering to the principle of separation of concerns, where each layer of your web application has a clear, well-defined role. Using JavaScript for visual tasks like truncation mixes these concerns, making your codebase harder to maintain, debug, and scale. CSS is purpose-built for layout and visual control, and truncation is naturally a part of that domain. Browser Support and Cross-Browser Consistency Modern CSS properties like text-overflow and -webkit-line-clamp are widely supported across all major browsers. This means that CSS solutions for truncation are generally consistent and reliable. JavaScript solutions, on the other hand, may behave differently depending on the browser environment and require additional testing and handling for cross-browser compatibility. While older browsers may not support specific CSS truncation techniques (e.g., multi-line truncation), fallback options (like single-line truncation) can be easily managed through CSS alone. With JavaScript, more complex logic might be required to handle such situations. Reduced Risk of Layout Shifting JavaScript-based text truncation risks causing layout shifting, especially during initial page loads or window resizes. The browser may need to recalculate the layout multiple times, leading to content flashing or jumpy behavior as text truncation is applied. CSS-based truncation is applied as part of the browser’s natural rendering flow, eliminating this risk and ensuring a smoother experience for the user. Conclusion CSS is the optimal solution for truncating text in most cases due to its simplicity, efficiency, and responsiveness. It leverages the power of the browser’s rendering engine, avoids the overhead of JavaScript, and keeps your code clean and maintainable. While JavaScript truncation has its use cases, CSS should always be your go-to solution for truncating strings, especially in static or predictable layouts. If you like this post, check out the other CSS posts on our blog!...

Sep 13, 2024

4 mins

CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Understanding the Difference Between :focus and :focus-visible in CSS I have learned my fair share about the importance of keyboard accessibility, so I know that visual indication of the focused element is very important. But the well-known :focus pseudo-class is not always the best fit for this job. That's where :focus-visible comes in. Let's look at the differences between these two pseudo-classes and explore the best practices for using them effectively. What is the :focus Pseudo-Class? The :focus pseudo-class is a CSS selector that applies styles to any element that receives focus, regardless of how that focus was triggered. This includes focus events from keyboard navigation, mouse clicks, and touch interactions. Example Usage of :focus ` In this example, the button will display a blue outline whenever it is focused, whether the user clicks on it with a mouse, taps it on a touchscreen, or navigates to it using the keyboard. What is the :focus-visible Pseudo-Class? The :focus-visible pseudo-class is more specialized. It only applies styles to an element when the browser determines that the focus should be visible. This typically occurs when the user navigates via the keyboard or assistive technologies rather than through mouse or touch input. Example Usage of :focus-visible ` Here, the button will only show a blue outline when focused through keyboard navigation or another input method that usually requires visible focus indicators. Key Differences Between :focus and :focus-visible :focus - Behavior: Applies to any element that receives focus, regardless of the input method. - Use Cases: Ensures that all interactions with the element are visually indicated, whether by mouse, keyboard, or touch. :focus-visible - Behavior: Applies styles only when the focus should be visible, such as using a keyboard or assistive technology. - Use Cases: Ideal for scenarios where you want to provide focus indicators only to keyboard and assistive technology users while avoiding unnecessary outlines for mouse and touch users, typically required by design. Accessibility Implications :focus - Pros: - Guarantees that all users can see when an element is focused, which is critical for accessibility. - Cons: - Can lead to a suboptimal experience for mouse users, as focus styles may appear unnecessarily during mouse interactions. :focus-visible - Pros: - Enhances user experience by showing focus indicators only when necessary, thus keeping the interface clean for mouse and touch users. - Tailors the experience for keyboard and assistive technology users, providing them with clear visual cues. - Cons: - Additional considerations may be required to ensure that focus indicators are not accidentally omitted, especially in older browsers that do not support :focus-visible. - There may be cases where you want to show focus indicators for all users, regardless of input method. Best Practices for Using :focus and :focus-visible To achieve the best accessibility and user experience, combining both :focus and :focus-visible in your CSS is often a good idea. Combining :focus and :focus-visible ` Here is a Stackblitz example of what such styling could look like for you to try out and play with. Additional Tips - Test with Keyboard and Assistive Technology: Ensure that your web application is navigable using a keyboard (Tab, Shift + Tab, etc.) and that focus indicators are visible for those who rely on them. It's never a bad idea to include accessibility testing in your e2e testing suite. - Provide Clear Focus Indicators: Make sure that focus indicators are prominent and easy to see. A subtle or hard-to-spot focus indicator can severely impact accessibility for users who rely on keyboard navigation. Conclusion The :focus-visible pseudo-class offers a more refined way to manage focus indicators, improving accessibility and user experience, particularly for keyboard and assistive technology users. By understanding the differences between :focus and :focus-visible, and applying best practices in your CSS, you can create more accessible and user-friendly web applications. Remember, accessibility should never be an afterthought. By thoughtfully applying focus styles, you ensure that all users, regardless of how they interact with your site, can easily navigate and interact....

Nov 8, 2024

3 mins

AccessibilityCSSPlaywright

History of Mobile Web Development and the rise of PWA

If you're in your thirties, like me, or older, you know that mobile phones have not always been so ubiquitous. In this article, we are going to cover the history of the mobile phone, and more specifically "Web Development", by focusing on the rise and benefits of PWAs. The article is going to be divided in the following sections: - History of the Mobile Phone - The evolution of Mobile Web Development - The Rise of PWA (Progressive Web App) History of the Smart Phone It is hard to remember a time when we all lived without smart phones in our pockets. How about when mobile phones could not be called "smart" since they had a single purpose: to make calls? Let's travel in time, and cover the main milestones that shaped our beloved handsets. March 1991 Even if it feels like ancient history, the story of mobile phones starts just shy of the millenium's turn. Phones started to become everyday accessories in the last decade of the 20th Century, with the first ever phone call on GSM network being made on March 1991. 1996 During their first few years of existence, phones rapidly advanced. In 1996, Nokia released the first phone with access to the "mobile web". 1998 1998 did not have any specific technological breakthroughs, but in my opinion, it marks the creation of a new industry: premium downloadable content. You may be curiuous to know which app was the first to be downloaded, but here, we are not talking about any app, as the phones did not even have web browsers yet. The first content to be sold were ringtones. This is one of the most succesful (and annoying) ringtone of the early 2000s "crazy frog": {% youtube awAKzaGrrbY %} 1999 Right before the end of the decade, phones reached another very important milesone. In this year, the first version of a mobile specific web browser was created, and our handsets were connected to the World Wide Web. 2000-2007 If I would have to list all the great phones and enhancements of these few years, this blogpost would become a book. Phones started to get much smarter. There were multiple improvements, from the size of the devices, to the signal coverage, all the way up to improved services, such as colored screens and cameras. All of the above made consumers interested in the products, and more and more people started to use them. Making it a very profitable market to invest in. 2007 The fast growth of this market made Apple decide to move into this growing sector. In the year 2007 Steve Jobs release the company's first mobile device: the Iphone. The Iphone was the first mobile interface to be completely touch-based. This was a big evolution, not only in terms of user experience, but also on the web development side. 2007+ Following the Iphone, all major companies of the time, such as Blackberry, and Nokia, started to emulate the success of Apple, and consumers were inundated with different devices every year. By the end of this decade, Mobile Phones were common devices for adults and teenagers, and have since developed and improved to what we have today. The evolution of Mobile Web Development Now that we have covered the actual evolution of our beloved handsets in terms of hardware, it is time to go back in time again to analyze the evolution of "mobile web development". As shown from the above section, the "web" made its first apprearance on Mobile phones in 1999. WML - 1999 I never had a chance to develop a mobile site in the late 90s. If I had, I would have had to use WML (Wireless Markup Language). This language (now obsolete), started to provide powerful features (link, forms, image, etc..), and was based on XML. Mobile development was specific, as this language was specific to devices that implemented the WAP (Wireless Application Protocol). The use of these sites on desktop was limited, or required the use of browser extensions. cHTML / iHTML - 1999 The browser capabilities on mobile phones developed quite quickly. Devices started to have access to subsets of HTML (cHTML and iHTML). This allowed developers to be able to create one asset (HTML) and serve a multitude of users, both on mobile and desktop. M.dot Mobile phone resolution was quite low, and phones in this period did not have touchscreens, making it difficult to surf the wed. To help in this matter, the industry respondend by utilizing what was called M.Dot methodology. This allowed a website to have two different entities, on two separate Urls. For example, if your site was myShop.com, when accessed from a mobile phone, you would have redirected users to m.myShop.com. Having different websites, allowed the developer to "eliminate" surplus content, and create a design that was more suited for the hardware of the time. This "duplication" came, of course, with a big development cost price tag. Native - 2008 The App store, and the Google Play store, were release in 2008. These events marked the beginning of a completely new industry. Internet speed on phones was very slow, and the price of data usage was still quite high. This enabled many companies to specialize in Native App development. These apps provided a quick and smooth experience to users, but with a great cost factor in terms of development and specialization. The distinct programming languages, and methodology needed to create Native Apps, was so wide across different devices, that many companies decided to specialize in a specific platform (Android, Apple or Windows). Native applications had the possibility to "connect" with the device, in unique ways, by having access to a huge set of APIs (eg. Push notification, background sync, use device space, etc..) Responsive Web design - 2008 But with the rise of Native App, another methodology started to gain traction: Responsive Web Design. This approach allowed the same website to render well on a variety of devices. Using this approach made the use of M.Dot methodology obsolete, and helped many companies save thousands of dollars in Native development. Unfortunately, "web apps" built this way would just be simple websites, and would require the user to access the internet, and specifically access the site URL. Hybrid App development - 2010 Responsive web design never managed to fully respond to customer requests. This was most likely due to the look and feel of the app being somehow different from a Native app. As phones developed, the gap between Native and Web Based widened, as the latter was not able to use many of the in-built features. In 2010, PhoneGap was revealed (currently known as Apache Cordova). This sofware enabled the development of applications using known web skills (html, css, javascript) to build Native Applications. More software followed this trend, enabling companies to start in-house development of Native Apps, without the need to incur high costs. PWA - NOW The last decade has been a roller coaster, as companies were torn among the use of Native app, Hybrid solutions, and responsive designs. In recent years, a new contender, or more precisely described as an upgrade of the Web App, entered the ring. This is known as the Progressive Web App (PWA). The primary intent of PWAs is to reduce the gap between web development and Native apps, by enchancing the user experience. In the next section, we are going to cover why the industry is responsing so positively to PWAs, and provide you useful insight to help you get up to speed with this methodology. The Rise of PWA (Progressive Web App) As you may have probably noticed from the way I speak about PWAs, I am personally really excited about this methodology, and in this section, we are going to explain the reason behind my interest in this technology. Feels like "home" First and foremost, the main advantage of PWAs is the ability for our websites/web application to be downloaded as real applications. When a website is fully setup as a PWA, mobile users are prompted with a "install now" action. Doing this will allow specific content (manually set as part of the PWA setting) to be downloaded directly on the phone, by allowing extremely quick load times and more. Furthermore, installing a PWA will also add it directly to the main mobile interface (homescreen), making it feel like a Native App. Be connected If you own a business, you are fully aware that connecting with the customer is essential. Therefore, if your customers are using your services online, being able to interact, and catch their attention, is vital. One of the main benefits of Native and Hybrid apps, as previously mentioned, was the ability to access the multitude of APIs offered by our handset. Thanks to PWAs, and more specifically to the use of a service worker, we will be able to make use of this powerful feature. Two of the most important features available on Web applications are: - Sync notification: Ability to sync your data, even if the app is not running. This is essential to provide quick content to your user. - Push notification: Ability to provide an alert to the customer, even if the app is not running ( eg. New notification in a specific app, or a reminder to use the app) It is true that the list of avaialble APIs is still small compared to that of Native implementation, but the community is working extremely hard to reduce this gap. Write for Web, serve on mobile When we previously covered RWD, we highlighted one ot its biggest advantages: being able to develop one single interface to serve a multitude of devices. PWAs offer the same advantages, with the added feature of providing the ability to display fullscreen like a "real app". This feature (part of the display setting of PWA) allows your app to take the full screen. This not only increases the space available to your app, but it also enhances the User Experience, by making sure the customer is not distracted by the "url" bar, by providing a "native look and feel". Additionally, we should highlight that the front end industry has seen a big rise in the use of frameworks, such as Vue, React, and Angular. The development of applications with "component based" architectures has supported the rise of theUI component library which is: > A cloud-based folder that consists of all the designed/styled parts of a website or piece of software. It helps designers to work in a consistent way and becomes very time efficient when executed correctly. The use of these libraries (most available for free), have supported the development of nice looking applications across multiple devices, without the need to develop all individual elements from scratch. Ready for shopping In recent months, the Google Play Store has supported PWAs as shown by this article. This service, though still in its early stages of implementation, provides a reassuring signal for the future of PWAs. You may be thinking, what about the Apple Store? Unfortuantely, Apple has not disclosed any information about PWA adoptation, but recent signals, highlighted in this medium article, show Apple's support of PWA development. At a fraction of the cost Unfortuantely, when it comes to business, cost is usually the most important factor. To further emphasise the above point, where we shared the introduction and use of "component based" architecture for speed, we also need to talk about development cost. There are three main aspects of PWAs that help reduce cost: - Existing skills - Development speed - Re-usability Existing skills Apart from some tinkering, and the introduction of the service worker, PWAs are just simple websites. They would allow a multitude of in-house development teams to be able to carry out development and/or support mobile apps, reducing the need to pay third party companies. Development speed As already mentioned above, component based achitectures, and the multitude of available community based components, have provided frontend developers the ability to quickly build performant PWAs in record time. Re-usability Many companies fail to quantify the financial savings produced by being able to re-use existing features. In a recent project I was involved with, we were able to transition from a Native App (supported by a third party company), to a fully in-house build PWA in record time, all thanks to the reusability of their Vue domponents! Versioning I have read many different articles that introduced PWAw, but I have personally learned this last point though experience. Until now, you would have never associated the word "versioning" with a website, but thanks to PWAs, this ability is also possible for web based applications. The main reason behind the need for versioning is purely technical, but its existence within PWAs is surely favorable to the many "Native" developers wanting to swap. Conclusion The war for Mobile Application domination is still on, but I personally believe that PWAs will hold a big share of the market within the next few years. Most of the advantages that support Native and Hybrid development, such as APIs, Native-look and feel, and the ability to publish within the big stores, are slowly being added to Web App. Even if Native applications are not going anytime soon, as there are many use cases that require its full control of the handset API,I believe that in the next few years, PWAs will become the standard choice for most in the mobile industry....

Feb 28, 2020

10 mins

PWAMobile Web Development

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.

How to add Dark Mode in your Web Application

How to Create Dark/Light Mode in your JavaScript project?

What is White/Dark Mode

Implementing Dark Mode with Javascript

Move all styles into CSS variables

Create a second set of variables for the dark theme

Create logic to read user preferences

Create logic to override the theme preference

Make our theme selection persistent

What about the images

Conclusion

Simone Cuomo

You might also like

How to Truncate Strings Easily with CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

History of Mobile Web Development and the rise of PWA

Svelte 5 is Here!

Let's innovate together!

You might also like

How to Truncate Strings Easily with CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

History of Mobile Web Development and the rise of PWA

Svelte 5 is Here!