Forem: Yoshi Rubin

The Importance of Web Standards and Best Practices: Why Reinventing the Wheel in JavaScript Often Leads to Worse Solutions

Yoshi Rubin — Sun, 18 Aug 2024 13:38:08 +0000

Introduction

In the ever-evolving world of web development, it's easy to get caught up in the latest frameworks, libraries, and tools. Developers often find themselves tempted to create custom solutions, believing that their unique approach might offer something better or more innovative. However, this approach can be a double-edged sword. Ignoring established web standards and best practices can lead to issues with accessibility, performance, and maintainability.

This article explores why adhering to web standards and following best practices is crucial, regardless of the framework or technology used. We will also discuss the risks of reinventing the wheel in JavaScript and why it often results in suboptimal solutions. To illustrate these points, we’ll refer to the WAI-ARIA Authoring Practices Guide (APG) and the importance of accessible, standardized patterns.

The Role of Web Standards

Web standards are the backbone of the internet. They ensure that web content is accessible, functional, and consistent across different browsers, devices, and platforms. Organizations like the World Wide Web Consortium (W3C) develop these standards, which include guidelines for HTML, CSS, JavaScript, and more. Adhering to these standards is crucial for creating websites that are user-friendly, accessible, and future-proof.

One key area of web standards is accessibility, which ensures that all users, including those with disabilities, can navigate and interact with web content. The WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) guidelines are an essential component of this. They provide a set of attributes that make web content and applications more accessible to people with disabilities, particularly those who rely on assistive technologies like screen readers.

Best Practices: A Foundation for Success

Best practices in web development are a set of guidelines and techniques that have been widely accepted because they lead to more efficient, maintainable, and scalable code. These practices are not tied to any specific framework or technology; they apply universally, regardless of whether you’re using React, Angular, Vue.js, or any other tool.

Some of the core best practices include:

Semantic HTML: Using the correct HTML elements for their intended purpose, which improves accessibility and search engine optimization (SEO).
Accessibility: Ensuring that web applications are usable by people with a range of disabilities, which includes following ARIA patterns and other accessibility guidelines.
Performance Optimization: Writing efficient code, optimizing images, and reducing load times to ensure a smooth user experience.
Code Maintainability: Writing clean, modular code that is easy to understand, test, and update.

These best practices not only improve the quality of your code but also contribute to a better user experience. They ensure that your application is accessible to all users, performs well under various conditions, and can be easily maintained and scaled as your project grows.

The Dangers of Reinventing the Wheel

In the world of JavaScript, developers often fall into the trap of creating custom solutions for problems that have already been solved by standardized patterns and libraries. While this might seem like a creative and innovative approach, it can lead to significant issues down the line.

For example, consider the creation of custom form controls. While it might seem straightforward to build a custom dropdown or checkbox, doing so without following established patterns can result in accessibility issues. Users who rely on keyboard navigation or screen readers might find these custom controls difficult or impossible to use. Additionally, custom solutions often lack the cross-browser compatibility and performance optimizations that come with well-established patterns.

Another common pitfall is the creation of custom navigation systems. While it might seem like a good idea to design a unique menu or routing system, doing so without adhering to best practices can lead to a confusing and inconsistent user experience. Standardized patterns for navigation are well-tested, accessible, and familiar to users, making them a safer and more reliable choice.

The ARIA Patterns: A Case Study

The WAI-ARIA Authoring Practices Guide (APG) is an excellent resource for developers looking to build accessible web components. It provides a collection of standardized patterns for common user interface components, such as buttons, dialogs, and navigation menus. These patterns are designed to be accessible to all users, including those with disabilities, and are built upon well-established web standards.

For example, the ARIA pattern for a modal dialog provides guidelines for making the dialog accessible to screen readers and keyboard users. It ensures that the dialog is correctly announced by assistive technologies, that focus is trapped within the dialog while it is open, and that users can close the dialog using both a button and the Escape key. By following this pattern, developers can create a modal dialog that is accessible and user-friendly, without having to reinvent the wheel.

