Evolution of Web Development Technology - From Mocha to Low-Code to Codeless-as-a-Service
Introduction
Web development technology has come a long way through the history of the internet, from text only user interfaces in the 80s to blocky layouts of the 90s, to the web logs (a.k.a blogs) of the 2000s all the way to the mobile apps of the 2010s.
What started with Berner Lee’s first web page in 1991 in Hypertext Markup Language(HTML) exists as the “literal” backbone of every web page created even to this day. In general, these technologies accelerated the evolution of the industry since the needs of the market also rapidly changed to adapt to what was being offered by the prevailing technology. This whole evolution can be looked in terms for two distinct eras:
- Java-based Frameworks
- Low-Code & Codeless Frameworks
Java-based Frameworks
The 1990s witnessed the birth of two of the most consequential programming languages - Java and Javascript. Originally called ‘Mocha’ and then ‘Livescript’, Javascript was invented to allow Netscape developers to automate behavior, generating dynamic content without requiring the user to refresh/reload the page to pick up changes. While Javascript seemed more like a marketing ploy or a “glue” language for hobbyist programmers, Java was considered the sought after “component language” for the hardcore developers.
Java enjoyed all the stardom from the late 90s until 2006 with J2EE and its web frameworks,and Struts was the trendiest framework used in conjunction with Java. Javascript became a great companion to Java, with Java Server Pages (JSPs) and Servlets were run on a Java application server to extend the capabilities of the Web server. As a result, Javascript did not attain the status of a mainstream programming language.
Flex 1.0, JSF 1.0, and Spring 1.0 became the buzz words of the 2000s when they were all released within weeks of each other. The revival of Javascript occurred in the mid-2000s with jQuery, which enabled web pages to have browser agnostic behavior thereby relieving the web developer from the ensuing browser war. The popularity of browser agnostic features enabled the era of full fledged Javascript frameworks such as Ember.js, Backbone.js and AngularJS.
Numerous technologies and frameworks came along, each aiming to capture the web developer’s attention and become the choice of the fraternity. But the fact that all these came and most survived proved two important points
- The needs of every web application are different
- Technical knowledge and maturity of the application development team defines the technology being used.
Low-Code & Codeless Frameworks
Fast forward to today, both Java and Javascript have had a consequential impact on the Internet as we know it. While they may be considered as technologies of the 90s and 2000s, It’s impressive to notice that they achieved success beyond their original visions. While these web development frameworks are elegant and have proven to be robust, they come with a steep learning curve and an investment to build and maintain a technical team.
In this fast moving world of web technologies and their importance to all industries alike, speed and time to market have gained importance like never before. Low-Code and Codeless as a Service paradigms have tried to fill this specific need. Their claim to fame has been that they can facilitate businesses to quickly and easily build custom software solutions without investing the time and resources required to maintain a full stack development team. Instead, designers can use their visual interfaces, drag-and-drop features and pre-built templates to create unique business applications without depending heavily on software developers. The key selling point has been, visual interfaces make it easy to adapt to the changing needs of the business thereby making it more agile and eventually lowering the release cycle timeframes.
In general, Low-Code and Codeless frameworks have following advantages:
-
Agility and Flexibility : With their solid visual interfaces, business teams can be more involved in the development process shortening the feedback cycle. The development process becomes more responsive to the changing news of the business
-
Improved Security Posture : Many codeless providers include built-in security tools and integration with popular security tools and frameworks. They pretty much build guard rails for developers to work within, thereby reducing the risk of security breaches and ensuring compliance with the applicable industry regulation.
-
Efficiency and Cost Reduction : By utilizing internal business staff ( SMEs) as developers, businesses can reduce the higher costs of hiring and maintaining full strength development teams. Also using these frameworks, costs associated with maintaining/upgrading software development tools can be significantly reduced
-
Out of the box Templates & Integrations : With ready to use pre-built templates and integrations connecting to popular platforms such as CRMs, payment processors, Document Management tools, development speed of application specific use cases can be improved
-
Hosting and Deployment : Most Low-Code and Codeless providers support cloud hosting with the public cloud provider of choice, and the end-to-end DevOps process is reduced to a few clicks on their setup wizard. This eliminates all the hassles of developing and maintaining automation for application deployment and end-to-end lifecycle management (CI-CD)
Conclusion
While the adoption of Low-Code and Codeless frameworks has grown in the industry, the decision to take this route should be based on a few important considerations. In general, they are suited for low computation workflow applications or probably replacing ingenious SaaS applications. Low-Code and Codeless frameworks won’t lend themselves well for complex applications that require granular control and support complex external integrations that require special data and event processing.
Focus on Problems: Coding is straightforward but solving problems elegantly will turn out to be key differentiator for long term success. Whether a developer writes code or an SME uses the drag-and-drop feature in a Low-Code or Codeless platform, the underlying algorithm or logic usually determines the fate of the application. If the underlying logic is implemented incorrectly, the whole purpose of going the Low-Code or Codeless way could easily be defeated.
Dependency on Low-Code or Codeless platform: The choice of Low-Code or Codeless platform becomes consequential for the long term because. Even obscure limitations of the platform, for example, support on a “non EN-US browser” might prove to be a major showstopper for the application. It also applies to external or partner integrations. Many of these features will then have to be linked with the Codeless platform’s feature release timeline, which may or may not be acceptable to the businesses
Operating Costs and Usage Pattern
Most Low-Code and Codeless platforms offer competitive pricing, especially at lower tiers. While it looks promising until the MVP stage, operating costs may turn out to be significant with a growth in user base. It may be too late before this realization and in most cases all the effort and development on the platform of choice is non-portable (to a full stack framework or another Low-Code or Codeless platform). The business will have to either jump on the platform bandwagon and hitch their success to the feature and support roadmap of the platform (with their limitations) OR hold everything and reinvest time, effort and money to convert everything over to a custom coded solution. More mature the application, the harder and more expensive it is to migrate to a different technology. This has the potential of the Low-Code or Codeless provider holding your business hostage. So, being aware of the application usage pattern and future growth will be key to understand the long term operating costs better to make an informed decision.
Low-Code and Codeless-as-service platforms offer a promising alternative for low-medium complexity applications, but it is important to note that these platforms are still maturing. Features, functionality and supporting tool sets taken for granted in the full stack development world may not be readily available. As a result, a deliberate and thoughtful decision is warranted before jumping on to such platforms.
References
