Technical Reflection from FrontEnd Con
by Anton Kononenko, posted 17/12/2019
Back in November I, along with some other Sonalakers, attended FrontEnd Con 2019 in Warsaw. The speaker lineup was impressive, with some very well known industry names in attendance, and an agenda with no filler.
After the conference, we got back together at SonalakeHQ to reflect on our biggest takeaways from the two days.
Server-side Rendering and Time to Interactive
Several talks focused on the subject of poor Time to Interactive (TTI) figures in the context of Server-side Rendered (SSR) web applications. This problem occurs with any framework – React, Angular, Vue.js.
SSR is a technique used to optimise First Meaningful Paint (FMP) so that users see the UI sooner, thus providing a better UX. FMP is particularly important for Single-page Applications (SPA) as all rendering happens in the browser and so is dependent on the performance of the user device.
The rendering flow for classical SPA is:
- Load an initial HTML page that usually contains only loading spinner or message
- Parse and execute code
- Load application
- Fetch data from server-side
- Start browser rendering
As we see, that a long list of things that need to happen before the spinner disappears and the application is ready for us – again, not a great UX. In ancient times, before SPA, all rendering happened server-side – what if we could use this technique to speed-up our SPAs? It turns out that we can!
The most common solution improve FMP scores is to use a mix of client-side and server-side rendering. We can use a Node.js server to run SPA on the server-side and send the resulting HTML at initial page load time.
The flow then looks like:
- Load pre-rendered HTML and data in place
- Parse and execute code
- Hydrate the application
Hydrate the applicate? Hydration is an alternative way of loading an application when it knows that it is going to receive pre-rendered HTML. In such cases, the application maps the HTML directly into the React/Angular/Vue.js components tree and adds the required event listeners.
From a user point of view, FMP occurs directly after the first step above however, the UI won’t be interactive because the application isn’t yet initialised. This can lead to confusion or frustration as users will start to click around the UI but nothing will happen. Again, poor UX.
Miguel Angel Duran spoke about this during his “React Rendering Strategies: Getting the most out of performance while keeping bots happy” talk presented some ideas on how to address this. The main idea is that when the HTML is received not all of this needs to be interactive. Quite often we have content which is not initially visible, for example, because the user needs to scroll. This means that components that represent those non-visible UI elements don’t need to be immediately rehydrated. Even more, those elements don’t even need to be fully rendered – instead, we can and display a placeholder and only load the real element content as the users scrolls to bring them close to being in view. This approach has the benefit of reducing the time required by the server to render the initial HTML. The result is improved TTI, but also FMP.
Minko Gechev, core Angular developer at Google, also shared some insights into the work his team is working on in relation to rehydration. His main thesis centred around delaying rehydration as long as possible and only performing it before it is strictly necessary. This work will form much the Angular teams future development focus.
Minko also mentioned Guess.js, a library that uses machine learning to predict the next page that users will navigate to using data from Google Analytics. Applications can use these predictions to preload pages to create a smooth user experience.
End-to-End Testing with Machine Learning
Benjamin Gruenbaum from testim gave a fantastic talk about about how machine learning can improve the way we go about creating end-to-end tests for frontend applications.
The biggest challenge for any end-to-end test is actually making it work with a real UI. We need to code meaningful CSS selectors in order to find each element and perform UI manipulations. This always takes time and it can be difficult to identify the correct CSS selectors. Previous attempts to capture CSS selectors automatically via user interaction recording worked, but the selectors tended to be very fine-grained and thus carried a high test maintenance overhead.
Benjamin’s goal is to use machine learning to help reduce, or even eradicate, the effort required to keep end-to-end tests up-to-date and to keeps builds green. Right now testim is a commercial tool, but there some opensource alternative such as puppeteer-recorder are developing in this direction.
Another application of machine learning to this space is test creation! The idea is to use actual user interaction and flow data, for example from Google Analytics, and an intelligent interaction recorder to automatically create tests. Of course, this would require some manual testing first but then additional test cases would be generated automatically. Doesn’t it sound great!
Alternative State Management for Modern React
Finally, Adam Klein during his talk on “State management in a world of hooks” presented an interesting library called reusable. It’s an alternative to Redux for state management. It doesn’t follow an event-driven approach, but rather focuses on sharing state shared across multiple components. It exposes one function that can wrap custom React hook, and make the state inside of it global. That’s basically it! The main benefit that it removes the need for boilerplate associated with sharing hooks.
Performance was a central theme and I’m sure will continue to be as we deliver more and more powerful web applications. In terms of frameworks, React looks like it’s still the boss, but Vue.js is becoming more established and is no longer a hype technology. Finally, TypeScript is becoming the default for frontend development.
Frontend Con was fantastic. On the whole, the quality of the talks was very high – it was also great to chat with engineers from other companies and share experiences. We’ll definitely be back.