As the world was still at Java's hand we often define what so called a component-based platform. I had this experience in the year 2000 with OpenUSS (Open University Support System). At that time I had an idea to develop a platform which is extendable using component architecture and J2EE technology (OpenUSS Component Architecture). After a while, we saw the birth of portal and portlet technology. Everyone tried to build portlets which can be easily installed in a portal server, all Java based. Do you remember all those portals like Apache Jetspeed, Liferay, JBoss Portal, IBM Websphere Portal, etc?
Today you still have those technologies like Portal, Portlet, and OpenSocial gadgets but they are not very compelling any longer. iGoogle is dead and nobody wants to use portal and portlet technology in their new web apps. All important web apps today don't use those portals, portlets, and gadgets anymore. The growth of these technologies is definitely going down to zero.
Generally, a Platform consists nowadays of two elements:
- Web App for web browsers: this is today still the most used application. Laptops, desktops, tablets and smartphones users use this type of application.
- Native App for tablets, smartphones, and wearables: only in a few cases you still need native apps for desktops and laptops as webapps are getting better every day for this use case. The most targeted platforms for smartphones, tablets and wearables today are Android and iOS.
Let's take a look at both elements in detail.
As mentioned above we don't need those portals, portlets, and gadgets anymore. Do we still in search for a component-based platform? Do we still need following requirements which were mostly answered by using portal, portlets and gadgets?
- Aggregate content and applications
- Integrate across applications
- Provide a unified user interface
- Support a unified web application development platform
- Personalize content and services
- Deploy a framework for publishing dynamic pages
The answer is yes but the main emphasis moves to different areas. The new trend in web app development is the so-called Progressive Web Apps (PWA). Today is more important to concentrate on the user experience instead of the web app itself. Following are the definition of Progressive Web Apps (taken from Google Developers Code Lab):
- Progressive - Works for every user, regardless of browser choice.
- Responsive - Fits any form factor: desktop, mobile, and tablet.
- Connectivityindependent - Enhanced with service workers to work offline or on low-quality networks.
- Native App-like - Feels like an app to the user with app-style interactions and navigation.
- Fresh - Always up-to-date thanks to the service worker update process.
- Safe - Served via HTTPS to prevent snooping and to ensure content hasn't been tampered with.
- Discoverable - Is identifiable as an "application" thanks to W3C manifest and service worker registration scope, allowing search engines to find it.
- Re-engageable - Makes re-engagement easy through features like push notifications.
- Installable - Allows users to "keep" apps they find most useful on their home screen without the hassle of an app store.
- Linkable - Easily share via URL, does not require complex installation.
So the main emphasis was moving from:
- Portals, portlets and gadgets which were defined to make the life of companies (which delivered the portals, portlets, gadgets) and developers (which write the portals, portlets, gadgets) easier to
- Progressive Web Apps which make users happy.
This does not mean that with a progressive web app we cannot deliver the requirements above. Let's take a look at all the requirement points in detail.
Aggregate Content and Applications and Integrate Across Applications
With Progressive Web Apps this looks different. You won't have such an integration using portlets. Instead, it will be an integration of many web apps using the same toolbar and each web app is working just like a standalone application. Here is a comparison.
Portal and Portlets Integration: Netvibes with Portal and Portlets
In a Portal and Portlet integration, each portlet can be maximized as a separate web app.
Progressive Web Apps Integration with Google Web Apps: Google+, Inbox, Search, etc.
In a Progressive Web Apps integration, each icon defines a web app and it will be opened separately as a standalone web app to follow the rule of Native App-like.
I was a happy user of iGoogle (OpenSocial Gadgets solution from Google), before Google turned it off. In the beginning, I thought that I need to search for an alternative just like Netvibes. In the end, I don't miss it at all. If I need to get the information I mostly need it in a full-screen mode. So in the end, I always need the web app in a whole and not only in a small portlet.
Provide a Unified User Interface
Both types can support a unified user interface. Progressive Web Apps use a common UI model, like Google Material Design or Bootstrap. Portal, Portlets, and Gadgets have mostly a mechanism to use the skins within the Portal Container.
Support a Unified Web Application Development Platform
Personalize Content and Services
This is where Portlet shows its strong character. You can turn off and on the portlets for your needs. If you see the Google toolbar above you can also personalize the content. So, in this case, the Progressive Web App can do the same thing with the individual design of its web app.
Deploy a Framework for Publishing Dynamic Pages
This is also possible with both types and the trend goes to Microservice.
As a summary, you can still fulfill the above requirements using Progressive Web Apps. Additionally, you can build component-based web apps by using the standard Web Components. Some real world use cases for Progressive Web Apps can be seen here:
A platform strategy without taking care of the most used clients (mobile phones and tablets) is simply a failure. Here are the types of the client devices today with their operating systems:
- Desktops and laptops with Windows, Linux, and MacOS: in most cases, you just need a web browser (Firefox, Internet Explorer, Edge, Chrome, or Safari) with the web apps. There is no need to build native apps for each operating systems, just go for Progressive Web Apps. Here are some facts:
- Google stops the development of Picasa client app and moves everything to the web with Google Photos.
- Integrated Development Environment (IDE) like Eclipse would be the one thing that should be natively implemented to run on clients on the top of the operating systems. But this model will also change in the future since Eclipse is beginning using web app as its future IDE: Eclipse Che - Cloud IDE.
- Tablets with Android and iOS: at the moment you need to build native apps for Android and iOS. But in many cases, the web apps with Progressive Web Apps could be the solution since web apps can do almost the same thing as the native apps, especially with the arrival of HTML5.
- Mobile phones with Android and iOS: as in the tablets area at the moment you need to build native apps for Android and iOS. Because of the screen size, it is likely that we need to develop the native apps. But the Progressive Web Apps are doing better every day (see the picture below and both examples above with Flipkart and Air Berlin).
- Wearables, gadgets, cars and TVwith Android Wear, Android Auto, Android TV, watchOS, Apple CarPlay and tvOS: this is the area where you have to write native apps since the smaller devices won't be able to run a web browser.
Progressive Web Apps with Material Design
Keep your eyes peeled for Part II, coming soon!