Conclusion

Web standards and best practices are essential for creating accessible, maintainable, and high-quality web applications. While it might be tempting to create custom solutions, doing so without following established patterns can lead to significant issues, particularly in areas like accessibility and performance. By adhering to web standards like the WAI-ARIA guidelines and following best practices, developers can ensure that their applications are accessible to all users, perform well, and are easy to maintain and scale.

Call to Action

To further your understanding of web standards and best practices, consider exploring resources like the WAI-ARIA Authoring Practices Guide and the W3C’s guidelines on accessibility and web design. Take the time to review your current projects and identify areas where you might be reinventing the wheel with custom solutions. By prioritizing standardized patterns and best practices, you can create better, more accessible web applications for everyone.

Resources

Breaking Down Major Migrations: Vuex to Pinia Before Moving to Nuxt 3

Yoshi Rubin — Fri, 24 May 2024 06:42:38 +0000

In our ongoing journey of migrating Torah Live to Nuxt 3, one critical step was transitioning from Vuex to Pinia while still on Nuxt 2. Here’s how we approached it:

Why Move from Vuex to Pinia? 🍍

While Nuxt 3 is compatible with Vuex, Pinia is considered the future of state management in Vue.js. According to the Vuex documentation:

"Pinia is now the new default. The official state management library for Vue has changed to Pinia. Pinia has almost the exact same or enhanced API as Vuex 5, described in Vuex 5 RFC. You could simply consider Pinia as Vuex 5 with a different name. Pinia also works with Vue 2.x as well. Vuex 3 and 4 will still be maintained. However, it's unlikely to add new functionalities to it. Vuex and Pinia can be installed in the same project. If you're migrating an existing Vuex app to Pinia, it might be a suitable option. However, if you're planning to start a new project, we highly recommend using Pinia instead."

Given that we were making a large migration to Nuxt 3, we saw this as an essential part of the move to keep our code maintainable and future-proof.

The Plan: Breaking Down the Migration

1. Preliminary Research and Preparation

Research: I read through numerous blog posts and watched videos to understand best practices for migrating from Vuex to Pinia. Some resources that were particularly helpful include:

2. Incremental Migration Process

Simultaneous Stores: One of the nice things about migrating to Pinia is that I was able to run both Pinia and Vuex simultaneously. This allowed us to migrate one store at a time and fully test all functionality before moving to the next store.

3. Deployment Strategy

Staging Deployments: We regularly deployed to our staging environment to ensure everything functioned as expected. This allowed us to catch issues early and ensure that the migration was proceeding smoothly.
Production Deployment: Once the migration was fully complete and thoroughly tested, we deployed the changes to production. This approach ensured that we did not run both Vuex and Pinia simultaneously in production, minimizing potential conflicts and issues.

Overcoming Challenges

1. Adapting to Pinia's Patterns

Mutation Handling: One challenge was getting used to Pinia's pattern of assigning values directly to the state without using mutations, a shift from the traditional flux pattern. This required a mental shift and adjustment in our coding practices.

2. Minimizing Codebase Disruption

Incremental Changes: We aimed to avoid making too many changes to the codebase at once, ensuring it was clear what changes were made and why. This approach helped maintain code clarity and ease the transition.

3. Avoiding Conflicts with Ongoing Work

Concurrent Development: Another factor we considered was avoiding conflicts with ongoing work by the team on the project. Copying to a new codebase could have introduced many regressions. By migrating within the existing codebase, we were able to maintain continuity and minimize disruption.

Looking Forward

With the migration from Vuex to Pinia complete, we laid a solid foundation for the transition to Nuxt 3. This methodical approach allowed us to manage the complexity of the migration and mitigate risks associated with big changes. I’m very pleased with how the migration went, and now we're on the cutting edge.

