Expert Opinions: Server-Side Rendering and Standards

As the web continues to evolve in 2018, developers need to know whether to rely on client side or server side rendering—or whether there’s a middle-ground approach. Our SVP of Developer Tools, Jason Beres recently had a chance to sit down with Stephen Fluin, Developer Advocate on the Angular team at Google.  This is the third of three parts of the conversation including the future of Native apps vs. PWAs, this post about Server Side Rendering, and one more with the Angular team’s advice for Enterprise Developers.

Jason Beres: In your keynote at Angular Connect, you talk about the benefits of server-side rendering. If I'm looking at things like search engine optimization, is there a benefit to using server-side rendering versus pure client side, or is there a negative effect? 

Stephen Fluin: It always depends on your audience. You should look at the specific situation, but for example, the Google web crawler is able to run JavaScript. So Angular applications, if you have the right polyfills, they will index perfectly.

Follow your routes. Navigate across your application. Get all your content index,  all that stuff.

Other search engine crawlers don't necessarily run JavaScript. So if those other search engines are important to you, then that's going to be a driver towards server-side rendering.

But the other thing I would look at is; do you have a share button in your application or do your users want to copy and paste your URL's and put them on Twitter or Facebook? Because those kind of scrapers, those web crawlers that social media platforms have also don't run JavaScript.

So being able to share a link and then have them by a single HB-request get out the bulk of your content and the images and things like that increase the connection to those platforms. And so that kind of also drives you to server-side rendering.

Then the last piece about it from my perspective is that it increases the perceived performance. I say perceived performance because technically you're actually slowing down the process with server-side rendering. By server-side rendering for users, you're giving them a fully rendered version of the application by HTML, because then the browser has to parse and then it bootstraps JavaScript and runs the application on top of that. And ultimately that's I think what enterprises are looking for.

It renders the page and then it renders the page with it. So if I look at every millisecond of performance, it's actually slower.

But because it's increasing the perceived performance, that's usually what matters.

Beres: I think a lot of the world was all server side rendering, then we came to client side rendering the last five to seven years, and it's interesting that you guys are, not going back to, but introducing a server side option in your framework.

Fluin: Yeah. Exactly. And for me, I give a talk at another conference called "What's up with the Web," because I find this really fascinating to watch how there's been a pendulum swing back and forth between client and server and right now the pendulum is swinging, or has swung far toward the client because experience is so key.

Every millisecond that I delay or interrupt my users I'm losing engagement. I can't quite come up with the number off the top of my head, but it's something like if you disengage a user or if you have them wait for a loading screen for more than four seconds, it's like a 60 or 70% chance they're going to disengage and go task switch, think about something else.

And so whether you're serving your employees and you're losing their focus or whether you're serving customers and you're losing their sales, these are both a really big deal.

Beres: A lot of the discussions we have as a vendor delivering solutions like component libraries is around questions like; “Where's the web going? What's the best decision to make?” And there really is no standard, but I believe the good thing about Angular is that you guys are providing a more complete, prescriptive framework that developers can get behind. It’s like, “We're here. It's ready. It's primetime.”

You said at Angular Connect, "Thank you but we're sorry," to the folks that were using the beta versions and the RC versions. I think that's the right approach because you're building that trust, but now that you're on Angular 5, we're seeing more growth in Angular. And really it's because of the prescriptive guidance that you're pushing that gives a little bit of certainty and standardization moving forward.

And ultimately that's I think what enterprises are looking for.

Fluin: Yeah, I mean we're seeing huge growth as well. There are tons of production applications that launch every day using Angular, which is kind of really exciting to see all of our hard work paying off, kind of Angular coming back to the main stream so to say after the Angular JS to Angular 2 switch.

When it comes to stability, I really think that's key for developers, but at the same time we have to balance that with innovation. I really like how we've positioned ourselves for the future where we can keep you developing applications the way you learn. So you learn Angular and then you write applications one way. And then we can kind of automatically take advantage of the web as it continues to progress for you.

And I'll give a couple examples of this.

WebAssembly is a really cool new technology, but you shouldn't actually be shipping WebAssembly today for a lot of use cases.

But, as the Angular team, we're in a really unique position where if at some point WebAssembly makes sense for how you should be delivering all web applications, we could actually flip a switch and then instead of compiling down to ES5, we could be shipping WebAssembly. Then depending on bootstrapping, handling all the connected piece, all the dom communication for you and because we've had this platform approach, we're really uniquely positioned to do that.

And another example is the shift around ES modules. So ES modules have been a spec standard for a while. But they didn't actually exist in the browsers until basically this year. Like WebAssembly, it's maybe not the best idea today to try and ship an application with ES 2015 modules for search quality and for other reasons. But when that does make sense, or if there's a way for us to ship an application that automatically opts the user's modern browsers into those sorts of things for performance gains, we can do that for you because we're the ones handling the build tool chamber, the ones handling the bootstrapping for you.

I'm really, really excited to see the web continue to evolve and Angular developers being able to just turn a switch on or getting, receiving all these benefits automatically by default.

Beres: How do you see WebAssembly evolving in the next few years?

Fluin: I don't know. I think it's really exciting. We've almost gotten to a point where JavaScript was the assembly of the web, but obviously, WebAssembly's far more performant. I think it's going to evolve dramatically in the next couple years as we, as people start trying to use it. As they encounter all of the issues of cross-project compatibility, run times ... kind of permissions issues. We're going to have to work through all those things before every application, every site can take advantage of it.

Beres: For specific verticals, like financial services where they're building internal apps where every nanosecond counts, and performance is the primary goal.  So if dev teams can use any technology that will improve any type of performance, it could be interesting for them but I was intrigued when I saw WebAssembly a couple years ago at Google IO, and it's interesting to see that it's slowly making its way up the ladder, right.

Fluin: Yep. Exactly.

Beres: I mentioned Material earlier and there was a lot of talk about Material at Angular Connect. How do you see Material evolving or have do you see its use by Angular and other platforms over the years and is Material something that you guys are focused on? Or are you focused on other design languages as well?

Fluin: Sure. The Angular Material team is kind of focused on two things. First, they are focused on taking Google's Material Design philosophy and manifesting that philosophy as a set of usable components that give you the Material Design aesthetic kind of out of the box. If you add Material to your project, it's going to feel like a Material application. And that's really important for a lot of teams to have that from Google because we came up with Material design, we ship Angular, so having a default, “hey, I don't want to do any time thinking about my design.”

Beres: Like clarity. Use it and you get what you expect.

Fluin: Yep. So, Material ends up serving as kind of a great default, so to say. But then the other half of what they're doing is the CDK or the component depth kit which is designed to enable other people to build fantastic component libraries. It's really important to me at least that we have a healthy ecosystem of design philosophies, of approaches to component, of enterprise-grade solutions that solve the different problems. Material is never going to solve everyone's problems.

And so having us providing tools that help other component authors and vendors move faster, provide better quality user experiences, it's really their second mission.

I think if we look forward five years from now, that team is maybe still somewhat focused on Material, but they're also responsible for making all of the other component libraries successful.

Beres: What I hear a lot from our customers is, “Is it Material based? Does it work with Material?” So I think Material is getting that traction anyway because it's a beautiful stylized library, it has a beautiful look and feel.

Fluin: It feels very consistent across platform.

###

We’d like to thank Stephen Fluin for his time in this interview, and invite you to check out more of what he has to say over at the Angular Blog. To learn more about Infragistics’ support for Angular, check out our Ignite UI for Angular page. ICYMI- Here's part one of the conversation, and part three is available now.