AppML History

In 1999 Refsnes Data developed the first version of AppML.

Already then,  AppML was based on HTTP request communication between web client and the web server. Later this method became well known as AJAX.

In September 2000, a development project for a large Norwegian customer was started. The goal of the project was to convert a huge information system (about 300 applications) from a Windows desktop application to a modern Internet application, using only AppML.

The AppML-based system was launched in 2001, several months before schedule, as the world's first commercial AJAX application. The project was a huge success, with development time reduced by 75% compared to ordinary web development. Since then, new applications have been added, and the system now covers over 1000 running applications.

In February 2015, W3Schools re-launched AppML as a new product, open to the public.

AppML design goals:

• AppML applications must run over the Internet
• AppML applications must be platform independent
• AppML applications must use Internet standards only (HTML, CSS, JavaScript)
• AppML applications must support a variety of application needs
• AppML applications must be self-describing
• AppML applications must be easy to develop, maintain and change
• AppML applications must be future proof

The paragraphs below describes Refsnes Data's original visions (1999) about future web applications.

Executables Will Die, JavaScript Will Live

Compiled executables (compiled from languages like C or Java) cannot run on different hardware.

Executables (EXE files, ActiveX and COM objects, DLL-files) are components that prevent the development of applications that can run over the internet.

Future application will not use, or rely on, executables or any other components installed on the client's computer.

Our suggestions:

Write your future applications using only HTML, CSS and JavaScript.

Make sure your future applications run in any web browser.

Web Applications Will be Internet Services

The history is full of large, purpose built, applications. Many of these died very quickly, because they could not survive requirements changes.

Applications should be flexible, generalized, and gracefully adjust to changes, without being crumbled or destroyed.

Applications should be able to scale from supporting a few to millions of requests per day.

Applications should be able to spread from one server to many, or to move between servers, without breaking the application.

Applications should be able to cooperate with other applications.

Applications should not contain large masses of code.

Applications should be broken down into smaller services, that are easy to create and easy to maintain.

Applications should be a set of Internet services that can return data to submitted Internet requests.

Applications should request services via standard Internet protocols without maintaining a permanent connection to the server. 

Our suggestions:

Write your future applications using Internet based SOA (Service Oriented Architecture).

Make your application services general and flexible, and ready to serve different types of requests.

Future Applications Will be Easy to Create and Edit

Clients and servers will exchange data in an easy understandable way.

Applications will not be coded, if it can be avoided.

Applications will be created and modified, by editing models, not by editing code.

Application descriptions will be readable by humans.

Application descriptions will be self describing.

Applications will be written by users, not programmers.

Our suggestions:

Use human readable text files to describe services, and provide services by executing these descriptions.

Use text files (like JSON files) to describe applications.

Use text files (like JSON files) to exchange data.

Use HTML, CSS, and JavaScript to execute applications.

Three Little Web Developers...

Once upon a time there were three little web developers developing a new web site.

1. The first web developer was using AppML.

2. The second web developer was using his favorite server programming language.

3. The third was using a professional enterprise web development framework.

The first web developer had a demo up and running in two days. After collaboration with the users, an exiting prototype was ready in a week. And after two weeks of testing, an intelligent, fast and easy to use, web site, was ready to publish.

The second web developer had his web site ready after 6 months. But the WWW had changed its requirements, and was not satisfied. The web developer could not make major changes to his project because it contained too much code. So he started the development of version 2.

The third web developer never managed to complete his work. The professional web development framework was very difficult to use, very hard to understand, and almost impossible to test.

Take a look at how the first developer did it.