At AscentCore, we invest in world-class talent to ensure we can build and deliver innovative digital products for our clients. Part of investing in our team includes learning about and cultivating their interests both inside and outside of their day-to-day activities at AscentCore.
AscentCore CTO Cornel Stefanche recently sat down with Cezar Derevlean, AscentCore’s front-end technical lead to talk about state-of-the-art happenings in the world of front-end web development.
Cornel: Cezar, thanks for chatting with me today! I’m going to start off by admitting that I’m not a great front-end developer and I’ve recently been focusing my time elsewhere. So I’m curious to hear from you about the latest developments in that space, specifically around React?
Cezar: Thanks, Cornel! It seems like the direction that React is going in is a lot of server-side rendering. The main argument for going, or getting close to server-side rendering until not long ago was SEO, but much more important that this would be speed. So, with the current tech, server-side rendering is often a lot faster.
There are multiple approaches to server-side rendering. Obviously, we’re not necessarily going back to getting the full page rendered again on every interaction. So something that you could do more recently was to generate everything on the server, serve the first batch, hydrate it, and then take it from there and do further interactions client-side rendered. What can Next.js do now, is something of its own kind of protocol where on every interaction that would modify the DOM, they can render on the server only pieces of a page and send that over to update the UI. Among other interesting new approaches is the islands architecture. You get your page rendered but non-interactive, and only certain “islands” are then hydrated and made interactive, prioritizing what’s closest to the viewport. This can mean a great performance increase. If I’m not mistaken, Astro were those who pioneered this idea and still successfully use it, with a very interesting benefit as well: ability to write different “islands” using different UI libraries (React, Svelte, Vue, Qwik etc.).
In the meantime, React itself is trying to solve this by going all in with React Server Components. This is still a really hot and controversial topic, so for now I’m not very keen on experimenting with something uncertain but I’m keeping an eye on it and I’ll try to be ready whenever its direction becomes a bit more settled.
Cornel: Got it. There’s a big difference between media content rich websites and applications that you want search engines to index. But if we’re talking about enterprise applications where you mostly show client data, I see no point in using server-site rendering in order to index.
Cezar: Agreed. And that has been the main focus of many discussions from the beginning of React – that if you want to do server-side rendering, you have to employ a slightly different approach and you would usually do it for SEO. But lately the discussion feels more focused on speed and performance rather than just SEO. And, as you said, a web application oftentimes isn’t something that search engines would be interested in. Especially because many are locked behind a login page.
This reminds me of something I’ve been experiencing lately with the Astro web framework. So Astro is essentially an alternative to Next.js, but in the sense that you would use it for content focused websites, which usually use a multi-page application rather than an SPA (Single Page Application). So if you have a blog or a presentation website or maybe even a small e-commerce site, Astro advertise themselves as the better choice. They have fantastic performance results. And if you have an SPA, then you should go with Next.js.
Cornel: What’s powering Astro?
Cezar: Astro is really lightweight as far as I can tell, and even though it’s not React, it offers the best of what React has. So you create components with the Astro extension and then you would write JSX-like syntax just like in a React component. . And that’s all happening on the server at build time. When that’s done, none of that JS will end up in the front-end. Let’s say you have a list of items, you would do a map on it which will return a list of items. That JavaScript will run on the backend ,helping you write the code faster and avoid duplication. But on the front-end, you’ll only have the generated HTML, just like a templating engine.
Cornel: So what other tools should we be aware of in the world of front-end development?
Cezar: Well, we have some newer frameworks such as Next.js and Remix. Next.js has become really popular over the last few years. Remix has been in closed beta for a while and now, besides getting investments from at least one really big and well known company, they’re open to be used by everyone. It’s a pretty good competitor of Next.js and it’s really gaining traction from the discussions that I’ve seen. I think even the CEO of Vercel, the mother company of Next.js, has admitted that they are doing many things very well, even better than Next, and that it’s very good to have this kind of competition, because it stimulates growth.
Cornel: Moving away from front-end libraries for a moment, I’d love to talk about something I’ve personally struggled with recently. I was working on a project and we decided that we needed to switch to a different component library – just something simple. But I had a hard time with select components, which can be really difficult. What is the current state of component libraries today?
Cezar: When I was first learning React, I started with Material UI because I wanted a solution for a component library. I didn’t know much about it, but I knew I needed something that implemented the material design approach. So I started from there and discovered that their components are made really well and they’ve just gotten more robust over time. I ended up liking them because of how well the components were built rather than because of the Material Design implementation. They were robust, customizable, and had a nice theming approach. So it became less about the design – I even used them in projects where I completely changed the theme.
They’re now on version 5 of Material UI and let me tell you what I like about them lately. So, previously people really struggled with where to put their styles in React. So putting them along with components usually made sense because that way you would put them where they belong. And if that component wasn’t rendered, those styles weren’t loaded. So putting styles along with the component was really nice, which is what Material UI did with a few approaches starting with CSS in JSS, and now moving to Emotion.
Another thing I like about this version is that there are a number of props you can use right away that are like CSS properties. They had the “ml”, “px” props and so on, which would stand for margin left, horizontal padding,etc. And you would put a value for that property and be able to position elements really easily without creating a class, without switching context – you would put it right there.
So, until recently, this was my go-to library for stuff like this. But now you have plenty of other polished solutions. To just name a few is MUI’s Joy UI spinoff, from the same folks who made Material UI, then there’s Mantine, and maybe 2023’s sensation, shadcn/ui, which has a beautiful and simple design, uses robust accessible Radix UI components under the hood, uses Tailwind CSS for styling, and delivers it via a very really interesting approach by letting you copy-paste and own the code instead of installing it as a package, and then you can do with it whatever you may.
Cornel: I think we could keep going on about this topic, but we’ll stop here. Thanks for such an interesting talk on front-end engineering!
