DEV Community: Eran Sakal

AI in Development: 6 Critical Barriers to Full Adoption

Eran Sakal — Mon, 25 Nov 2024 13:00:00 +0000

After publishing the first article in this series Develop 10x Faster with AI: Unlock the Power of AI for Developers, I received some fantastic questions and thoughtful concerns from readers.

But before we dive into those, a quick anecdote: In my day-to-day work, I often share my screen for pair programming and collaborative coding sessions. And after seeing Cursor IDE in action, they usually say things like "Whoa, what IDE is that?". Many of them made the switch after those sessions.

The point is: You don't have to be 100% convinced to give it a try. It's incredibly easy to get started.

Now, let's get to those burning questions...

It’s clear that this topic sparks curiosity—and a bit of healthy skepticism—which is exactly what I was hoping for.

Below, I’m sharing the five most common questions I’ve been asked, along with insights from the discussions they inspired.

I’d love to hear your perspective, so don’t hesitate to share your thoughts, whether you agree, disagree, or have your own experiences to add in the comments!

1. Is Cursor IDE All Hype or a True Game-Changer?

As someone who loves diving into new tech, I always approach new tools with both excitement and caution. With Cursor IDE, I’ve taken the time to test it thoroughly, looking at both its strengths and its limitations. Its potential isn’t just theoretical—it’s grounded in real improvements to how I work.

Feature	Cursor IDE	Other AI Tools
AI Integration	Fully integrated into the IDE	Added as a plugin or extension
Workflow Support	AI assists throughout the development (part of auto complete, terminal tab, compilation errors)	Focused on code suggestions
Stack Awareness	Understands the project stack and suggests context-relevant code	Offers general suggestions based on code patterns
Context Awareness	Deep understanding of project context	Limited to selected files(s) or function scope
Coding Standards	Enforces and suggests team-wide standards	Relies on user-defined configurations
Reviewable Diffs	Automatically generates diffs for user review and approval	Typically applies changes directly without detailed diffs
Error Prevention	Actively reduces bugs through suggestions	Reactive, highlights errors after code

2.Switching IDEs is a big commitment. What makes Cursor IDE worth the change?

You're right. Switching IDEs is a big deal. It's like leaving your comfortable, familiar home for a new, unknown place. You have to relearn all the shortcuts, re-establish your muscle memory, and find your way around a completely different environment.

But what if this new place offered not just a change of scenery, but a whole new way of living? That's what Cursor IDE offers. It's not just about code generation; it's about a fundamentally different way of interacting with your code, collaborating with others, and even learning new skills.

Personally, I’ve attempted switching to VS Code multiple times in the past but always found myself returning to WebStorm. However, once I experienced the power and fluidity of Cursor IDE’s AI-assisted workflow, everything changed. The familiar features I had to leave behind—once a major concern—now feel like a small trade-off for the significant boost in productivity and creativity it delivers. Thought I’m still figuring out a few shortcuts!

3. Does Cursor IDE offer value for experienced developers working in their primary languages?

This is the question I get asked most often. While it's true that AI tools often shine when dealing with repetitive tasks or unfamiliar codebases, Cursor IDE has genuinely surprised me with its ability to enhance my productivity even in my areas of expertise.

What makes Cursor IDE unique is that AI isn’t just an add-on—it’s deeply embedded into the core of the IDE. This might seem like a technicality, but it has profound implications. Because the AI is so deeply integrated, it acts as a true extension of your own thinking, almost like a second brain. Many other AI tools feel more like external advisors – helpful, yes, but still requiring you to do the heavy lifting. Cursor IDE, on the other hand, feels like a collaborative partner that anticipates your needs and seamlessly assists you throughout the development process.

4. Aren't you afraid of being obsolete by the same tools you encourage people to use?

This is the question that keeps many developers up at night. It's tempting to fear that AI tools will make us redundant, replacing human developers altogether. But I believe the reality is not that dark.

It's true that AI, and specifically Cursor IDE, can significantly amplify a developer's productivity. We can produce more code, of higher quality, in less time. But this doesn't necessarily translate to job losses. Instead, it allows us to evolve and focus on higher-level tasks.

Imagine a CEO with a talented Chief of Staff. This Chief of Staff anticipates needs, streamlines operations, and ensures the CEO's time is used most effectively. AI tools act as a Chief of Staff for developers, handling mundane tasks, optimizing workflows, and allowing developers to focus on the strategic aspects of software development that drive innovation and business growth.

While it's undeniable that some entry-level coding tasks may become automated, the demand for developers who can leverage AI, think critically, and solve complex problems will only increase. The key is to embrace these tools, adapt our skills, and focus on the uniquely human aspects of software development – creativity, collaboration, and problem-solving.

The AI revolution is here to stay. We can choose to resist it and risk being left behind, or we can embrace it and use it to elevate our craft. I choose the latter.

5. How can I pitch Cursor IDE to my managers and highlight the reasons the company will benefit from it?

Introducing a new tool is an investment, and like any investment, it requires a clear understanding of its potential return. To make a strong case, you need to go beyond individual preferences and showcase how the tool contributes to the company's overall success.

The challenge with tools like Cursor IDE is that their impact can be difficult to capture with traditional KPIs. How do you measure the value of reduced cognitive load or increased developer satisfaction? And let's not forget the complexity of getting approval from multiple departments (security, finance, IT... the list goes on!).

Successfully integrating a new tool into a company's workflow requires more than just enthusiasm. It's about understanding how that tool can contribute to the company's core objectives.

Cursor IDE has the potential to significantly impact a company's bottom line by:

Faster Time to Market: Accelerates development cycles by streamlining workflows, enabling your teams to deliver features and updates to customers more quickly, keeping you ahead of market demands.
Enhanced Product Stability: By improving code quality and consistency, AI reduces the risk of bugs and production issues, ensuring more stable and reliable software.
Consistent Standards Across Teams: AI enforces coding standards seamlessly, making your codebase more maintainable, scalable, and easier to manage, especially as teams grow.
Increased Developer Output: Automating repetitive tasks frees developers to focus on delivering innovative, high-value features. This leads to greater productivity and a stronger product pipeline.

When decision-makers realize that Cursor IDE empowers their existing development team to perform at a significantly higher level, the return on investment becomes clear. It's like hiring top-tier team with the same workforce. This realization naturally leads to identifying and tracking the most relevant KPIs to measure the increased efficiency and output.

6. As a manager, how should I approach the use of AI tools in my team’s workflow?

Managers can no longer afford to be unaware of the role AI plays in their team's daily work. Developers are already integrating AI tools into their workflows, often without realizing the full implications. This can range from simple code snippets generated by ChatGPT to sophisticated AI-powered IDEs like Cursor. Ignoring this reality leaves your team vulnerable and your company's code potentially at risk.

Instead of simply reacting to the rise of AI, companies need to proactively shape its adoption. This includes:

Curating Approved AI Tools: Carefully evaluate and select a set of approved AI tools that meet your company's security and privacy standards.
Enforcing Privacy and Security: Establish clear guidelines on data handling, code sharing, and the use of external AI services. Limit the use of public LLMs and prioritize enterprise-grade solutions that offer enhanced security and privacy.
Fostering Open Dialogue: Encourage open discussions about AI, its benefits, its challenges, and the ethical considerations surrounding its use.
Providing Training and Support: Equip your team with the knowledge and resources they need to use AI tools responsibly and effectively.

By taking a proactive and informed approach, companies can not only mitigate the risks associated with AI but also unlock its full potential to empower their development teams.

See how Cursor IDE's Business plan addresses key enterprise needs for security and privacy in the snapshot below.

Alright, your turn to take the stage! Did I miss anything? Got any burning questions or hot takes on this topic? Share your thoughts, in the comments below.

Develop 10x Faster with AI: Unlock the Power of AI for Developers

Eran Sakal — Mon, 18 Nov 2024 07:00:00 +0000

Ready to transform your coding experience? Download Cursor IDE and become the developer you should be in 2024. 🚀 This isn’t a promotion—it’s what I did, and I couldn’t be happier. This article explains how Cursor helped me take my development to the next level.

Imagine your upcoming workweek. Think about the project you’re tackling with all the technology stack it contains. Now, picture the effort it will take to deliver your task to meet deadlines.

Now, close your eyes and imagine this instead: you're in the same chair, typing on the same keyboard, but this time it takes you 10x less time to complete your work, and the process is 20x more fun and stress-free.

In today’s fast-evolving landscape, we can’t predict the exact tools we’ll be using even tomorrow. However, Cursor IDE has already shown us the way forward by deeply integrating AI into the development workflow, making it one of the coolest additions to any developer’s toolbox.

Until another IDE takes the crown, make the most of Cursor and enjoy all the benefits highlighted in this article today.

At this point, you’re probably wondering: “Why should I bother with a new IDE? I already use GitHub Copilot—what more could I need?”. I hear you. Let me share my journey.

For months, I used GitHub Copilot with WebStorm and VSCode. While it was fun and certainly helped speed up tasks like writing comments and making some code adjustments, it never truly stood out. It was useful, yes, but it didn’t feel like the game-changer I was hoping for in this new era of AI.

Eventually, I canceled my Copilot subscription and began searching for alternatives. That’s when I stumbled upon a fantastic vlog by @developersdigest. Watching Cursor in action sparked my curiosity, and I decided to give it a shot.

Fast forward to today: this article is my take after I’ve embraced tools that turn development into a seamless collaboration between human creativity and AI precision.

Why Cursor Elevates VSCode to the Next Level

Cursor, built on the foundation of VSCode, deeply integrates AI into the IDE, turning coding from a solitary task into a collaborative and enjoyable experience. It doesn’t just boost your speed—it enhances your intelligence and efficiency.

Beating Copilot at Its Own Game

GitHub Copilot may have been the first big AI assistant, but Cursor takes it further. It doesn’t just assist—it understands your project, offering smarter suggestions, contextual improvements, and comprehensive changes. With Cursor, it feels like you’re collaborating with a teammate who’s an expert at everything.

What about ChatGPT?

I currently use both Cursor and ChatGPT Plus side by side. ChatGPT is my go-to for discussing architecture, design, and approaches, while Cursor handles the actual development with its deep IDE integrations, as detailed below.

Interestingly, while writing this article, ChatGPT introduced a feature for IDE integration in beta version. Although it doesn’t yet match the seamless AI integrations Cursor offers, I’m planning to give it a try in parallel since ChatGPT often provides a significant productivity boost. However, for now, Cursor remains my primary choice for development.

Cursor’s Game-Changing Features

1. Super-Powered Auto-Completion

Cursor’s auto-completion is more than predictive—it’s intuitive. It anticipates your logic, completes entire blocks of code, and even fixes multiple issues simultaneously.

