The usual life of a developer is constantly training on new skills whenever new technology comes in, a new JavaScript framework that comes in, and spend hours learning about that framework. After learning, implement that framework in day to day life or in the project that he/she is working on and we try to improve the performance of the application.
Come next year, another new technology or framework comes along and takes away hours of a developers life in starting that framework and again implement that to make apps even faster; and the cycle keeps on repeating itself. This problem is never-ending. To overcome this problem, there is a new solution you can see, which is web components.
What are web components? They are independent of any of the frameworks, whether you’re working Angular, React or Vue. It works completely independent of that. The reason for that is, it is purely built using HTML and pure JavaScript, so it doesn’t depend on any of the frameworks, you can implement it in any of your applications or the existing application, you can convert your Angular product into web components and you can start building the application. The best part about web components is, it is supported by all the major browsers, and those who don’t support, we can implement that using Polyfils. That solves the major problems of selecting a framework before each product or an application that we start working on. Most of the time is consumed in exploration and research.
Most of the developers’ time is spent thinking about what is best for this application or what is best for this product, figure it out by doing analysis about Angular, React, or Vue, but this web components solves a major problem. You can just start implementing it.
But the other question that is important is about the performance. The performance plays a very important role in any online venture, high performance sites engage and retain users better than the low performing sites. As you can see, the slower the content loads on the screen, the greater the number of users keep going away from the application. In this fast paced world, we want everything to load within seconds, we don’t have time to wait for the content or to use an application. We just need everything fast, no matter if it’s a heavy application or a light one. We just need our content to be ready within seconds, so performance is also about retaining the customers or the users. It improves the user experience to a great level. As the content loads onscreen faster, users try to engage in our applications and try to stay on the applications for more time rather than just looking at the loading screen.
So, how to measure the performance of your application? There is an open-source tool called Lighthouse. It not only measures your performance but it gives you analytical reports of how to improve the performance of your application. It suggests techniques and the best part is it is open-source.
One of the techniques to implement or improve the performance is called Server Side Rendering (SSR) but before I move to the Server Side Rendering, let’s just see what exactly is a Client Side Rendering. In traditional Client Side Rendering applications, the browser sends a request to the server, we get a pretty HTML and a JavaScript tag where most of the JavaScript code lives. The browser again sends that request and tries to fetch in the JavaScript file. Once we get that file, we finally have our content rendered on the screen. Multiple requests just to lower the content on the screen. It just slows down the user experience and it frustrates the user. To overcome this problem, there is a technique called Server Side Rendering.
Server Side Rendering has been in the picture for a long time, since the existence of server programming languages like PHP, Python, Ruby or Java. Earlier, there was a lack of bandwidth and a lack of dynamic content available, but now as we are moving in this fast-paced world, the bandwidth is much faster as compared to earlier, and the dynamic content is available on a large scale, so Server Side Rendering comes around back in picture. What happens in a Server Side Application? How does it work?
What it does is it avoids additional round trips, it renders the application faster, it brings along the fast first ping and first content full ping and the rendering on the server makes it possible to avoid seeing lots of JavaScript in the client, which helps to achieve a fast time to render ratio.
As the content is loaded faster the user can start interacting with the website faster, as he/she doesn’t have to wait or see the loading screen for even a second. That is how you can improve any application within seconds. To achieve this technology, or to achieve a server side, there are multiple technologies available right now. If your product is in Angular, you can build your application using Angular Universal, which is a Server Side Technology.
If you’re working on React, then you can use Next JS. That is another big thing that’s coming up to easily convert your existing applications into a Server Side Application. So, the problems of content frameworks and how they’re all converging into the single platform called web components has been discussed. You have a single layer of web components that is reusable across all the frameworks. But we are not only limited to the web, how can we achieve this on mobile.
We have numerous devices that we access on a daily basis. In fact, recent studies show that we access our mobile devices for more than 15% of a year, that’s almost around ten years of our entire lifetime. This gives us an opportunity as the product owner, or the product company, or the mobile developers to reach our end users and to provide them a beautiful and interactive experience of a product. But the problem here is similar to one we were facing on the web. As we have multiple platforms, we have to build for multiple platforms, and to build for multiple platforms you have to set up multiple teams, and that comes along with a lot of cost. Huge cost. There are other problems as well; we have to maintain the consistency between two platforms or more platforms. So how do we achieve true re-usability? How do you have a single common interface that works across all these platforms?
There have been multiple efforts to resolve this issue and let us discuss all of them one by one, but before that I would like to take this opportunity to remind you about the approach called progressive web apps (PWA). This is an application that is completely offline, can be installed on the user’s device, and has access to all of the web APIs. The only thing that it lacks is, it doesn’t have access to the platform native APIs. What I mean by that is, if you want to access the users contacts or the sensor information of the mobile, you cannot do that with PWAs. The most important thing to note here is that if you have an existing website, we can easily convert that website to a PWA within just ten minutes of time.
The other approach that people are trying out, is the hybrid mobile web application development. You just wrap that website in a web view and you have all the access to the APIs, native APIs through the concept of Bridge. A bridge is nothing but a foreign function interface that is exposed from the native site. This is a native application architecture. The native code is directly communicating with the platform services and divisions. The other approach that we’ve been trying out is React native approach. React native lets us basically create a fully native UI elements with just JavaScript and React. So, you have your existing Web pin create the mobile applications for you as well and that gives significant cost saving.
But the problem is, even though this architecture is more performing than web view, it is still not compatible with the native application performance, but it works. We have now got the reusability, but we are lacking in performance. So how do you bridge the gap between performance and usability?
Flutter is an open source platform developed by Google which lets you develop the fully native applications faster with a single code base. What makes Flutter so fast when compared to the other approaches? Flutter basically gets pre-compiled to the native board, so it doesn’t have to go through the bridge every time, as in the case of React native. So, the most important feature of Flutter is called hot reload. The other thing which is really interesting about Flutter is that it already comes with different frameworks for Android and for iOS. It comes with the Material Design framework for android and it comes with the Cupertino framework for the iOS. The third and most interesting fact about Flutter is that, as the Flutters render engine is totally isolated from the core part, it basically allows Flutter to run on any device. Right now Google is only focusing on the mobile part, but Flutter can run on any device which has a display. There is already a project called hummingbird which is still in Beta, but we can expect it soon, in the next month it can release. With that project we will be able to run the Flutter code on the web as well.