Stay tuned for our next post where we dive into the actual migration to Nuxt 3, including some unexpected errors and how to avoid them!

Takeaways

Plan and Research: Thorough research and planning are crucial for successful migrations.
Incremental Changes: Breaking down large migrations into smaller, manageable projects can lead to smoother transitions.
Community Resources: Leverage community resources and documentation to guide your migration process.

Feel free to reach out if you have any questions or need advice on similar migrations! 🚀

Check out the previous post in this series!

🛠 Navigating the Upgrade Plan: Steps Before Vue 3 Migration

Yoshi Rubin — Wed, 08 May 2024 07:17:50 +0000

Welcome back, fellow tech enthusiasts! If you're just joining us, this post is part of a series where we dive deep into Torah Live's journey of upgrading to Nuxt 3. In our previous post, we explored why we made the decision to upgrade. Now, let's take a closer look at the meticulous plan we crafted before diving into Vue 3 migration.

Before diving headfirst into Vue 3 migration, we embarked on a thorough planning phase to ensure a smooth transition. This phase involved extensive research, meticulous documentation, and strategic decision-making.

First and foremost, I delved into the vast ocean of online resources to gather insights from fellow developers who had embarked on similar migration journeys. Blogs, articles, and video tutorials became my compass, guiding me through the intricacies of Nuxt 3 migration. Among the resources that proved invaluable were HarlanZW's Nuxt 3 Migration Cheatsheet, Debbie's blog on migrating from Nuxt 2 to Nuxt 3 (This one is a bit older but still has good info), and Alex Van Liew's enlightening video tutorial from Vue Conf.

Armed with insights from the community and a clear understanding of the migration process, I devised a comprehensive plan to tackle the upgrade in a systematic manner:

Complete Any Pre-Migration Migrations: Leveraging the flexibility of Vue 2, we prioritized any migrations that could be completed before transitioning to Vue 3. This allowed us to make incremental improvements to our codebase while still operating on Vue 2, ensuring a seamless transition.
Evaluate Third-Party Packages: I meticulously compiled a list of all third-party packages used in our application, categorizing them based on their compatibility with Vue 3. Packages with Vue 3 compatibility were marked for seamless integration, while those without required careful evaluation to determine suitable alternatives.
Migration to Nuxt-Bridge: With a clear roadmap in place, we initiated the migration process by transitioning to Nuxt-Bridge. This intermediary step served as a crucial bridge between Vue 2 and Vue 3, laying the groundwork for the final migration.
Transition to Vue 3: Once our application was successfully built on Nitro with Nuxt-Bridge, we were ready to take the leap to Vue 3. Armed with meticulous planning and a comprehensive understanding of the migration process, we embarked on the final phase of our journey.

As we meticulously executed each step of our upgrade plan, we encountered unexpected challenges and roadblocks along the way. However, with perseverance and a strategic approach, we navigated through the stormy seas of migration, emerging stronger and more resilient than ever before.

The planning phase proved to be the cornerstone of our successful migration journey. By investing time and effort into research, documentation, and strategic decision-making, we laid a solid foundation for the transition to Vue 3. In the next installment, we'll dive into the migration process itself, uncovering insights and lessons learned along the way. Stay tuned for more updates, and don't forget to check out my previous post for the full story! 🚀

🚀 Exploring Upgrading to Nuxt 3

Yoshi Rubin — Thu, 02 May 2024 14:44:07 +0000

Hey there, tech enthusiasts! Ever heard of Torah Live? We're on a mission to revolutionize Jewish education by making Torah subjects relatable and entertaining for kids and teens through videos, games, comics, and challenges. Intrigued? Let's delve into why we decided to upgrade from Nuxt 2 to Nuxt 3 and the amazing benefits it brought!