The suggestions are so precise that you’ll often find yourself just pressing Tab to approve them, letting Cursor handle the typing. In this example, I placed the cursor on the arguments, and it accurately suggested the projectName argument (#1). From there, I simply Tabbed through the remaining suggestions (#2, #3), streamlining the process effortlessly.

2. Inline Popovers: Your AI Genie

Cursor’s inline popovers are like having an AI assistant whispering actionable tips as you code. Highlight any snippet, provide a quick prompt, and instantly get suggestions or fixes tailored to your needs.

Not a fan of crafting detailed prompts? Simply typing fix is often all you need.

3. Transition from Figma to Code – Lightning Fast

Transforming designs into code has never been easier. With a specialized Figma plugin Figma To Cursor, you can export any design as XML directly to your clipboard and simply paste it into Cursor’s prompt with a Generate prefix. That’s all it takes. Cursor’s AI takes care of the rest, producing remarkable results. It not only generates the HTML structure but also styles it according to your project’s conventions, seamlessly integrating with your stack, including the application state management and any other frameworks used. This saves you hours of manual effort while ensuring consistency and alignment with your existing architecture.

4. Visual Diffs for Code Changes

Every modification Cursor suggests is presented as a familiar visual diff, but it goes beyond just offering generic solutions. Cursor is fully aware of your codebase and provides context-aware migrations, ensuring seamless integration and precise updates. You retain full control to review, accept, or reject the changes with confidence.

5. Context-Aware Chat

Cursor’s chat feature goes beyond the boundaries of the current file. It doesn’t just answer questions—it understands your entire project. You decide which files to include in the conversation—whether it’s specific files, folders, or even the entire codebase.

Here’s a practical example: In my project, I needed to add a photo carousel in Ionic with features like zoom and pinch—a task I would normally estimate to take an entire day due to its complexity. Using Cursor IDE, I selected the relevant files, image-gallery.tsx and image-gallery.module.css, in the chat and provided a prompt outlining the desired changes. Cursor responded with a clear, step-by-step guide that modified multiple files simultaneously. All I had to do was review the suggested changes, click “apply,” and approve them with ease.

6. Web Surfing for Context

Cursor isn’t confined to local knowledge. It fetches relevant real-time data from the web, and tailors its suggestions based on the latest best practices.

Here’s a real-world example: I had an image carousel built with Ionic’s IonSlides component. This component was deprecated in v6.0.0 and removed in v7.0.0. The official migration guide in this article recommended switching to swiper.js.

With Cursor’s ability to incorporate web links directly into prompts, I kept things simple: my prompt was, “use @ web https://ionicframework.com/docs/react/slides with swiper.js”. Cursor read the relevant pages and delivered a near-perfect solution, saving me the time needed to learn it and write it by my self.

This feature not only speeds up migrations but also ensures the generated code aligns with the latest official recommendations, saving me the time and effort of learning and implementing it manually.

7. Documentation Cataloging

Cursor includes a built-in catalog of a wide range of documentation, ensuring it pulls answers from the latest official sources.

For teams using internally developed libraries, the ability to add custom documentation is an incredibly valuable feature. For everyone else, Cursor seamlessly provides code based on the most up-to-date documentation, all behind the scenes, without requiring any extra effort from the user.

8. Cursor Supports Multiple Frameworks and Languages

Cursor works seamlessly with a wide variety of frameworks and programming languages, making it a valuable tool for developers across different domains.

For instance, in the image below, a data scientist is using Python to implement face recognition with the DeepFace library. Cursor not only aids in writing and debugging the code but also offers contextual suggestions for integrating complementary tools, such as PostgreSQL, to store and retrieve detected face data efficiently.

How Companies Can Ensure Privacy with Cursor

When it comes to companies, privacy is always a top priority. However, the concept of privacy is evolving, especially in a world where we rely on thousands of third-party libraries, IDE plugins, and browser extensions—each introducing potential attack vectors.

To deliver efficiently, you can’t build everything from scratch; AI-powered IDEs and tools have become indispensable. This makes it crucial to choose trustworthy providers, minimize unnecessary plugins, and configure tools securely.

The first step is to enable privacy mode, as outlined in Cursor’s privacy page. Next, ensure the company uses its own API key tied to a service the organization subscribes to, providing added control and security.

Consider limiting the use of unnecessary plugins to reduce potential attack surfaces, regularly review and update the tool’s configurations, and follow best practices when interacting with AI tools to further enhance privacy and security.

My Experience with Cursor

I reimagined my personal journal app with Cursor, and it was a game-changer. From Firebase integration to transforming Figma designs into clean HTML, to automating UI logic and refining repetitive code, Cursor turned hours of work into minutes. Its deep understanding of my project let me focus on creativity, problem-solving, and building—while it handled the tedious tasks effortlessly.

Why You Should Try Cursor Today

Cursor isn’t just another tool; it’s a revolution for developers. It’s fast, intuitive, and makes coding fun again. If you’re ready to unlock your potential and deliver projects with unprecedented speed, try Cursor.

A Practical Guide to Scaling Frontend Experiences - Part 1

Eran Sakal — Mon, 21 Oct 2024 12:00:00 +0000

Before you dive into this article, I highly recommend reading Why You Should TRUST Frameworks (And What It Takes to Build One From Scratch) article. This series builds upon the foundation laid in that article, which explores the core challenges modern frontend frameworks face. Unisphere, the framework we’re discussing here, originated from those very concepts. In this series, we’ll outline three levels of development mastery, with the third level being where Unisphere truly shines. To fully understand the journey from basic app development to complex, scalable architectures, we encourage you to start from the frameworks article.

Many frontend developers are dealing with similar issues. The ecosystem is rich with examples, code samples, open-source projects, solutions, and ideas. However, it doesn’t always make the job easier. In fact, it can sometimes make things more challenging as you sift through endless possibilities to find what works for your specific needs.

The Developer Luck Spectrum

In this series, we’ll explore what I like to call the “Developer Luck Spectrum.” Your position on this spectrum depends on the level of freedom, complexity, and responsibility you carry as you navigate various development challenges.

Level I - The Luckiest Developers (Application Developers): These developers are at the "luckiest" end of the spectrum because they focus solely on a single application. They have the freedom to break APIs, tweak dependencies, and operate in a controlled environment without worrying about broader integrations. It’s a developer’s paradise—less complex, with plenty of room for experimentation.
Level II - The Motivated Developers (Multi-Application Developers): As you start managing features across multiple applications, you transition into the realm of scaling. You're no longer as "lucky" because you're building solutions that must work across applications, increasing complexity. However, this brings more learning opportunities and a greater sense of accomplishment.
Level III - The Strategic Developers (System Architects): At the highest level, you oversee integrations across multiple applications as-well-as embedding your experiences within customer applications. This requires strong architectural planning, versioning, documentations, backward compatibility, and a deep focus on developer/integrator experience. As complexity increases, so does the potential for a much broader impact.

Starting with "The Luckiest Developers (Application Developers)"

I’ll be writing an article for each level of “luckiness.” This one is tailored for “The Luckiest Developers,” and may be particularly appealing to novice developers. As we progress, the content will become more advanced, but a solid understanding of this article is essential to fully grasp the concepts in the follow-up pieces.

So, without further ado, let’s dive into what it takes to extend a single application with a feature—what we call “experiences”.

Building the Experience

To keep our focus on the underlying infrastructure, we’ll simplify the experiences by representing them as basic shapes. For instance, a simple circle will stand in for the reactions experience, and a rectangle will represent the notifications experience.

The purpose of this abstraction is to focus on building the underlying infrastructure that can be reused with any experience. It’s about a “write once, use many times” approach, allowing us focusing on the box -the structure- rather than getting caught up in the details of whatt's inside.

Let's kick things off by creating the reactions experience, which we'll represent with a simple circle. While we could easily create this using CSS, we'll wrap it in React to make it more interactive.

import React from 'react';

export const Reactions: React.FC = ({ onClick }) => {
  return (
    <div
      style={{
        width: '50px',
        height: '50px',
        borderRadius: '50%',
        backgroundColor: 'blue',
        display: 'flex',
        justifyContent: 'center',
        alignItems: 'center',
        cursor: 'pointer',
      }}
    >
    </div>
  );
};

The time it takes to code this isn’t the focus of this article—we're concentrating on the framework that supports it. However, to pique your curiosity, here's a glimpse of the actual experience behind the circle. As you'll see, it's much more visually engaging, but the infrastructure remains indifferent to what’s inside.

Codebase Management Strategies

This section focuses on where to code of the experience should be written

Since this is part of a single application, it’s often best to keep the code within the application’s codebase. Extracting it into a separate code base and consume it using NPM library might seem tempting, but for a feature in a single application, it raises unnecessary questions about versioning, deployment, APIs, documentation, dependencies, peer dependencies, and technology upgrades. Keeping it simple by integrating directly into the application can save time and effort.

Even for single applications, using a framework like NX can offer significant advantages in managing your codebase. While it comes with a learning curve, NX is an excellent tool for writing modular code, even within a single application. Plus, when you’re ready to explore more advanced deployment techniques, you’ll already have the infrastructure in place.

Packaging and Deployment

This section focuses on how to package and deploy the experience so it will be used in the application.

At this stage, the feature is part of the application codebase, so there’s no need to consider versioning, deployment pipelines, or public APIs as it gets automatically bundled with the application during the build process. This simplicity avoids the complexity of packaging and deployment strategies until the feature

Development Environment Tools

This section explores the tools available for developing the feature locally.

Since the feature is part of the application’s codebase, it can be served locally just like the rest of the application. For many developers, especially those working on a single app, this process is straightforward—you’re likely already serving your application locally or using tools like Storybook for isolated component development. If your feature is embedded and consumed in an iframe, you might use a playground application for developing locally. Whatever your current setup is, keep doing what works for you. For the motivated and strategic developers managing more complex setups, we’ll dive into advanced techniques in later articles.

Unit tests

This section covers when and where to focus on unit testing within your project.

Unit tests are highly valuable, yet many developers find it challenging to prioritize them due to both technical and business pressures. My rule of thumb is simple: the server should always have unit tests, while the frontend only requires them in areas with pure logic. In frontend development, automated testing, end-to-end (e2e) tests, and—if you’re using Storybook—accessibility and visual regression tests can provide significant benefits.

Documentations

This section discusses the importance of documentation and tools to consider when creating it.

Good documentation is crucial when building public APIs or products, as it helps ensure ease of use and adoption. However, documenting internal application details can be tricky and is not needed, as it can quickly become outdated and unreliable over time.

For the motivated and strategic developers managing more complex setups, we’ll dive into advanced techniques in later articles.

Core Infrastructure Feature Components

This section outlines key infrastructure components that can enhance your frontend experiences, from state management to theming.

Application State

Managing the state of your application is fundamental to building interactive experiences. You likely already have an application state library in place, so it’s usually best to continue using what works for you.

However, if you haven’t explored XState for application state management, I highly recommend checking out Rethinking State Management - Why XState is a Game-Changer for Developers. XState offers a fresh approach with its finite state machines and statecharts, providing flexibility for even the most complex state management scenarios.

Interactions with the Application

React provides all the hooks you need to manage interactions between your experience and the larger application. If you’re already using a state management solution like Mobx or Redux, you can leverage these libraries hooks to streamline communication across components.

If you’re not using an application state library, you can likely manage with React’s built-in context and providers, or even by passing props down through components (also known as prop drilling), depending on the complexity of your application.

Languages & Theming

Localization and theming are essential for any scalable application. Chances are you’re already using libraries like i18next for language management. Similarly, you’re probably relying on design systems such as Material UI, Chakra UI, Ant Design, or Tailwind CSS for theming. These libraries come with built-in hooks to help you manage languages and themes effectively.

When You Earn the Motivated Developer Badge?

At some point, you’ll find yourself working on two or more applications that need to share features between them. Your first instinct might be to start packaging shared experiences into NPM modules.

Before you rush ahead, take a moment to reconsider. Ask yourself the following question to determine if you’re ready to level up or if you can remain in the comfort zone:

Question: Are both applications managed by the same team?

If the answer is yes, you’re still among the luckiest developers. There’s no need to split your codebase, and this is where NX can really save you time and effort. If you’re already using it, you can proceed with minimal hassle. If not, don’t worry—migrating to NX is a relatively simple process.

If the applications are managed by different teams, you might still benefit from using NX for its excellent Code Ownership tools. However, in many cases, you’ll likely end up managing each application in its own codebase. And with that, congratulations—you’ve officially earned the “motivated developer” badge.

What’s Next?

In the next article, we’ll shift focus to the motivated developers—those managing multiple applications and navigating the complexities of shared experiences. We’ll also dive into the world of the strategic developers, where versioning, backward compatibility, and public APIs become everyday challenges.

Even if you’re not facing these hurdles yet, it’s always helpful to get a sneak peek at what’s ahead and prepare for potential future challenges.

If you’d like to be notified when part 2 is released, follow me on dev.to and stay in the loop!

The Key Questions Every Modern Frontend Framework Should Answer

Eran Sakal — Fri, 18 Oct 2024 11:00:00 +0000

When developing a modern frontend framework, the primary objective is to enable developers to focus on building features without being limited by specific use cases. A well-crafted framework provides flexibility, relieving developers from concerns about bundling, DevOps processes, and challenges related to runtime or standalone hosting.

Here’s a list of key questions that helped shape the creation of such a framework, aimed at solving real-world challenges developers face. This framework, called Unisphere, is explored further in the article Why You Should TRUST Frameworks (And What It Takes to Build One From Scratch).

Index of Key Questions

How can we share features written in React with non-React applications, like Angular?
How do we enable communication between features hosted in iframes and the host application?
How can we avoid treating runtime features like UFOs?
How do we manage independent module deployment and usage?
How can we bundle features for consumption as a package, at runtime, or as a standalone application?
How do we maintain loose coupling between features while still offering tight integration?
How can we seamlessly integrate features into customer applications we don’t control?
How do we provide productive documentation and code samples?
How do we manage shared runtime assets like themes and languages across features?
How do we deliver new versions of features while ensuring backward compatibility?
How do we overcome dependency version conflicts?
How do we support features that operate at different cadences and use different dependency versions?
How do we scaffold a project that provides all the tools a developer needs from the start?
How can we offer unified diagnostic tools across multiple features?
How do we allow the discovery of features at runtime and enable customization?
How do we streamline collaboration between teams working on different experiences?
How do we handle state management across features?
How do we optimize performance while consuming features at runtime?
How do we design a framework that can solve problems we haven’t anticipated yet?

Key Questions the Framework Aims to Solve

1. How can we share features written in React with non-React applications, like Angular?

Challenge: Many developers today write new features in React but maintain legacy applications in Angular or Vanilla JS. Reusing React components in these environments can be tricky due to differences in lifecycle and architecture.

Solution: The framework should provide tools or abstractions to integrate React components seamlessly into non-React applications, minimizing the need for rewrites or reliance on iframes.

2. How do we enable communication between features hosted in iframes and the host application?

Challenge: Iframes often isolate features, limiting interaction between them and the host application.

Solution: The framework should enable communication mechanisms like postMessage, shared states, or event-driven systems to allow real-time interaction between iframe-hosted features and the main application.

3. How can we avoid treating runtime features like UFOs?

Challenge: Runtime features can feel disconnected from the host, negatively affecting user experience.

Solution: Rich infrastructure based on services that cover aspects like shared data storage, pub-sub mechanism, runtime discovery and others will allow tight integration in a loose environment.

4. How do we manage independent module deployment and usage?

Challenge: Independently developed modules need to work together without causing version conflicts or dependency issues.

Solution: The framework should support independent module deployment while maintaining compatibility across versions, offering tools to manage dependencies and updates without breaking the system.

5. How can we bundle features for consumption as a package, at runtime, or as a standalone application?

Challenge: Features may need to be consumed in multiple ways, whether through NPM packages, runtime loading, or standalone deployment.

Solution: The framework should allow developers to write features once as React packages and provide smart wrappers to deploy them as standalone apps or runtime modules, ensuring flexibility and reducing redundancy.

6. How do we maintain loose coupling between features while still offering tight integration?

Challenge: Features may need to communicate without being tightly coupled, which can make scaling difficult.

Solution: The framework should support pub/sub models or service-oriented architecture, enabling features to interact dynamically without direct dependencies.

7. How can we seamlessly integrate features into customer applications we don’t control?

Challenge: Embedding features into third-party applications with different tech stacks can cause compatibility issues.

Solution: The framework should offer embeddable components or runtime widgets that adapt to any tech stack, making integration simple and compatible.

8. How do we provide productive documentation and code samples?

Challenge: Developers need clear, easy-to-use documentation and code examples to get started quickly.

Solution: The framework should include well-maintained documentation and live code samples that demonstrate how to integrate and use features effectively.

9. How do we manage shared runtime assets like themes and languages across features?

Challenge: Sharing assets like themes and languages across independently developed features is difficult.

Solution: A centralized asset management system should allow themes, languages, and other shared resources to be easily distributed and updated across all features.

10. How do we deliver new versions of features while ensuring backward compatibility?

Challenge: Updating features without breaking existing functionality is crucial, especially for long-lived applications.

Solution: The framework should support versioning strategies that allow multiple versions of a feature to coexist, with clear migration paths to update without disrupting applications.

11. How do we overcome dependency version conflicts?

Challenge: Conflicts between different dependency versions, such as React or Material UI, can break applications.

Solution: Dependency isolation techniques like module federation or smart bundling mechanisms should help manage conflicting versions, allowing features to use different versions of the same dependency.

12. How do we support features that operate at different cadences and use different dependency versions?

Challenge: Some features may require frequent updates, while others remain static for long periods, leading to version misalignment.

Solution: The framework should allow independent versioning of features, supporting different dependency versions as needed.

13. How do we scaffold a project that provides all the tools a developer needs from the start?

Challenge: A poorly scaffolded project can slow down development by omitting critical tools and workflows.

Solution: The framework should offer an opinionated project scaffolding system that includes testing, bundling, state management, and deployment workflows out of the box.

14. How can we offer unified diagnostic tools across multiple features?

Challenge: Debugging fragmented features with separate diagnostic tools can become complex.

Solution: A unified set of diagnostic tools (e.g., logging, performance metrics, error reporting) should be available for all features, simplifying the process of debugging and optimization.

15. How do we allow the discovery of features at runtime and enable customization?

Challenge: Developers need to discover and customize available features dynamically.

Solution: The framework should offer a runtime discovery mechanism (e.g., feature registry or API) that allows developers to query available features and customize their behavior.

16. How do we streamline collaboration between teams working on different experiences?

Challenge: When multiple teams are working on different features, they need to ensure their work integrates smoothly.

Solution: The framework should provide standardized tools and workflows, such as shared testing environments, CI/CD pipelines, or common module formats to ensure seamless collaboration.

17. How do we handle state management across features?

Challenge: Managing state across multiple features without tight coupling can lead to performance bottlenecks.

Solution: A centralized state management system should allow state sharing and synchronization across features while preserving their independence.

18. How do we optimize performance while consuming features at runtime?

Challenge: Loading features at runtime can introduce performance issues like slow load times and memory overhead.

Solution: The framework should support lazy loading, code splitting, and efficient caching to ensure runtime features don’t negatively impact performance.

19. How do we design a framework that can solve problems we haven’t anticipated yet?

Challenge: It’s impossible to predict every future requirement or use case.

Solution: A future-proof framework should focus on flexibility and extensibility, using a modular design that allows new features and integrations to be added without disrupting existing functionality. Loose coupling between components ensures that changes in one area don’t break the entire system.

Conclusion

By addressing these key questions, the framework is designed to empower developers to focus on building flexible, scalable, and adaptable features. The goal isn’t just to solve today’s challenges but to create a foundation for solving problems we haven’t even thought of yet.

To dive deeper into the philosophy behind this approach, check out the article: Why You Should TRUST Frameworks (And What It Takes to Build One From Scratch) article.

If you’d like to be notified when new articles are released, follow me on dev.to and stay in the loop!

Why You Should TRUST Frameworks (And What It Takes to Build One From Scratch)

Eran Sakal — Wed, 16 Oct 2024 11:30:00 +0000

I’ve always had a love-hate relationship with frameworks. In today’s development world, you simply can’t meet production demands without weaving together multiple frameworks and libraries. They take care of the heavy lifting and the “dirty work” for you, which is great—until it’s not. The magic of a framework fades the moment you need something outside its box. That’s when you find yourself diving deep, hacking your way around it until things fit your use case.

But let’s face it: frameworks are here to stay. You might be an “old school” dev who believes you should write everything from scratch, and if that’s the case, this article might not be for you and I wish you good luck. For the rest of us, frameworks are essential, despite the occasional rough edges.

There’s a risk, of course. Using frameworks and libraries exposes your project to potential vulnerabilities—either through poor implementation or unmaintained code, or good forbidden malicious code. This is a topic for another day, but it’s worth keeping in mind as you pick your tools.

Introducing Unisphere (and What’s in It for You)

Unisphere is a meta-framework designed to tackle the core challenges modern developers face when building scalable and flexible frontend experiences.

While working on the framework, we gathered a list of questions that served as a checklist to ensure we were on the right track. Answering one or two is manageable, but answering them all requires careful planning. Our goal was for the framework to provide a rock-solid solution for today’s challenges as well as future ones. I’m sharing this list for you to review: The Key Questions Every Modern Frontend Framework Should Answer.

Why Should You Care About Unisphere?

Unisphere is more than just an internal framework for Kaltura—it’s a case study in how to address complex development problems. This series is filled with practical insights, architecture patterns, and code samples that you can adapt for your own projects.

Why it Works

Writing a framework is tough—writing it for internal use is even tougher. When a framework is your product (whether commercial or open source), you control its growth. You document, iterate, and refine based on your own needs. But when it’s built for internal use, you have to get it right from day one. If you don’t, your fellow developers won’t adopt it, and it’ll die before it even gets started.

Fortunately, my manager at Kaltura, Nir Belinki, saw the potential of an opinionated frontend framework. Unisphere was built to streamline developer workflows by separating infrastructure from the application layer. This allows developers to focus on features without worrying about underlying complexities.

By following a similar approach, you can increase productivity and simplify maintenance, making it a great model to learn from.

Why Is it a Meta-Framework?

Unisphere isn’t designed to replace core tools like React or NX. Instead, it builds on top of these technologies to solve higher-level architectural problems, such as runtime modularity, multi-environment integration, and scaling frontend systems efficiently.

While React is ideal for building UI components and NX is excellent for monorepo management, Unisphere extends these tools, adding the layers needed to address the complexities of integrating features across different applications and environments.

A Glimpse Into the Technology Stack

To deliver its solutions, Unisphere uses a variety of well-established technologies:

Rollup bundles runtime artifacts.
Webpack manages standalone applications.
TypeScript ensures type safety, even when working with runtime modules.
GitHub Actions runs CI/CD pipelines.
AWS S3 and CloudFront host and deliver artifacts globally with low latency.

For efficient workflows, Commander.js offers a custom CLI, while Docusaurus powers documentation, ensuring that everything is easy to find and well-maintained.

In addition, all applications and runtime artifacts are hosted in a centralized AWS S3 bucket, which handles various types of artifacts—runtime scripts, single-page applications, and multi-page applications. This setup simplifies hosting, version control, and caching strategies, reducing the burden on dev-ops.

Finally, NX allows us to extend its capabilities with custom plugins and generators to automate workflows, create boilerplates, and manage continuous migrations. This helps developers evolve the codebase over time with minimal effort as new features are introduced or technologies change.

Wrapping It Up: The Multiplier Effect

As you can see, Unisphere leverages a wide array of techniques, libraries, and frameworks—and it does so with style. By clearly separating the infrastructure from the application layer and defining boundaries between them, it creates a powerful multiplier effect. A small team can maintain the infrastructure, empowering the rest of the developers to focus on delivering value, resulting in exponential gains in productivity.

What It Takes to Build a Framework From Scratch

Building a framework from scratch isn’t easy—it takes careful planning, clear objectives, and a deep understanding of your users. Based on my own experience with Unisphere, here are the core principles you need to keep in mind:

Start with Clear Objectives: Define exactly what your framework is going to solve and what it isn’t. It’s crucial to know where your framework fits and who should use it. If you’re not sure what your goals are, your users won’t be either.
Know Your Audience: Developers are your main users, so understand what they love and what frustrates them. For example, developers hate guessing. They need clear documentation, helpful code samples, and a supportive community. Make sure your framework delivers on these expectations from day one.
Define Strong Concepts: Every framework needs a set of core concepts that guide its development. These concepts will be the foundation upon which everything else is built. Without a strong philosophical backbone, your framework can easily lose focus.
Don’t Be Afraid to Change—But Know You Have Limited Time: Frameworks need room to evolve, but keep in mind that you only have a short window before your first official release to make significant changes. Early on, don’t hesitate to roll out ideas, test new approaches, or pivot from your original objectives. Use this time wisely by creating alpha and beta iterations, so you can remain flexible and gather valuable feedback before locking in decisions. Once the official version is out, making drastic changes becomes much harder without risking breaking functionality or backward compatibility.
Prioritize Developer Experience (DX): Think about how the framework feels to use—smooth, intuitive, or frustrating and rigid? The developer experience should be a top priority. From setup to execution, every part of using your framework should be frictionless.
Automate Everything You Can: Developers hate writing repetitive code, so automate whatever is possible. Build tools and command-line utilities that hide the complexity and let developers focus on what really matters: delivering the application itself.
Remove Obstacles, Focus on Execution: Your framework should make developers’ lives easier, not harder. By removing barriers and solving common problems upfront, you free developers to focus on execution and delivering the actual requirements.
Guard the Framework’s Role and Responsibilities: It’s important to maintain the framework’s core objectives and purpose. Users may request changes or patches that seem valid from their perspective but could work against the framework’s goals. Be cautious about introducing features that deviate from the framework’s responsibilities, as everything that becomes part of the public API or behavior must be supported long-term. Over time, this can make it difficult to deprecate or evolve certain aspects. Stay firm on what belongs within the framework and what doesn’t.
Think Long-Term: It’s easy to design for the present, but if you don’t consider long-term use cases, you’ll struggle with backward compatibility down the road. Always keep future growth in mind to avoid unnecessary breaking changes later on.
Log Everything: If your library is meant to be used by developers, logging is essential—log everything. You need detailed logs for every action your framework takes, and you should support a verbose mode for diagnostic debug logs. If your framework runs at runtime, expose it in a way that helps developers diagnose issues easily. No developer trusts a black box, and the more verbose your library is, the more trust you’ll build.
Communicate Everything: Good documentation is non-negotiable. From day one, ensure you have a well-maintained, easy-to-navigate documentation site. Share your roadmap, be transparent about your plans, and invest time in making the experience appealing for users.
Consider Migrations From Day One: When developers start using your framework, they will depend on you to provide smooth migrations as time passes. Every framework evolves, and if you don’t plan for migrations early, you risk causing frustration or even losing users down the road. Build in a strategy for versioning and migration tools from the beginning to ensure seamless transitions between versions without breaking existing implementations.

Ending Insight

I want to end this section with one final insight, which I believe is the most important of all:

Don’t Try to Remove the Learning Curve: Every framework comes with a learning curve—some steeper than others. Don’t try to satisfy everyone by oversimplifying your framework to the point where it doesn’t require learning. Be comfortable with the fact that developers will need to invest time in understanding how your framework works. Focus on attracting developers who are willing to learn and dive deeper, rather than those looking for shortcuts. If some developers choose not to invest the time, that’s their decision—but it doesn’t mean you need to compromise your framework’s depth or its long-term potential.

The Concepts Behind a Good Framework

Alright, enough storytelling—let’s get into the good stuff. After all, developers thrive on architecture, code and solid concepts, not just stories (we’ll leave that for the marketers).

If you’ve made it this far, I hope I’ve sparked your interest in what Unisphere brings to the table. Now, let’s dive into the core ideas that shape the framework.

Below, I’ve listed most of the key concepts that define Unisphere. Each of these will get its own dedicated article, where I’ll unpack them in detail.

It might take some time to cover everything, but don’t worry—I’ll be coming back to this article to update the links as I publish each new piece.

Developer-Friendly: Maximize adoption by making the framework valuable and easy for developers to adapt.
Diagnostics & Developer Tools: Built-in tools to simplify debugging, troubleshooting, and performance monitoring.
Automate Everything with Boilerplates & Command Lines: Simplify processes by hiding complexity behind easy-to-use commands.
Migrations in Mind: Ensure smooth updates and adaptations to changes with minimal friction.
Runtime Discovery: Bridges the gap between loosely or non-coupled elements when used at runtime.
Triple Usage Approach (NPM, Runtime, Standalone): Write once, without worrying about how it will be consumed later.
Typed in a Non-Typed World: Maintain type safety with TypeScript, even in loosely coupled architecture.
Built with SPA in Mind: Tailored for single-page applications, addressing their unique challenges and use cases.
Clear Naming for Runtime: Establish clarity and consistency in naming conventions to avoid conflicts in runtime environments.
Dogfooding Your Own Framework: Use the framework also internally to guarantee reliability, scalability, and continuous improvement.
Versioning and Compatibility: Implement resilient versioning strategies that maintain backward compatibility while enabling the introduction of breaking upgrades.
Collaboration with Partners: Facilitate smooth integration with external elements that aren't part of the framework.
Flexible Dependency Strategy: Resolve dependency conflicts in NPM packages without losing flexibility by introducing a new balanced strategy (details in the future article).
Framework Agnostic: Design the public API in vanilla JavaScript, allowing it to integrate with any framework, despite using React internally.

What’s Next?

This article sets the stage for understanding the challenges and concepts involved in building a framework like Unisphere. But there’s much more to come! In the coming weeks, I’ll be releasing a multi-part series titled “A Practical Guide to Scaling Frontend Experiences,” where we’ll explore real-world scenarios for scaling features across multiple applications.

I’ll also delve deeper into the concepts mentioned here and link each back to this article.

Additionally, I’ll be sharing boilerplates, code samples, and other guides that Unisphere has to offer.

If you’d like to be notified when new articles are released, follow me on dev.to and stay in the loop!

Playing the Long Game in Frontend Development: Key Takeaways

Eran Sakal — Tue, 20 Aug 2024 11:40:00 +0000

From legacy code transformations to building entirely new platforms, my journey recently leading frontend projects at Kaltura has been filled with lessons. This article summarizes those experiences into actionable takeaways. For the full story and context, check out the first article in this series.

Before we start - A Note to Readers

This article was written by me (a human!) and then polished with the assistance of an AI tool. My hope is that it will be read primarily by fellow humans, and not only by AI agents 😆 While AI assistance is valuable, the true magic lies in the human connection.

Let’s dive into the key takeaways!

1. Vision and Milestones: Your Strategic Roadmap

Define the End Game: Before anything else, clearly define your ultimate goals. What does success look like for this project? What are the key outcomes you want to achieve? Having this overarching vision in mind will guide your decision-making throughout the entire journey.
Work Backwards: Once you have your end goal, start planning backward. Break down the big picture into smaller, manageable milestones that bridge the gap between where you are now and where you want to be.
Clear and Measurable Goals: Each milestone should have concrete, measurable objectives. This provides a clear target to aim for, but avoid getting bogged down in excessive detail that could stifle agility.
Estimate, Don't Obsess: While it's valuable to estimate timelines, don't get hung up on hitting precise ETAs. Flexibility is key in the face of unexpected challenges.
Adapt, Don't Replan: As you progress, be prepared to adjust your plan based on new information or unforeseen obstacles. But avoid constant replanning, which can disrupt momentum and create unnecessary delays.

2. Dual Perspective: Balancing the Now and the Future

Think Short-Term and Long-Term: Every decision should be evaluated from both an immediate (Team Lead) and future (Architect & Tech Lead) perspective.
Plan for Scalability: Ensure your infrastructure can handle future growth without overbuilding in the present.

3. Embrace Iterative Progress: Flexibility is Key

Don't Fear from Temporary Code: Early versions of code might be replaced as requirements evolve or understanding deepens. As long as it serves its immediate purpose and meets quality standards, it's valuable.
A perfect illustration: of this is a strategic feature we recently developed. The ideal architecture for this feature would have taken four quarters to implement, but immediate business needs didn't allow for such a long development cycle. So, we broke down the development into four distinct phases, each delivering incremental value while progressively moving closer to the desired architecture. This approach allowed us to satisfy both short-term requirements and our long-term architectural goals.
Celebrate Small Wins: Recognize and appreciate progress, even in small increments. This keeps morale high and momentum going.

4. Additional Strategies for Success

Challenge the Status Quo: Be open to questioning past decisions. The best path forward may require adapting and rethinking.
Patience is Key: Transformations take time. Stay committed to your vision even if progress is slow.
Communication is Essential: Keep everyone aligned on the vision, milestones, and progress. Transparency fosters trust and collaboration.
Build a Strong Foundation: Invest in robust logging, effective dev tools (custom-built if necessary), and a thoughtful approach to state management.
Leverage Existing Solutions: While custom tools have their place, don't reinvent the wheel. Utilize proven libraries and frameworks whenever possible.

I hope these insights will prove helpful in your own development journeys. Feel free to share your thoughts, questions, or similar experiences in the comments below.

Until next time,
Eran

Playing the Long Game in Frontend Development: Reflections on Balancing Ambition and Execution

Eran Sakal — Tue, 20 Aug 2024 11:30:00 +0000

At Kaltura, I wear multiple hats—Frontend Architect, Team Leader, and Tech Lead. Each hat comes with its unique perspective: the Architect dreams big and plans for the future, the Team Leader focuses on immediate results, and the Tech Lead drives innovation and quality. Balancing these viewpoints is giving me a unique position to influence both today's successes and tomorrow's possibilities.

In the fast-paced world of software development, we face a constant challenge: meeting immediate customer needs while simultaneously building for the long term. It's easy to get caught up in the day-to-day, but it's critical to keep that end goal in sight.

Before we start - A Note to Readers

Two Projects, One Journey

This month marks an exciting landmark for me: the completion of two major projects I've led. The original motivation for this article was to digitally celebrate that achievement. Thus, this article focuses on the stories behind those two projects.

But as my wise colleague, Stas, reminded me, an article without actionable insights is incomplete. So, I've extracted the key takeaways from these projects into a separate article, which I encourage you to read next!

Project #1: A Three-Year Journey to a Modern Frontend

Over three years ago, Kaltura acquired a company with a React-based application that was already handling significant daily user traffic. My mission: lead its frontend development.

Our immediate goals were clear: enhance stability, boost performance, and elevate the team's skills. But the long-term vision was ambitious: a complete replacement of the legacy system with a modern, robust application built on the latest technologies. Unlike a typical MVP (Minimum Viable Product) approach, we couldn't afford gradual iteration; the new application needed to be fully functional and in production quickly.

We set off on a multi-year journey, developing two applications in parallel: the acquired application, which required intensive maintenance and development to ensure a good experience for its hundreds of thousands of daily users, and a brand-new application built from the ground up. We rapidly launched this new application, ensuring it offered complete feature parity with the legacy system right from the start.

This graph illustrates the gradual reduction of dependency on our legacy system over the course of the project from 2021 to 2024. Starting with a fully integrated legacy system, the graph shows how, through strategic milestones and iterative progress, we systematically transitioned to a new application. Key events like creating smart “bridges,” separating codebases, and implementing new features contributed to this decline, culminating in the complete elimination of legacy dependencies by August 2024. This visual journey reflects the careful planning and execution required to achieve a seamless transition.

As seen in the graph, a few days ago, the team— Stas, Tornike, Anna, and Toby—reached a major milestone: deleting 3,000 files of the acquired application from the new application codebase, marking the completion of this transition.

This success was a collaborative effort involving many teams: Product, Designers, UX designers, Quality Assurance, Server, and RTC teams.

Project #2: A Platform Born from the Pandemic

The second project, though still in its early stages, represents a major transformation in how we deliver real-time experiences. The idea for this project came about during the challenges of the COVID-19 pandemic. As the world shifted online, our company saw the need to adapt and help our customers host virtual events that were just as engaging as in-person ones.

In 2020, we responded by creating a new infrastructure specifically for this kind of online collaboration. This allowed our products to include features that were usually only found at physical events - think sponsor booths, parallel tracks, networking lounges, real-time reactions, interactive quizzes, moderated events, and much more.

While our initial solution proved effective, as we continued to add features, it became evident that we needed to expand our vision. We needed to create a comprehensive framework that catered to all stakeholders: customers, end-users, product teams, developers, marketing, and professional services. Two years ago, my manager challenged me to architect and execute such a framework that would enable us to scale rapidly and seamlessly.

This project has been an exciting challenge, with lots of architectural hurdles to overcome and important decisions to make. From redesigning the core infrastructure to making sure it's easy for developers to use, every step has been a chance to learn and innovate.

I'm genuinely excited to see how these two projects will impact our company's offerings and growth in the coming years. If you're curious about the lessons we learned and the strategies we employed, please check out my follow-up article where I delve into the key takeaways from this journey.

Until next time,
Eran

Rethinking State Management - Why XState is a Game-Changer for Developers

Eran Sakal — Mon, 15 Jan 2024 15:00:00 +0000

In this article, I want to share a personal journey of discovery in the world of state management. My path led me to XState, a tool that I believe is the best choice for managing state in modern applications like React, Angular, Vue, and others. This isn't just a professional advice; it's a personal recommendation based on real-world experience.

It’s important for you to know that this advice is backed by my professional experience. Over the last twenty three years as a software developer, I’ve explored a variety of technologies and trends. For the past eight years, I've been part of the company Kaltura, leading front-end teams development. In the last four years, I’ve also stepped into the role of our group frontend architect. My journey has covered everything from hands-on development to architectural design, mentoring, leading teams, and code reviewing.

The purpose of sharing my background isn't to show off but to lend credibility to my views on XState. I firmly believe that XState is a critical tool for any application striving for maturity, robustness, sustainability, maintainability, and optimal performance.

A Personal Example: Kaltura Meeting Experience

It's important to note that XState is an excellent candidate for any size of application that requires more than just React context. Its adaptability makes it equally effective in small-scale projects as it is in large, complex applications. The reason XState hasn't been as widely adopted by the community, as I see it, is detailed later in the article.

In our work on the Kaltura Meeting Experience, we encountered significant challenges as the project expanded. Originally built using Redux, the application was initially impressive in its performance and capabilities. However, as the complexity increased with over 30 distinct features we hit the scalability wall. Each feature comes with its own set of logics, restrictions, states, and actions, we reached a point where we lost control over the application state.

This growing complexity highlighted the limitations of our existing state management approach. The more features we added, the more we realized that managing a complex network of states and interactions with Redux was becoming unsustainable.

The transition to XState marked a pivotal moment in the project. It was more than just a switch in technology; it was a strategic shift in how we approached state management. XState's ability to handle a multitude of states and transitions elegantly made it an ideal choice.

The Challenge of Adoption

As I see it, the main reason developers often stick with tools like Redux and MobX is due to their accessibility. These libraries simplify the concept of a state machine, easing the initial learning process and concealing their complexities and limitations until the later stages of product development.

In contrast, XState, with its extensive capabilities and the nuances of integrating it into React applications, presents a more intimidating learning curve. For us, it took several months to fully grasp how a full-blown state machine functions while simultaneously figuring out the optimal way to manage multiple machines that needed to interact with each other and with React.

Another factor contributing to Redux's popularity is its well-known browser extension for dev tools, which allows developers to easily visualize the application state at any given moment. This convenience is part of what simplifies the onboarding process for Redux. Many developers may not realize the work done under the hood when they enable devTools: true while creating a store with configureStore. This level of integration and ease of use is something that XState's author might consider emulating. I'll delve into your options for similar functionalities with XState in the last section.

Despite these challenges, we recognized from the first day that XState was the right tool for our needs. We embraced the challenge, and today we can confidently state that it was worth every bit of effort and refactoring we invested. The results speak for themselves in the enhanced stability and scalability of our applications.

When XState Might Not Be Ideal Choice

While XState is a powerful tool for state management, there are scenarios where other tools might be more suitable. Firstly, if your front-end predominantly mirrors server-side CRUD (Create, Read, Update, Delete) operations and doesn't have websocket based realtime updates, a library like react-query could be a more efficient choice. This is due to its specialized handling of server-state synchronization.

Secondly, for managing interactions between nested components – a situation often referred to as 'prop drilling' – React Context is typically the preferred method. It simplifies the process of passing data through multiple component layers without cumbersome prop forwarding.

In all other scenarios, once you become proficient with it, I advocate for XState. Its robustness in managing states makes it an invaluable asset in a developer’s toolkit.

TL;DR - Understanding XState

This section offers a brief overview of XState for those seeking a quick summary. While it won't provide detailed instructions on using XState, it will give you a clear understanding of its core concepts and why it's becoming increasingly popular in the development community

What is XState?

XState is a library for creating, interpreting, and executing finite state machines and statecharts in JavaScript. At its core, XState is about managing state in a predictable, scalable, and maintainable way. In simpler terms, think of it as a roadmap that guides how your feature behaves in response to various events or actions. Unlike traditional state management solutions that can become unwieldy as applications grow, XState provides a structured and visual way of handling state, making it easier to understand and manage complex scenarios.

Why XState?

XState allows developers to define states, transitions, and actions in a structured format. This approach not only brings clarity to the development process but also reduces bugs and improves maintainability. With XState, you can visualize these state transitions and interactions, which is invaluable for both development and debugging.

How XState Works

Imagine your feature as a machine that can be in different states, like 'loading', 'idle', 'error', or 'success'. XState manages these states and the transitions between them based on events. For instance, when a user clicks a button, the application might move from 'idle' to 'loading'. XState handles these transitions smoothly and predictably. Furthermore, it integrates seamlessly with popular frameworks like React, Vue, and Angular, making it a versatile choice for many developers.

First Steps with XState

Giving XState a fair chance requires patience and dedication. It's essential to invest time in understanding the concepts of state machines and becoming familiar with their components.

Learn XState from the Documentation

Start by exploring the XState v5 documentation. Note that there is also documentation for the older XState v4. Ensure you're referring to the latest version for the most current information.
Before integrating XState with React, it's crucial to grasp the fundamentals of state management and statecharts. Begin with the Core Concepts section to build a foundational understanding of XState's functionality.
Take your time to understand each term. The Glossary page offers a comprehensive list of terms, each linked to its relevant section in the documentation for more in-depth understanding.
Utilize the online studio to explore and analyze machines created by others and try designing your own machines.

Implement the First Feature

When ready to implement XState in a React application, start with a single feature. This helps you get a feel for the process.

In XState, you can design a single state machine for your entire application, managing different features with spawn machines. However, for frameworks like React and Angular, I recommend creating a separate machine for each feature. This approach, using multiple machines instead of a centralized one with spawns, simplifies interactions with these frameworks.

Pro Tip: To succeed with XState, having runtime visibility of the machines is crucial. However, this is a weak point as I see it in XState. As of the writing of this article, the Inspector section in their documentation is marked as TBD. Your options are:

Follow the XState v4 documentation for machine inspection.
Consider using an extension like XState Ninja, though I haven't personally used it.
Develop an internal tool for your application. We did this to tailor inspectors to our needs, but it's not a necessity from the start. Consider this only if it becomes relevant.

Avoid Using Spawn Machines Initially

As you delve into the documentation, the concept of spawning machines may catch your attention. Spawning is typically used for managing parallel sub-flows, like handling multiple file uploads simultaneously, with each upload having its own state machine. It’s advisable to master the basics of XState implementation before moving on to more advanced concepts like spawning.

If you need assistance, feel free to join the XState Discord channel or leave a comment below for guidance.

The Dark Side of Design Systems - Mistakes, Missteps, and Lessons Learned

Eran Sakal — Mon, 20 Nov 2023 12:00:00 +0000

"To be authentic is to be at peace with your imperfections" by Simon Sinek.

Before we dive in, let's acknowledge the positive aspect: having a cross-group library that's been adopted by our products and provides a unified user experience is a significant achievement. We're committed to continuous improvement, aiming for streamlined processes, clear architecture, and robust build and deployment strategies.

It's important to note that the critiques and lessons shared in this article in no way diminish the hard work, dedication, and ongoing investment we're all making in this library.

Two years ago, we realized our organization lacked a unified design system to be used across our suite of applications. This realization wasn't shocking; we were transitioning from isolated, independent applications to a more unified user experience. In this new paradigm, users could interact with multiple applications seamlessly, whether through iframes or dynamic content loading.

While we achieved the primary goals set by the product team for the design system, this article isn't about patting ourselves on the back. In truth, our short-term planning led to many challenges. We faced issues related to adaptability, maintenance, versioning, and more. Additionally, the lack of clear ownership and the diverse needs of multiple products led to managerial headaches.

So, this article is about humility and learning. I'll candidly share the pitfalls we encountered, because there's as much—if not more—to learn from mistakes as there is from successes.

Note: It's worth mentioning that leveraging an existing library like Material UI (MUI) was, and still is, the right choice for us. The decision to build on an existing library or start from scratch depends on your specific goals. If your design system library is a product, whether paid or open-source, you should create your own components from scratch. If not, it's smarter to use a library that's already made, making it work for what your applications need.

Ready to get started? Let's dive in.

From React Expertise to Design System Novice: Why Knowing React Isn't Enough

In our group we have React experts who've built complex, high-performing applications. So, creating a design system library should be a walk in the park, right? Not quite. As we discovered, React expertise doesn't automatically equip you for the unique challenges of building a design system library.

One glaring example was our decision to closely follow the Material-UI (MUI) library's API and structure. With limited knowledge about design systems, we chose to emulate those who seemed to know best, aiming to benefit from MUI's accessibility support, component offerings, and other features. We'll dive deeper into this issue in the next section.

Another pitfall was our struggle with customization. When we did attempt to create components that adhered to our design requirements, we found that they were not easily customizable. This happened because our team's developers were not used to some React techniques that help build flexible design systems.

Lessons Learned

Build a Specialized Squad

Writing a design system library isn't just another frontend task; it requires specialized knowledge and skills. If your team doesn't already possess this expertise, consider forming a dedicated squad for the initial version. This squad should consist of strong, skilled frontend developers led by someone with an architecture-oriented approach.

Allocate Time and Resources

Creating a design system library is not a side project. Make sure to allocate sufficient time and resources to this endeavor. Clearly communicate to all stakeholders that this is a significant commitment and not something to be squeezed in "along the way."

Identity Crisis: The Conflict Between General-Purpose and Opinionated Design Systems

Popular design systems like Material-UI (MUI), Chakra-UI, and others are built to be robust and versatile. They offer a wide range of overlapping APIs to cater to a various of use-cases. While they may have their own opinions, for the sake of this article, let's consider them non-opinionated. They're designed to fit into almost any application architecture you throw at them.

However, when you're crafting a design system tailored for your own suite of applications, the goals shift dramatically. You're not building for the world; you're building for your specific ecosystem. This leads to a more opinionated approach, focusing on APIs that precisely meet the needs of your applications. For instance, you don't need five different ways to customize themes; one or two methods that align with your architecture should suffice.

But let's clear up a common misconception: being opinionated doesn't mean being strict. A strict API forces applications to work around the library, while an opinionated one promotes smoother integration by exposing just what's needed. This aligns well with the open-closed principle, allowing for easier future extensions.

At Kaltura, for example, our Professional Services department needs the ability to customize themes at multiple levels. While MUI provides various ways to achieve this, offering too many options can lead to an unsustainable, hard-to-support system. By controlling the API and tailoring it to specific needs, we create a win-win situation for everyone involved.

Lessons Learned

Tailor to Your Ecosystem

When building an in-house design system, focus on what your specific applications need. This allows you to create an opinionated API that promotes smoother integration and easier maintenance.

Opinionated Doesn't Mean Strict

An opinionated API isn't a limitation; it's a focused toolset that serves your specific needs without forcing workarounds. It should be designed to be open for extension but closed for modification, following the open-closed principle.

Control the API for Sustainability

Offering too many customization options can lead to an unsustainable system. Control the API to ensure that it aligns with your architecture and can be effectively maintained in the long term.

API Design Decisions: The Risks of Inheriting vs. Tailoring

Let's make this section a bit more interesting by diving into an example. Imagine you have a button component in your design system with the following requirements:

Clickable
Can be disabled or in a loading state
May have an icon on the right side
Comes in three sizes
Offers three variations (circle, pill, borderless)

Pause for a moment and think: how many properties should such a button expose?

To give you some perspective, I tried counting the properties of a MUI button and lost track after about 140. For a general-purpose library like MUI, this makes sense. They need to cater to every HTML attribute, accessibility feature, animation, and more.

When you make a library for just what you need, things are different. You might only need about 7 properties for your product. If you add some basic technical parts like 'ref', 'styles', and 'classes', you get to around 14 properties total. But as we inherit from the MUI button, we end up showing many more properties than our designers asked for.

Now, let's consider a more complex component like a dialog which also has compositions of inner parts like header, body, footer, etc. For our tailored library, we should have offered just two variations of dialog with about 10-15 properties. But by exposing the MUI's dialog component and making changes to it, we accidentally shared too many properties and also allowing compositions that are not part of the company design system. This made our dialog box too complex and harder to manage than we intended.

For our tailored library, we needed to expose just two compositions and about 10-15 properties. But as we exposed the with customizations, we exposed a much larger, potentially hard to handle component API.

Lessons Learned

Less Can Be More

When tailoring an API to your specific needs, you often require far fewer properties than a general-purpose library would offer. This makes your library easier to understand, use, and maintain.

Know Your Requirements

Understanding both your product and technical requirements is crucial. This allows you to expose only the properties that are genuinely needed, avoiding unnecessary complexity.

Be Cautious When Inheriting

Inheriting all properties from a general-purpose library can lead to a bloated, hard-to-maintain API. Moreover, you risk exposing properties that not only are irrelevant to your product requirements but may also directly conflict with them, making it impossible to meet those requirements effectively.

Complexity Scales

As components become more complex, the number of properties can grow exponentially if you're not careful. Tailoring your API keeps this complexity in check, making your library more sustainable in the long run.

The Illusion of Documentation: Why Storybook Isn't a Substitute

In today's development landscape, it's common to equate having a Storybook with having a documentation site. While Storybook is an excellent tool for showcasing components and their various states, it's not a one-to-one substitute for comprehensive documentation.

Storybook excels at visual representation and interaction, allowing you to see components in isolation and play around with their properties. However, it often falls short in providing the context, best practices, and architectural guidelines that are crucial for a design system. It doesn't explain the "why" behind certain design decisions or how components should be used together with each other to build cohesive user experiences.

Simply put, Storybook helps developers see how a button works by clicking on it. But it doesn't guide them to write good explanations about when to use this button or how it fits into the bigger picture of the design. Since Storybook focuses more on making components than explaining them, it can lead to weaker documentation.

Lessons Learned

Don't Confuse Tools with Documentation

While tools like Storybook are valuable for component visualization, they are not a replacement for thorough documentation that includes context, guidelines, and best practices.

Context Matters

A design system is more than a collection of components; it's a set of rules and philosophies that guide how those components are used. Storybook won't provide this context, so make sure your documentation does.

Documentation: A Dual-Purpose Resource

A well-crafted documentation site serves as an invaluable resource for both developers and designers. For developers, it's a guide to understanding how to implement and extend components. For designers, it's a reference point to validate that the implementation aligns with design requirements. To foster effective collaboration and feedback, your documentation should comprehensively cover all possible states of a component, including states that are changing quickly like loading, busy, and error.

Storybook's Hidden Power: Why Docs Mode Matters

Storybook offers two modes: Canvas and Docs. While Canvas provides a hands-on, interactive way to explore components, it's often more convenient for developers and not ideal for serving as a documentation site. In contrast, the Docs mode is where the true power of Storybook as a documentation tool comes into play. It allows for more comprehensive coverage and should be the focus if you're aiming to create a robust documentation site. Configuring for a "docs-only" build, although challenging, is a crucial step in achieving this goal.

Use-Case Blind Spots: Why Our Tech Stack Choices Were Wrong for a Library

When our design system library was first initiated by one of our developers, we didn't invest much time in framing the concepts, motivations, and assumptions behind it. We naturally chose to use MUI, but we didn't stop to think about possible problems or other options that might have been better.

MUI is an excellent library and serves our applications well. However, when you're developing a library, dependencies take on even greater importance. Unlike an application, where you own the page, a library is more like an invited guest. Everything from the HTML it generates to the classes it exposes and its bundle size becomes crucial.

Moreover, the library sets the tone for how application developers approach UI. For example, if MUI has a particular way of managing dynamic styles, our library will echo that approach. To illustrate, let me share one positive and one negative example from our experience. On the positive side, about a year after integrating the library into our applications, we received a critical request to support Content Security Policy (CSP). Fortunately, since MUI supports it, our library does too, saving us from having to start a new design system library from scratch.

On the flip side, a design system library typically comes with a theme, which is conveniently exposed to the application. In our case, we started echoing MUI's theme, and it became part of the public API of our library. As I'll discuss in the next section, the MUI theme doesn't align with our library's theme. Because it was there from day one, we've been working extremely hard to deprecate it—an effort that is far from over.

In addition to the theme challenges, another aspect of Material-UI (MUI) that we encountered involves its handling of DOM classes. MUI is designed to expose classes on the DOM, allowing for advanced customization of component. This feature is particularly beneficial for professional services and other developers who need to tailor the look and feel of components to specific requirements at runtime.

This approach, however, has made our design system heavily rely on MUI's specific methods. By integrating MUI's DOM classes into the public interface of our components, we've created a strong link with MUI. This connection has a significant implication: as we are committed to not breaking the customizations made by professional services, it effectively means we cannot upgrade MUI without risking issues. Upgrading MUI could lead to unexpected behavior or problems in our components due to changes in how MUI's classes are structured or function.

We are now working on separating our design system from MUI's DOM classes. This means finding new ways to let users customize components that don't rely so much on MUI's classes. This is an important goal for us as we improve our design system."

Lessons Learned

Know What You Bring to the Table

Dependencies aren't just code; they're a set of decisions and limitations that you're importing into your project. Whether you bundle a library as a dependency or count on the host to provide it as a peer dependency, you need to be mindful of what you're introducing.

Consider the Footprint

When you're a guest in someone else's application, every byte matters. Be conscious of the footprint your library leaves, from bundle size to the HTML and classes it generates.

Your Choices Echo

The decisions you make in your library will influence how application developers approach their work. Choose wisely, as these choices can have long-term impacts, both good and bad.

Evaluate Long-Term Compatibility

Sometimes the implications of a tech stack choice aren't immediately apparent. Always consider how well a dependency will align with potential future requirements, as we discovered with our need to support CSP.

Design Tokens and Theme: Keep Them Separate from the Underlying Library Tokens

The heart of a design system lies in its theme, which is fundamentally based on design tokens. These tokens are the basic building blocks of your app's design, just like a language for your designers. Changing a single design token can significantly impact all the components and layouts that use it. Moreover, users can switch themes at runtime to alter the overall experience—think light mode to dark mode.

Since this is your company's library, it should communicate using your designers' tokens. It's crucial to expose only the essential set of tokens that your designers use in tools like Figma. Otherwise, you'll find yourself unable to align the application with their designs after the initial setup.

Remember, the design tokens and the classes you show become official parts of your system, even if you didn't intend it. This means you'll have to support both the underlying library's tokens and your designers' tokens, which will lead to conflicts.

Lessons Learned

Always Look Through the Lens of Professional Services

Before releasing a component, carefully review the injected DOM HTML and make informed decisions about the classes it includes. Assume that your company's professional services team—or the users of your library—will find and use these classes to meet their deadlines and design goals.

Always Look Through the Lens of Designers

Any design token you expose that isn't defined by your designers is a ticking time bomb for future conflicts. Designers use tokens in their tools like Figma and expect changes to reflect in the final product. Conflicts with underlying design system tokens will prevent you from achieving the designers' vision.

Maintain Your Own Theme

Your theme, your design token. The only people who should influence the theme are your designers—not even you. Unlike component APIs, where you're expected to add essential or integrative props like onClick, classes, children, ref, and others, the theme is the designers' domain. Respect that and act as their guardian.

For context, check out the default theme of MUI. It has 1,372 lines when formatted, compared to our company theme's mere 119 lines. Imagine the number of unnecessary tokens you're adding by exposing the underlying theme tokens.

Summary and What's Next

We've covered a lot of ground in this article, from the challenges of building a design system library to the nuances of API design, documentation, and theming. The journey has been enlightening, to say the least, and we've learned valuable lessons along the way.

Cover image crafted with Picsart.

List Your Way to Team Leading: Managerial Relationships & Product Interactions

Eran Sakal — Mon, 02 Oct 2023 16:40:45 +0000

This is the second part of our journey through frontend team leadership. If you've read the first part, you already know we're exploring this through a structured list—a format close to my heart. In this article, we'll delve into managerial relationships, product interactions, and how to work effectively with peer development & QA teams. These are the nuts and bolts that have helped me, and I hope they'll help you too in navigating the complexities of frontend development. So, let's continue listing, shall we?

Managerial Relationships

Maintain Open Communication: Keep your managers in the loop with regular updates. The more informed they are, the better they can support the team.
Proactively Raise Concerns: Don't hesitate to flag potential issues as early as possible. In the best-case scenario, these concerns may resolve themselves, but early warning allows for better planning.
Own Your Decisions, But Strive for Excellence: Do your best and aim for high standards, but understand that perfection is not always attainable. There's no need to apologize for imperfections if you've made a well-considered effort.
Embrace Constructive Disagreement and Autonomy: It's okay to have differing opinions on team developments, deadlines, or designs. You're not only expected to lead the team effectively but also empowered to make decisions that may not align with your managers' views. The key is to make well-considered choices without fear of repercussions, as long as those decisions are made in the best interest of the team and project.

Product Interactions

Foster a Collaborative Relationship: View the product team as allies in achieving common goals. Instead of keeping a scorecard on changing requirements, focus on how you can adapt and work together for the best outcome.
Be Solution-Oriented: You're expected to identify challenges and proactively suggest viable alternatives. This adds value to the product development process.
Maintain Regular Communication: Keep the lines of communication open with the product team. Whether it's daily stand-ups or weekly syncs, make sure you're consistently in touch.
Share Early and Often: Aim to provide previews of features before they're fully completed. Early feedback can be invaluable.
Offer Constructive Feedback: If you see room for improvement, don't hesitate to provide constructive criticism. This helps refine the product and fosters a culture of continuous improvement.
Assist in Story Grooming: Encourage the product team to thoroughly groom user stories. Offer yours and the feature leader expertise to help identify edge cases, potential error scenarios, and any conflicts with existing features.

Peer Development & QA Team

Anticipate and Plan: Be mindful of other teams' deadlines and pressures. Proactively identify potential bottlenecks, especially when tasks require parallel work from teams with dependencies on each other. Whenever possible, prioritize sequential work to mitigate these challenges.
End-to-End Responsibility: Understand that a feature is only considered delivered when it has received end-to-end approval from QA, encompassing both backend and frontend contributions.
Timely Deliveries for QA: Avoid the common pitfall of pushing all deliveries to QA near the end of a commitment period. Ensure that QA has ample time to conduct thorough testing.
Quality Over Speed: Resist the urge to release medium-quality work just to meet deadlines. Factor in time for bug-fixing cycles and only release features that have received a 'go' from QA. Note that this may require a QA environment that supports pre-releases, allowing for greater flexibility in feature inclusion or exclusion.
Celebrate Collective Success: Keep a positive mindset and recognize that successful project deliveries are the result of collaborative efforts from all peers—designers, product managers, delivery managers, QA, and other development teams.

The slide above is from a presentation we gave to unveil the first iteration of our next-generation product. It was a moment to celebrate the collective achievements and hard work of the all the peers.

Fostering a Culture of 'Good Enough'

This section is an extension of the 'Good Enough' principle mentioned in Team Dynamics and serves as the cornerstone of our team philosophy.

The Good

Empowerment: A safe environment encourages team members to stretch their capabilities and aim beyond the basic requirements.
Innovation: A forgiving culture toward imperfection often breeds innovation, as it removes the fear of failure.

The Bad

Perfectionism: The binary mindset—something is either perfect or not—can cause undue stress and project delays.
Analysis Paralysis: Overthinking due to high standards can result in inaction and missed opportunities.

The Balance

Celebrate Achievements: Focus on what's been accomplished. While code may never be perfect, "good enough" often is.
Flexible Quality Standards: This guide doesn't set specific quality standards, but the underlying principle is that multiple approaches can lead to stakeholder satisfaction. It's better to deliver a feature with excellent user experience on time than to deliver nothing because you were caught up trying to fulfill every single requirement and missed the QA deadline.
Realistic Expectations: Aim for doing your best. If something doesn't get completed on time despite best efforts, that's acceptable. Features can often be rolled out in phases; just ensure that each phase meets quality standards and avoids excessive shortcuts. Any shortcomings can be addressed in future iterations.

In conclusion, leading a frontend team in a dynamic environment is both a challenging and rewarding experience. The guidelines and principles shared here are not just theoretical musings but hard-earned insights from years of hands-on leadership. They aim to foster a culture of collaboration, quality, and continuous improvement. Remember, the journey to a high-performing team is a collective effort, one that requires engagement from every role—be it developers, designers, product managers, or QA. As you navigate the complexities of team leadership, may these insights serve as a compass, guiding you toward collaborative success and professional growth for you and your team.

List Your Way to Team Leading: A Frontend Team Guide

Eran Sakal — Mon, 02 Oct 2023 16:40:18 +0000

I've always had a passion for lists, mind maps, and productivity tools. There's something satisfying about reading lists or exploring mind maps crafted by others who are sharing insights from their own journeys. This post is my way of giving back to that community of knowledge-sharers by offering one of my own curated lists.

Three years ago, Kaltura expanded its portfolio by acquiring a company specializing in online classes and webinars—a product already serving hundreds of thousands of users daily. As is often the case when startups transition into enterprise environments, we faced the challenge of scaling the product while aligning it with Kaltura's standards.

At the time, I was serving as the frontend architect for our group. My boss approached me with an intriguing proposition: to temporarily step away from my architectural duties and spearhead the frontend development of this newly acquired product.

Now, having achieved the goals we set out to accomplish, I'm transitioning back to my original role. Along the way, I've collected insights and guidelines that I thought worth sharing.

In this article, I've broken down my mind map on team leadership into a structured format, covering Team Dynamics, Communication Strategies, and Time Management. In the second article I dive into Product Interactions, Backend & QA Collaboration, and Managerial Relationships.

Team Dynamics

Team Autonomy and Leadership

Feature Leaders and Ownership in Team Dynamics: emphasize the role of 'Feature Leaders.' Assign each feature to a specific team member who will take the lead. This designated leader becomes your go-to person for any stakeholder inquiries and is responsible for the entire process, from grooming the ticket to securing QA approval. Adopting this strategy can be beneficial for everyone: the feature leader gains valuable experience and responsibilities, while it also helps distribute the workload more evenly, reducing pressure on you as the team leader.
Keep the Team Informed and Prepared: Ensure that each team member is aware of their prioritized tasks and next steps. Maintain an individual backlog for each developer to serve as a backup plan. This allows team members to continue working autonomously and make context switches as needed, without being overly dependent on the team leader for direction
Minimize Distractions, Maximize Autonomy: Empower developers to work directly with peers from other teams, product, or design. Regular touchpoints keep everyone aligned, but the goal is to allow team members the freedom to resolve issues and make decisions without constant interruptions.
Distribute Work Evenly: Strive to balance the workload among team members by ensuring that everyone has a mix of tasks—ranging from feature development and bug fixes to support chores. This approach not only helps prevent burnout but also allows each team member to contribute to various aspects of the project. That being said, aim to assign specific features to individual team members for ownership, so they can feel a direct impact on the product.
Enable Autonomy, Stay Informed: Empower your team to take initiative, while keeping yourself updated and ready to step in when guidance is needed.

Conversational Dynamics

Daily Touchpoints: Engage with the team daily, even if briefly, to maintain a pulse on progress and morale.
Team Over Individual: Frame discussions around collective successes rather than individual contributions.

Collaborative Culture

Encourage Cross-Functional Recognition: Advocate for team members to be acknowledged by peers from other roles such as QA, product, designers, and developers from other teams.
Support Professional Growth: Recognize and support the team's aspirations for career development. It's important to note that growth isn't solely about ascending the management ladder; it can also mean expanding development capabilities, taking on more complex tasks, or assuming additional responsibilities within the team.
Promote Iterative Collaboration: Encourage developers to engage frequently with product and design teams. Hidden requirements often surface during development or testing phases. Releasing features in small, quick milestones is more effective than delivering a fully completed feature at the end of a timeframe.
- Note: This approach may require adjustments to the QA environment to facilitate testing of multiple pre-released features, a topic beyond the scope of this article.
Foster a Culture of 'Good Enough': Promote a mindset that values meaningful progress over unattainable perfection. More on this in Part 2 of the series.

From the Team Experience: How We Manage Individual Backlogs with Notion and Jira

In our team, we've adopted Notion as an unofficial tool for managing individual backlogs. We chose Notion for its robust capabilities to structure data effortlessly, allowing us to focus more on the tasks at hand. Each developer has a set of tasks listed in Notion, which cross-references the official stories in Jira. This dual-system approach enables us to maintain agility in our internal processes while ensuring seamless communication with other teams.

Adopting this approach has yielded another significant benefit: a unified platform for collaborative note-taking and feature planning. In Notion, each item exists as a distinct page within a hierarchical tree structure. This setup provides us with a centralized, shareable space for drafting designs, setting milestones, listing actionable items, commenting, and compiling questions. Without such a system, notes often remain siloed in individual notebooks, which can easily be misplaced, hindering the collaborative process.

Communication Strategies

Synchronous Communication

Opt for Chats Over Meetings for Syncing: While meetings are great for initiating feature development or brainstorming designs, they can be time-consuming for daily updates. For ongoing work, it's more efficient to establish a dedicated chat channel for each feature. Include all key stakeholders—developers, product managers, delivery teams, and QA—in these chats. This approach not only boosts productivity but also saves the team a significant amount of time compared to holding daily sync meetings for every active feature.
Feature-Specific Chats: Just as you modularize code by context, create a chat for each feature. The chat's lifespan should align with the feature's development cycle.
Feature Leader Ownership: While you may be in the chat, your role is to mediate and provide guidance. Engage when necessary, but otherwise, let the feature leader own the conversation.
Ad-Hoc Chats for Quick Resolutions: When issues arise that require immediate attention, create ad-hoc chats to resolve them swiftly and keep the feature chat noise-free.

Meeting Protocols

Efficient Scheduling:
- Keep meetings short and always share an agenda in advance.
- End meetings on time and summarize with a list of actionable items.
- Invite only essential participants to minimize time wastage, especially for your team.
Team Representation: You don't need to attend every meeting. Empower team members to represent the team in specific contexts, like STP meetings or feature sync-ups.
Meeting Attendance: Feel free to decline meetings or request agendas if you think your presence isn't necessary.

Written Communication

Address Defensive Messaging Promptly: If chat messages seem to carry a defensive or aggressive tone, initiate a call to resolve misunderstandings directly.

Product Requirements Tickets

Tickets as the Single Source of Truth: Ensure that tickets are well-groomed and clear to all stakeholders before development begins.
- Developer Ownership: Once approved, tickets are owned by the developer, subject to your and the product manager's oversight.
- Idle Tickets: Any team tickets not assigned to a sprint should default back to you.
- Flexibility Levels: Make sure the team knows how much leeway they have with requirements, so they can make informed decisions or raise concerns as needed.
- Adapting to Change: Requirements may evolve; developers should be prepared to adapt, but they should also feel free to engage you if they're uncomfortable with the changes.

From the Team Experience: Why Feature-Specific Chats Beat Daily Syncs

In the fast-paced world of frontend development, striking the right balance between effective communication and avoiding meeting fatigue is crucial. In our team, we've cracked the code with "🧩 - feature-specific" chats. We use Microsoft Teams for internal communication, and it's incredibly easy to spin up new chat groups. Each chat kicks off with a smiley, chosen by the feature leader, which adds a fun and personal touch while making the chats easy to locate. Ownership of these chats lies with the feature leader, and I step in only when necessary.

Time Management

Sprint Planning Meeting

Prioritize Quarterly Commitments: These aren't just your own commitments; they're your team's as well.
Delegate the Promotion of Support Tickets and Bugs: It's neither realistic nor necessary to address all support tickets and bugs immediately. Some may be rejected, while others may require further input from product teams or may not align with the quarter's commitments. Product, delivery, and QA teams are often the experts in these areas. They're best positioned to identify and flag urgent issues, so let them take the lead.
Tip: If the sprint seems to be bug-heavy, ensure it doesn't jeopardize your quarterly goals and communicate any concerns.

Team Dailies

While I have a lot to say about dailies, I'll stick to the highlights here:

Engage the Team: Consider kicking off with small talk or a quick interactive activity, like a Miro board. I was skeptical at first, but it's become second nature and has actually made our meetings more enjoyable and less of a chore.
Punctuality Matters: Always start on time.
Keep It Brief: Our dailies are scheduled for 30 minutes but usually wrap up in just 6-10. Keep in mind that time spent in meetings adds up, affecting everyone's productivity. Plus, team members often have multiple meetings each day, which can disrupt their focus on actual work.
Be Concise: Keep the daily focused on reviewing ongoing developments, identifying bottlenecks, and clarifying any ambiguous requirements. Make sure there's room for team members to voice their concerns. Remember, this isn't the time to dwell on past efforts; it's about paving a smooth path for the day ahead.
Take Irrelevant Discussions Offline: If a topic isn't relevant to everyone, politely pause the discussion and suggest taking it offline with the relevant parties.

From the Team Experience: Navigating 650+ Joint Dailies

In our team, we've put the principles outlined earlier into practice. Our daily stand-ups are quite inclusive, featuring a product manager, a delivery manager, five QA professionals, an occasional backend team representative, and our four-member frontend team, myself included. We have the unique advantage of "dogfooding" our own collaborative meeting product, which allows us to test new features during these dailies.

Given the diverse attendance, we aim to wrap up the core discussion quickly without sacrificing small talk. We employ a "funnel approach," where attendees gradually exit the meeting as we narrow down to topics relevant to smaller subsets of the group. Ultimately, only the frontend team remains, and we use that time to focus on team-specific issues. The entire meeting can range from 6 to 20 minutes, and thanks to this structured, funnel-like approach, our dailies remain efficient and far from burdensome.

Product Showoff Meetings

These meetings usually kick off a new sprint and celebrate the achievements of the previous quarter.

Let the Team Shine: Encourage team members to present the features they've been working on.

Quarterly Planning

This can vary from team to team, but here are some insights tailored to highly communicative and proficient teams like mine:

Allocate Time for Unknowns: Reserve some bandwidth for support tickets and requests from the server team.
Limit Ambiguous Features: Aim to include no more than one or two features that require extensive R&D or lack clear requirements.
Use the 'Stretch Goal' Tag Wisely: Only tag tasks you genuinely believe can be completed within the quarter.
Identify and Communicate Risks: Make sure the product team is aware of challenging features so they can allocate resources more effectively.

In this first part, we've delved into the intricacies of team dynamics, communication strategies, and time management. These foundational elements set the stage for a high-performing frontend team. But the journey doesn't end here. In the next article, we'll explore how to navigate relationships with managerial staff, the product team, and peer development & QA teams. As you apply these insights, remember that the key to effective leadership is adaptability and a commitment to continuous improvement.

Thanks to Anna, Tornike and Stas for the joyful journey. Luckily it is not a good bye, as we will continue to work together on the product architecture.

Cover image crafted with Picsart.

A Guide to Effective Code Reviews

Eran Sakal — Mon, 27 Feb 2023 09:00:00 +0000

Pro Tip
As someone who's used many different code review tools over the years, I can confidently say that Reviewable stands out as one of the best. It's a game-changer that makes code review and feedback easier than ever before. If you believe in using the right tool for the job, I strongly recommend giving it a try. I've been a true fan for five years now, and I'm not affiliated with Reviewable in any way. Give it a try and see for yourself!

About Our Product: Where All the Code Reviews Happen

I work at Kaltura, a leading software company that offers a comprehensive video platform for streaming, uploading, and publishing videos across various platforms and devices. As part of my role, I'm a member of the team developing Kaltura Meetings, a modern application that facilitates live online classes, webinars, and meetings with interactive features. With its complex architecture, and numerous features and integrations, effective code reviews are crucial to ensure the success of our product

Is the Main Purpose of the Code Review Assignee to Approve Code?

Everyone loves the feeling of writing LGTM ("Looks good to me") on a teammate's code review. It shows that their opinion matters because the pull request can be approved and merged thanks to their cooperation.

Code reviews are a wonderful opportunity for developers to provide feedback and influence their teammates' coding styles and implementations, but that's only if the reviewers know how to provide constructive feedback. Sadly, some reviewers tend to dwell on insignificant details like personal coding preferences and can hold up the entire review process. They act like perfectionists, and it can take an eternity for them to be satisfied.

Some people might feel uncomfortable with my statements above, and they should because it is easy to lose sight of the reason people conduct code reviews.

The Importance of Conducting Effective Code Reviews

Conducting a good code review is not about LGTMing someone work. It is also not about making your teammate's code look similar to how you would write it. It is about highlighting some areas in the code that are not aligned with the requirements, might lead to undesired runtime behaviors, impact performance and stability, or introduce security holes.

The Role of Design in Code Reviews

Effective code reviews require a well-defined feature design that has been thoroughly reviewed and approved before the code review stage. If design flaws are discovered during code review, it may indicate that the team missed something earlier in the development process. It's important to ensure that the feature design is sound before moving on to the code review stage to prevent potential delays and issues.

Although technical design meetings are a popular way to approve a design, I usually don't find them necessary. Often, the design simply mirrors the application's existing architecture and those meetings are not needed. When extending the architecture or suggesting a new approach, I usually recommend on a brainstorming sessions and short cycles interactions until the design is approved. When conducting the code review the design should be already known to all the reviewers.

Developers are human and might make design decisions that need to be changed during the code review process, but this should be the exception rather than the norm. As for when to expect design flaws during code review, it's important to consider the developer's level of experience. Beginners or newcomers to the team might be less familiar with the application's architecture and design. It's important to remember that the code review process is a collaborative effort, and developers should strive to give constructive feedback while considering the experience level of their peers.

A Step-by-Step Guide to Conducting Effective Code Reviews

Every developer has their own preferred method of conducting code reviews, and in my case, the following framework has led to more productive outcomes.

Step 1 - Understand the Requirements

The reviewer should start by reading the requirements and making sure they make sense. Understanding the needs will lead to more constructive comments. While reading the requirements, it is the time to put the rigorous glasses, ask questions, and ensure that the requirements are complete, clear, and consistent with the existing behaviors of the application.

Step 2 - Challenge the Application

After confirming the requirements, it's time to dig deeper and get hands-on with the application. As a developer, I recommend putting on your curious glasses, rolling up your sleeves, and playing with the application. To ensure code quality, I suggest reproducing at least 80-90% of the use cases covered in the requirements. This approach helps identify potential issues and ensures that the code is working as intended.

Some people might say this is the QA responsibility and not the a developer's one. As I see it, the developer is responsible for ensuring their deliveries are aligned with the requirements and avoiding apparent discrepancies. Any discrepancies you find between requirements and implementation that are resolved during the code review, will lead to higher delivery quality, shorten the time to production, have more positive interactions with QA people, and have fewer escaping bugs.

This step might require additional setup. There are many ways to automate it. Some people integrate their repository with Vercel or Netlify, services that build and serve your application directly from the pull request. Others are okay with pulling and playing with the repository on their local machine. Whatever option you choose, don't skip this step. Reading hundreds of lines of code and verifying them is for compilers. Humans manage better with visual UI. Playing with the application can help you identify issues that you might miss when just reading tens of files in a diff.

Step 3 - Prefer the red pill

Even if things look legit and working, they still need to function correctly under the hood. They could look okay but fail later due to a wrong application state or unexpected asynced events handling.

If the code review is on the backend parts, you should always have unit tests verifying the outcome and the process that led to that outcome. If you don't have unit tests covering the backend logic, please spend time with the team and discuss about ways to include them in the development process. Unit tests are crucial for backend areas. On the frontend side, it is harder to write unit tests due to the nature of the browser rendering framework, so the decision between cost and value is not as straightforward as in the backend.

If the pull request you are reviewing is on the frontend parts, there is a golden egg that, if used wisely, will make your current and future you much happier. I'm talking about having high logs coverage, letting you fully understand what happened. As frontend applications are based on async flows, and usually, many flows run in parallel, your logs should take it into consideration and reflect it in a way that will later let separate and focus on the events that interest you. This level of logging can help you trace through the logic of your application, find the root cause of issues faster, and reduce the time spent on debugging. While it may take extra effort to implement and maintain, the benefits of having high logs coverage far outweigh the costs. Moreover, it will be easier to maintain as the project scales up and more developers are involved in the project.

Having applicative logs on the frontend application is not heavily adopted by developers for various reasons. I will keep my thoughts private about why it is uncommon, but I encourage you to try it.

My team took it one step forward in our application, Kaltura Meetings. We are not logging things into the console or relying on the network browser devtool tab to try and understand what happens in our application. Instead, we have our own dev tools tailor-made to our needs. Those tools let us read, search, filter, group, and deduce things from the logs.

Assuming your application exposes logs, you should check them when you run the requirements to ensure the events raised and the app state changes reflect the desired outcome.

Step 4 - Review the code

If you follow the previous steps, you now better understand the feature, and your review will be much more productive. Try to focus more on performance, problematic implementations, and areas that are not following the guidelines or are not aligned with the style guides of the team.

Addressing the Most Common Concerns: Time Constraints and Deadlines

One of the most common arguments against code review is that it takes too much time and is not feasible within the constraints of a team's deadlines. While this argument is understandable, it's important to recognize that code review is a key aspect of ensuring high-quality code and avoiding costly errors in the long run. In fact, by catching issues early on, code review can save time and resources down the road. Additionally, there are many ways to streamline the code review process, such as setting clear guidelines and using automated tools to speed up the review process. Ultimately, while code review may require some upfront investment, the benefits it provides in terms of code quality and reliability make it a worthwhile practice for any development team.

Key takeaways from the code review process

If done correctly, code reviewing is essential to the development process. It leads to knowledge sharing, mutual responsibility across the team, and better deliveries. But if done incorrectly, it can lead to a negative atmosphere, lack of trust among the team, and poor deliveries.

I wrote an article about code reviewing two years ago, and I'm happy to see that my framework hasn't changed much over the years. If you're interested in reading more about code reviews, I recommend checking out my previous article, 'The Role of Code Review in the Overall Development Process'. I believe it's still relevant, and might add more insights to this article.

Enjoy the day,
Eran

Thanks to my teammates Anna Yurkevych, Tornike Menabde, and Stas Kogut for making the workdays interesting and meaningful.

Photo by Markus Winkler on Unsplash