Challenging Issues in Front-End Platforms
One of the most challenging aspects of working with front-end platforms is solving difficult problems related to user interface design and functionality. These obstacles can require a deep understanding of HTML, CSS, and JavaScript in order to create effective and responsive web applications.
The world is changing because of software. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
Sylor-Miller: I've been a frontend platform engineer for at least the last 10 years. We've felt a little like nobody knows what to do with us. We tend to own bits and pieces of infrastructure but we didn't really fit in very well with DevOps or SRE. We often own large parts of the product code base, but we aren't product engineers. We've never really fit in anywhere. I'm really excited to be here, because it feels like we're getting a seat at the cool kids table finally. I've found my people.
When I was preparing this talk, I chatted with folks that I know that are more like DevOps, SRE, backend, they don't work on the frontend. I wanted to get a sense of like, what do you think about the frontend? A few different themes emerged from those discussions. What I heard from folks overwhelmingly, is that the frontend feels like it's super complicated for no reason. The tech changes super rapidly. There's approximately 5000 different libraries and tools and patterns out there. New ones come out every day, so we don't know how to keep up. I heard a lot about how HTML and JavaScript and especially CSS are really frustrating to work with. How many of you feel this way? My hope is
Given that frontend platform teams are in the unusual position of having two clients, I believe that this is particularly crucial on the frontend. Initially, the engineers who are developing our product make use of all the instruments, services, and materials that we provide. We also have the second order customer of the actual users of our websites and web apps. In an ideal world, we would never give engineers tools that are going to be really terrible for UX, and vice versa. We don't want to make decisions that are great for the user experience, but make it harder to ship features. That seems like a no-brainer. In reality, this tension between the needs of engineers and the needs of
But that's only the very tip of the iceberg. Beneath the surface is an immense amount of complexity, encompassing all the processes and decisions we make to enhance the developer experience, all of which bear a significant influence on our users. The client-side JavaScript libraries you employ are not as important to your end users as how you choose to architect your design system, manage dependencies, conduct experiments, or build and deliver content. This entire iceberg is your front-end architecture. Our goal is to steer clear of a frontend complexity iceberg collision on the scale of the Titanic. We're going to learn more about it. We're going to start by developing a
What are the most challenging issues and limitations that web development, and particularly frontend platform development, faces? I will discuss nine now. Many of them, in my opinion, are the most difficult and crucial tasks that your platform ought to be abstracting away for you. I chose these for that reason. The global web's design, which consists of HTML, CSS, and JavaScript, is the first limitation we must overcome. The initial intent of the web was not to serve as an application framework. This is what the original website that was made in 1991 looked. You are welcome to view it now. As you can see, it's just a bunch of text and some links. There's no images. There's no multimedia. All there
What is required to create a webpage? A web browser client and an internet-connected web server are required. To add interaction, you'll need JavaScript, CSS to design the content, and HTML to establish the page's structure. I think the important thing for all of us to think about is the fact that all three of these languages are uncompiled, static text files. You don't build a binary then ship it to a web browser. It's uncompiled, static test files. Anyone can open up their favorite editor and type some words and symbols, and then FTP them up to a web server, and you have a frontend platform. FTPing static files to a server doesn't scale. In order
The fact that no single firm or browser vendor owns the internet presents the second limitation we must overcome. The World Wide Web Consortium (W3C) also goes by the name TC39, which stands for the ECMA International JavaScript standard body. The goal of the standardization process is to reach a consensus. The rate of change will always be extremely slow while attempting to reach consensus. It is imperative that all parties collaborate and reach a consensus over the appropriate APIs to develop and their design. Subsequently, it is up to individual enterprises to decide whether or not to adopt the requirements. Over time, a great deal of the complexity has developed because engineers and
Users come first when it comes to the web, which is the third difficult issue. tremendous power with a tremendous deal of responsibility. We need to make sure that everyone can access the web while also safeguarding user security and privacy. I adore how the W3C addresses this and refers to it as the constituency' priority in their recently published web platform design guidelines. Users' demands come first, then those of webpage authors, then those of user agent implementers, then those of specification writers, and lastly, theoretical purity. The absence of theoretical purity is fantastic since it feels so subtle. Theoretical purity was mentioned, and someone said, "No, that's last." I am a member of the W3C Performance
Users come first when it comes to the web, which is the third difficult issue. tremendous power with a tremendous deal of responsibility. We need to make sure that everyone can access the web while also safeguarding user security and privacy. I adore how the W3C addresses this and refers to it as the constituency' priority in their recently published web platform design guidelines. Users' demands come first, then those of webpage authors, then those of user agent implementers, then those of specification writers, and lastly, theoretical purity. The absence of theoretical purity is fantastic since it feels so subtle. Theoretical purity was mentioned, and someone said, "No, that's last." I am a member of the W3C Performance
Users come first when it comes to the web, which is the third difficult issue. tremendous power with a tremendous deal of responsibility. We need to make sure that everyone can access the web while also safeguarding user security and privacy. I adore how the W3C addresses this and refers to it as the constituency' priority in their recently published web platform design guidelines. Users' demands come first, then those of webpage authors, then those of user agent implementers, then those of specification writers, and lastly, theoretical purity. The absence of theoretical purity is fantastic since it feels so subtle. Theoretical purity was mentioned, and someone said, "No, that's last." I am a member of the W3C Performance
The network is another thing you can't rely on. On the web, there is a whole additional category of design choices that are strategies to get over unstable network connections. This is essentially due to the fact that each request you submit presents a fresh chance for failure. You run the risk of either losing connections in the middle of a session or having a slower connection that negatively affects the user experience. A browser's cache keeps your assets for you, reducing the need for web browsers to traverse the network and re-request each file. We are currently facing one of the two most difficult challenges in computer science.
The fact that browsers are single-threaded is the next limitation. There's a tiny asterisk there because I have to provide a disclaimer. Multiple threads and processes are operating in modern browsers. The browser's main thread is not the only thread that performs tasks like networking. Certain items are handed off to be multi-threaded in newer browsers. We're going to take a crash course in browser operation so that you can grasp what I mean when I talk about why it's so vital that web browsers are single-threaded. I go extremely deep into this in a session I delivered a few years back titled Happy Browser, Happy User. Let's go over the traditional interview, which is similar to what occurs when I type a URL into my browser.
Index.html is the HTTP response that my server provides. The browser begins parsing the file into the DOM tree, often known as the document object model. Recall that this text file is static and uncompiled. It must transform it into this representation tree structure, which is an in-memory representation of the HTML document. After reading through and parsing my HTML, the parser finds links to CSS and JavaScript and uses the network to send HTTP requests for those. Because CSS has a higher priority, it is requested and returned first. All of that CSS is sorted by the browser and stored in a different tree known as the CSSOM, or CSS Object Model. This tree structure is different. It essentially removes all of that.
Now, let's discuss JavaScript. That returns across the wire and is processed into still another tree. Trees are beloved by browsers. The JavaScript AST is the name of this one. The JS AST is essentially compiled into machine code. The code is run by the browser. Then it starts this runtime event loop pattern in JavaScript, which is akin to an asynchronous message queue that runs continuously in the background. An overlay for login appears when the user, for example, taps on the screen. An event is created by that action and is added to the event loop. The code of any event handler that is waiting for that event is performed. The DOM tree is then directly modified by that handler code, initiating the re-rendering of the render tree, relayout, and
Since the browser is single-threaded, all of these operations are taking place on a single thread, which is why I wanted us to fully get it. When considering web architecture and performance, this is crucial. The main thread won't be able to reply to the user in a timely manner if it is trying to download, parse, and execute three gigabytes of JavaScript while the user is attempting to scroll the page. We need to animate at 60 frames per second in order to achieve a fluid scrolling experience. The browser cannot animation while it is performing other tasks; it will drop frames and you will have to
We are currently discussing observability as our final hard challenge. In the front end, observability is challenging. Considering everything else we've already covered, such as the fact that you don't own the execution environment and that network connections can be erratic, user privacy essentially means that the user has the opportunity to fully disable any telemetry collection. There's also this other issue in physics known as Schrodinger's JavaScript, or the observer problem, as I like to call it. You need to write more JavaScript that runs on the same main thread as all of the code that actually makes your website operate if you want to keep an eye on the health of your website, which is undoubtedly executing a lot of JavaScript. If you're not cautious, attempting to
We're going to tackle the elephant in the room, which is all of those millions of different frameworks and libraries that feel so hard to keep up with, to finish off our topic of why the frontend is so complex. I believe it helps to approach this issue historically, using the client-server pendulum as a guide. When I first started creating websites back in the day, some twenty years ago, there was essentially a single way that everyone did it. On the server, you generated multi-page applications. You use a server-side language, such as PHP, the.NET framework, or ColdFusion, to build your HTML answer. After that, you would add a small amount of CSS to make it seem good. Next, you employ jQuery,
The swing of the pendulum occurred. We began utilizing frameworks like React and the single-page application architecture to help develop better web app experiences. This means that rather than including your HTML in the first payload, you transmit this large JavaScript bundle. Once it has executed, it changes the DOM tree directly in memory to produce pixels on the screen. We choose to pay off faster page loads in exchange for a far better user experience when engaging with a website. This is because HTML is loaded inside the client rather than over the network. As React gained popularity, more and more individuals began utilizing it for everything.
The balance has shifted slightly in favor of the middle in recent years, and networks are now speedier. As low-powered mobile devices become more common, particularly in emerging economies, the user's device's CPU is increasingly the main bottleneck. These new frameworks and patterns that combine the best aspects of the two previous techniques have emerged. Server-side rendering (SSR) is the process of rendering your initial view on the server using JavaScript. The client receives the same JavaScript after it has been hydrated, at which point it assumes control of the interaction. You have the option of having it take up the entire page or only small, interactive "component islands" on your website. Each of these
The balance has shifted slightly in favor of the middle in recent years, and networks are now speedier. As low-powered mobile devices become more common, particularly in emerging economies, the user's device's CPU is increasingly the main bottleneck. These new frameworks and patterns that combine the best aspects of the two previous techniques have emerged. Server-side rendering (SSR) is the process of rendering your initial view on the server using JavaScript. The client receives the same JavaScript after it has been hydrated, at which point it assumes control of the interaction. You have the option of having it take up the entire page or only small, interactive "component islands" on your website. Each of these
The next significant move is to let it go, just like Elsa did. Give up trying to control every little thing; oddly, your website or web application will be more durable the less you try to control it. Steph Eckles said, "Using adaptive layout techniques is a trust exercise between designers, developers, and the browser." I think this is a great quote since it really gets to the heart of things. Here, Steph is particularly discussing letting go of the notion of pixel-perfect layouts. The concept of coding within the browser and having faith in it to perform well applies to all the various methods we have to build within the limitations we discussed.
The second fundamental approach to managing complexity is to become more similar to our users. By that, what do I mean? We are all members of a privileged few in this room, possessing powerful contemporary electronics and dependable, quick, and steady internet connections. The majority of our users do not experience the web in the same manner that we do. We use high-speed computers and fast connections while working at our workstations to create and test websites. This is not a packed metro car with sporadic coverage of the internet. This chart is from Alex Russell's talk, The Global Baseline in 2022, which he gave at the performance.now() conference last year. This is a Geekbench historical graph.
My sort of high-level approach to managing the complexity is to leverage the capabilities of contemporary HTML and CSS. I always seem to be complaining about standards. These days, it seems as though browser standards are not only catching up, but also advancing quickly thanks to new platform capabilities. What they do is take all of the functions for which you previously had to write a ton of JavaScript in order to accomplish them in the browser. For example, you no longer need to write JavaScript in order to center a div. Come hang with me in the JavaScript anti-JavaScript club. JavaScript is my favorite language. My favorite programming language is JavaScript. My preferred activity is not writing.
Which architecture is best? Since I work as a staff engineer, I get to say my favorite sentence here, but it depends. I created this website, Ask a Staff Engineer, since I adore it so much. Go there whenever you have a query for a staff engineer, and they will respond, "It depends." The requirements of an e-commerce website will differ significantly from those of a software as a service business. There isn't a solution that works for everyone. We must consider trade-offs. We begin as usual with our users. Consider the user experience you are providing. Are you generally showing static material so that the server can render your HTML? Does your content focus more on tasks and interaction? Probably a good idea to check out SSR
When choosing a frontend architecture, you also need to consider your business objectives. One of the factors will be your consumers' location and the type of gadgets they usually utilize. You will need to give performance even more thought if you hope to expand your user base in India, where the majority of people use Android smartphones with inferior specs. Consider supporting a progressive web application as well. SEO is very important, especially for media and e-commerce. Everyone should be concerned about SEO. Google now considers your site's performance when ranking results thanks to the introduction of Core Web Vitals. When it comes to e-commerce, speed is everything.
Lastly, it's critical to consider the expertise and background of your team. You may be a media company and you're thinking, "We got to care about performance now, what do we do?" Even though all of your frontend engineers may already be familiar with React. Most likely, you should check out SSR. Your React components should be rendered on the server, and when you go to the client, you should layer on component islands. Consider the size of your platform staff as well. Selecting dull technology is probably a better idea if your team is smaller. I'm glad Suhail mentioned selecting uninteresting. My employment at Etsy is the reason behind my selection of the dull tech club. My team selected dull technology. Select items with a large ecosystem.
You can begin choosing the appropriate architecture when you've considered each of these many aspects. Perhaps distinct architectures are needed for different sections of your website. I adore Ryan Townsend's analysis. Just recently, he delivered a lecture titled "The Unbearable Weight of Massive JavaScript." He recommends, in fact, employing distinct strategies for each e-commerce site pages, taking into account all of the various aspects we have discussed, such as static versus dynamic content, SEO, performance, and interactions. The idea of having to support four distinct architectures—one for each page—terrifies the platform team. To flip that around, I would certainly suggest that developing a platform that can handle four distinct rendering patterns, and
Many of you felt that the frontend was just too difficult when we first started. I hope I've convinced you otherwise. I've persuaded you that the frontend does, in fact, handle some of the trickiest computer science problems, such as distributed computing, asynchronous input/output, and not controlling the execution environment in which your code runs. There is a reason why the solutions we have work. That CSS is written that way for a very good reason, despite the fact that so many people find it annoying. I really want you to focus on core web technology as the primary takeaway from this. Avoid falling by the framework's marketing hype. Recognize the fundamental causes of the intricacy.
Individual 1: I have also been developing websites for a considerable amount of time. Previously, we went through a slight rewrite every two or three years and it was a new foundation. Though it seems like things have slowed down a little during the last three, four, or perhaps five years. Is it also what you've experienced? I can't remember a framework that has been around as long as React.
Sylor-Miller I believe that React has essentially taken control. React has become the standard for several reasons. Meta is investing a great deal of money and effort into shipping React. I believe that our industry has a propensity to seek out clear-cut, straightforward solutions. I'm going to utilize React just like everyone else; I won't give it any thought. I believe that's just the way things are; it's almost like a new mindset has emerged. That's just the way things are. You have to navigate and manage it because I'm a pragmatist. That, in my opinion, explains what we are witnessing. Many of these more recent concepts and frameworks are really
Sylor-Miller Frontend integration tests get my utmost support. Because having to fake out the APIs that are running inside of the browser when writing a unit test is the worst thing you can do, I really enjoy behavioral and integration testing. As of right now, the best choice for unit testing that I've seen is the React Testing Library. It's more of a behavioral driven test than a pure unit test, where you define additional actions that a user takes in the browser and then watch for the outcomes. Since there may be frontend code in the frontend backend code, you are most likely writing relatively few pure unit tests for your frontend interaction code.
Third Participant: Regarding taking this up with platform engineering, I have a query. Platforms are usually considered in terms of how to be Kubernetes but better. I believe that we frequently overlooked runtimes, [inaudible 00:41:29]. What do we not see? In what ways may platform organizations improve the lives of frontend engineers and expedite their work?
Sylor-Miller It's something I believe you should be aware of. Throughout my career as a front-end platform developer, I have had three different organizations to report to: infrastructure, UX, and product. I believe that because of the code we develop and the issues we solve, nobody knows what to do with us because our work affects the entire distributed system made up of all of these servers, web browsers, and other bits and pieces. Frontend engineering is perceived as being less cool by most people. Our pay is not as high as that of backend engineers. I believe and hope that platform teams will have to, particularly now that JavaScript is widely used.
Sylor-Miller I spent a good amount of time working on a design systems team. A design system's responsibility is to produce reusable user interface components that can be utilized by other engineers. In essence, they are Lego pieces that represent UI elements. We discovered that other developers were essentially using mustache views to copy and paste all of their PHP and HTML. That meant that each time we had to go in and make a modification, we were unable to locate the component because it was either slightly altered or copied and pasted incorrectly. There are so many various versions of everything that it would be difficult to fix everything's accessibility. This layer of abstraction was made by us in our
June 24–25, 2024 Practical advice to make clear the top development priorities of the day. InfoQ is hosting a two-day conference called InfoQ Dev Summit Boston, which focuses on the most important technical choices that senior software developers must make these days. Explore more than 20 technical sessions to gain life-changing knowledge about generative AI, security, contemporary web apps, and other topics from seasoned software developers. JOIN NOW
