PoNG: 10 Reasons to Rethink the Web

Classic portal servers or web application servers create HTML server side. I strongly belive, this is not an up to date architecture. I propose a portal web app. But PoNG is even more: a meta portal web app. Meta means, that it is no specific web app. It is more a framework, which enables you to create any web app you need.

Meta web app sounds complicating. But if you don't need to write HTML code server side, things get easy. Of course you still may need central data stores and logic in the backend, where "application servers" are built for. The AS will also thank you for getting rid of all the HTML stuff. Don't understand me wrong: HTML is perfect to do its job in the browser and the best thing we have in the net, but don't create HTML server side, only to wrap information.

My top reasons to have a portal web app like PoNG:

Scaling of Dynamic Web Sites

What do you think scales better:

1. Classic Web Application Server or Web Portal Server:
   • Server: Load Data
   • Server: Crunch to HTML
   • Net: Deliver HTML
   • Client: Render HTML to Page
2. Portal web app:
   • Server: Load Data
   • Net: Deliver Data
   • Client: Crunch HTML
   • Client: Render HTML to Page

What are the facts:

• If it is a really dynamic scenario, the server has to render the page for each client individually -- for each request.
• Clients have more computing Power than the server, all clients in summary factors better
• The net traffic round about 1000 times higher in the classic case, since HTML is so huge, compared with the raw data

No reason create dynamic HTML server side

Don't forget, where the WWW comes from: Serving static information into the net. That's why the first page called index. HTML and browsers are so good, that this was used to serve dynamic content. There was no way to do have any dynamic things on the client, because there was no scripting and also CSS was very limited.

Today, there are no restrictions to serve content and let the browser do the rest of the job.

Flexible use cases, like RSS

RSS is so powerful, but there is only limited use of RSS. I like the concept -- but why don't we use it? I think the reason is: RSS is exotic, because the rest of the web works the other way round. Result: It is hard to embed non HTML information in a server generated page, where the web programmers didn't think about including RSS.

The good thing about RSS: It shows the flexibility of structured (but raw, i.e. non HTML) information. RSS can be used in the bookmarks bar, you can integrate it as content in your page, you can get smart phone apps to read RSS, you can read feeds like a web page, you can filter them, you can merge several RSS feeds, ...

Client Computing Power

The times of limited client computing powers are over. Today every new mobile phone or table has so many more computing power than the first WWW server, a NEXT.

Architecture in Sync With Smartphone Apps

Do it like good smart phone apps: Don't get HTML from the backend, request JSON unsing the REST pattern. Then present the information in an appropriate rendering and offer it ergonomically to the user.

Portal Projects

I've seen and done a lot of web application programming projects. We have JPA and a lot of good frameworks, but crunching good HTML is still a lot of programing work.

MVC Life Cycle

Do you know how Inter Portlet communication work the JEE way, or MVC is done in JSF? Forget it. Everything is so easy, if the state is maintained only on the client. No sessions, no synching of states in a server cluster, no MVC patterns beween client and server. In the past, you had to use e.g. stateful session beans or session variables of a PHP script. Think stateless!! And please persist information, which are important to remember asynchronous e.g. shopping baskets. This leads to web applications with a good architecture, web applications with a good performance and results in a good user experience.

Barrier Free Web

HTML prevents barrier freeness, because it is a mix of information, content, layout and design.

If you have the layout separated, it should be easier to support special clients, e.g. for blind people.

But barrier free also means, that you don't exclude devices. If you don't have a one fits all HTML, you can also support devices with a small display, no display, limited bandwith or limited computing resources.

Device Independence

If the client decides, how to present the user the information, everything is possible. The support of multi display clients (e.g. car cockpits) or no display clients (voice controlled) or devices with small displays or workstations with multiple huge monitors are no problem.

JEE Portal lite -- don't do it this way

No joke: Some customer, some project. I was defined to use a standard JEE Portal server. So we purchased licenses, to build up a cluster -- expensive -- with the value of a new SUV.

Then we stripped away all the good built in features -- WIKI, Chat, User Management ... -- security issues. Also user self service was disabled, and also customizing by the user.

Finally we got the deployment -- and it was an "iFrame Portlet". All the rendering was done on the tomcat in the backend tier behind.

There are so many better way to waste money?