Future Applications

The paragraphs below describes W3Schools' vision 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, 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 flexibe, generalized, and gracefully adjust to changes, without beeing crumbeled 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, ad 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 radable by humans.

Application decriptions 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 XML files) to describe applications.

Use text files (like XML 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.