At Torah Live, we're all about staying ahead of the curve. When Vue 2 was nearing its end-of-life and we encountered performance issues, we knew it was time for a change. Vue 2's inability to cache computed values on the server side caused significant performance bottlenecks, leading us to manually memoize hashtables to mitigate the issue. With Nuxt 3, this problem is a thing of the past, thanks to its improved architecture and performance optimizations.

Picture this: hours spent grappling with performance hiccups in Vue 2, manually memoizing hashtables, and crossing our fingers for smoother sailing. Then, Vue 3 swoops in like a superhero, addressing our woes and streamlining our development process. 🦸‍♂️

In a nutshell, upgrading to Nuxt 3 was a no-brainer for us at Torah Live. Stick around for more tales from our migration journey and the magic we uncovered along the way!

What is SSR and when should you use it.

Yoshi Rubin — Fri, 30 Sep 2022 12:42:36 +0000

What is Server Side Rendering (SSR)?

When creating a dynamic webpage using Single Page Application (SPA), the server sends the entire web application in javascript files to the client, the browser will then make the api calls to the server to fetch the content from the server and render our page. With Single Server Rendering (SSR) the page is rendered on the server and the browser will receive an HTML page ready to be displayed.

Ok, so why is that better?

The benefits of using SSR boil down to a better user experience (UX) and better SEO

Improve UX. With SSR you get a faster time-to-content, now that we don’t need to wait till we download all of the JS files and then execute them a user with slower internet speed will get to see the webpage content much quicker. Another benefit is that the data on the initial load is loaded on the server as well which is likely a faster connection to the database than most client connections.
These benefits tend to result in better Web Vitals as well which brings me to the next bug benefit of SSR.

Better SEO. Because we are loading a fully rendered page the search engine crawlers will see the fully rendered page.

There must be some tradeoffs to using SSR?

Yes, there are tradeoffs and they should be taken into account.

Development constraints. This is a big one and might need a post of its own to get into more detail but the general idea is, since we are rendering the page on the server any browser specific code needs to be called in the correct lifecycle hooks.

Server-side load. There is more load on the server now and that does need to be taken into account when it comes to scale.

Build setup and deployment are more involved. We now require a Node.js environment to build and deploy our app.

So when should I use SSR?

If time-to-content and better SEO are important to your web application and you have a large amount of dynamic content then SSR could help you improve your web application and may even help improve conversion rates.

Great how do I get started?

Here are some great resources to get you started with setting up your webapp with SSR.
For react check out the Next.JS.
For vue check out the Nuxt.JS.
For angular check out Angular Universal.

Clean Code Handbook Chapter 1 Summary

Yoshi Rubin — Mon, 06 Jan 2020 10:14:22 +0000

Hey all!

I recently started reading "Clean Code A Handbook of Agile Software Craftsmanship" by Robert C. Martin link to the book on Amazon and I thought I would share what I have been learning I believe there are other conclusions you can have from reading this book, the book was highly recommended to me and so far I have not been disappointed.

In the first chapter, the author is trying to help us understand why we need clean code and what clean code is.

The author sells us on the idea that bad code can kill companies because one of the issues with bad code is that once we start with bad code we continue to pile on more bad code which makes fixing bugs harder which eventually makes the application unusable and not and not worth fixing, so then the companies dedicate resources to make a new application that does the same as the old one but then that one is done in a rush with “bad code” and we end up in a never-ending loop of bad code unless we break it and start writing clean code.

Now we get into the what is clean code part of this chapter, here the author asks other famous programmers and teachers how they would describe “clean code” I will not get into all of those here (they are really great but can get too long for this format)so I will try to give a short description that will be inclusive of most of the main points.

A few of the adjectives used to describe clean code are elegant, readable and straightforward when the author breaks those down a little more we get to an understanding that when writing code the focus should be to minimize complexity so when someone else reads the code it should be like reading a book, where everything makes sense and has a clear purpose in other words the code is cared for.

(This is my first post and my first time trying something like this feedback is welcome but please be gentle 😅)