Framework itself consist of two layers:
- UI Library - is made on top of the Core and based on Bootstrap 5.2.0+ CSS.
Currently, the library itself is in maturation stage. What that actually mean?
The best way to find out how a library is stable, what is missing, or what we did wrong is simply to develop a few web apps which will reveal potential issues, or framework design failures.
Currently, we are in the stage of developing such web apps based on our GS WebComponents. Our first app - browser extension for Green Screens Web 5250 IBM i server is already in production, published on Google Store and MS Web Store.
Application itself is rather simple, but helped us to discover some issues fixed in the meanwhile. Either way, that was our goal at the end.
The next web app we are working on right now is full migration of our web based administration console for our main product - Green Screens Server Web 5250 for IBM i. Our plan is to finish it by the end of the 2022. So, we hope that the new version will be ready before the next 2022.Q4 product release.
Over the time as we were developing WebComponents, quite a new technology with many new concepts, we learned a lot in the process, and now we feel quite confident in developing apps with that new acquired knowledge.
Even, only 3 months are left to the end of the year and our next 2022.Q4 release, the sheer speed of development with WebComponents compared to the previous web technologies development principles, we are quite convinced that new Web Admin console will be ready before next release by the end of December.
In 2017, we developed Web 5250 Terminal UI modernization engine. That first version was quite basic. However, we learned a lot in the meanwhile.
In 2018/2019, we upgraded UI library. Also, we improved our engine with new features. On the Green Screens Server side, we already have a possibility to parse binary compiled display DDS files. No need for DDS source. Also, we have a feature that can detect DDS file used by the current terminal user/session.
Those two features allows us two important steps:
- Dynamically generate XML document based on currently used DDS file and its DDS records on the fly.
- Send generated XML to the user. As HTML is a "loose" XML, generated XML is actually a set of HTML tags, which can be custom HTML elements. The same ones we are using in our GS WebComponents.
So, the final result should be self rendering web UI based on mentioned technologies.
There are various problems for automatic screen modernization, mostly related to automatic screen data layouting which is fundamentally different from classical 5250 terminal screens. Many companies tried, and failed.
We do not fool ourselves, there is no 100% automatic screen modernization, respecting modern Web Principles. So, our goal is to provide an easy-to-use ecosystem which will allow developers to modernize their 5250 terminal screens in modern, easy and fast ways using pure web technology.
On top of that, the whole library and ecosystem will be open-sourced and will operate as an extra module within our Green Screens for IBM terminal server. This will give companies a lot of freedom to modify, adjust or completely change UI library to their own needs.
Why did we choose WebComponents after all?
Before WebComponents, there were and still are a lot of libraries and frameworks. Each of them has their own development principles. Over the years, many principles from all those different frameworks turns out to be high potential for getting into a Web Standardization through W3C.
Result of all those web development concepts now can be seen inside WebComponents and accompanying new browsers features, which will push out all other 3rd party libraries out of the main development scope.
WebComponents, compared to many development libraries, are W3C and browsers official standard that will not go anywhere in the near future. Something we simply can't count on for 3rd party frameworks.
Principles in WebComponents are actually making build and packaging tools obsolete. Server side UI rendering or compilation/transpilation obsolete. Dependency on 3rd party libraries obsolete. We can go with the "obsolete" word on and on...
We proved to ourselves that the WebComponents are technology to count on in the long-term. By our experience so far, development time reduction is ~20x, source code reduction is ~10x reducing not only cost and time of development, it reduces programming mistakes which has a direct effect on cost reduction.
Why did we choose Bootstrap for our WebComponents?
There are several CSS libraries out there with similar principles as Bootstrap. After reviewing them, we came up to a conclusion that Bootstrap is the best choice.
Even, some feature existed only in Bootstrap during our evaluation stage; such as CSS Variables; that does not mean other CSS lib's won’t have them in near future. Of course, that was not the only reason.
Advantages over other frameworks made us choose Bootstrap are:
- Open-source under MIT license
- Large amount of available themes
- Large user base
- Wide-spread usage
- CSS Variables
- Own icon set - no 3rd party dependency
- Familiarity with framework by us and many developers
Year 2023. for our WebComponents and Green Screens Server will be very important as we will not only switch UI interface to a new more modern technology, we will also upgrade our 5250 Web Terminal.
As old MS Internet Explorer and Edge (non WebKit based version) is out of technical support by the Microsoft, we will eventually remove support for them. Upgrading to the modern web technologies will break that support for old browsers. We are slowly changing and upgrading module by module over the coming months and the whole next year to make this transition invisible to the end user.
For now, stay tuned, and keep following our news feed for more blogs about GS WebComponents and other features coming in the following weeks and months.