Future Applications
The following introducesThe Example version ofAbout Future Web Applications.
Executable files will die, JavaScript will survive
Compiled executable files (such as those compiled from C or Java) cannot run on different hardware.
Executable files (EXE files, ActiveX and COM objects, DLL files) are components that prevent the development of applications running on the Internet.
Future applications will not be able to use, or rely on, components installed on client computers.
Our suggestion:
Use only HTML, CSS, and JavaScript to write your future applications.
Ensure that your future applications can run in any web browser.
Web applications will become Internet services
Applications in the past were large, purpose-built applications. Most of them will soon die because they cannot provide services as requirements change.
Applications should be flexible, general-purpose, and able to adapt well to changing requirements without breaking.
Applications should be able to scale to support millions of requests per day.
Applications should be able to be distributed and moved across multiple servers without breaking.
Applications should be able to work together with other applications.
Applications should not contain large amounts of code. Applications should be broken down into smaller services for easy creation and easy maintenance.
An application is a series of Internet services that return data to submitted Internet requests.
Applications should request services through standard Internet protocols without maintaining a permanent connection to the server.
Our suggestion:
Use the Internet based on SOA (Service Oriented Architecture) to write your future applications.
Make your application services more general, more flexible, and able to serve different types of requests.
Future applications will be easy to create and edit
The client and server sides will exchange data in an easy-to-understand way.
Applications will not be coded if it can be avoided.
Applications will be created and modified by editing models rather than editing code.
Application descriptions will be human-readable.
Application descriptions will be self-descriptive.
Applications will be written by users, not by programmers.
Our suggestion:
Use human-readable text files to describe services, and provide services by executing these descriptions.
Use text files (such as XML files) to describe applications.
Use text files (such as XML files) for data exchange.
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 website.
1. The first web developer used <AppML>.
2. The second web developer used his favorite server-side programming language.
3. The third used a professional enterprise web development framework.
The first web developer completed the demo in two days. In collaboration with users, an initial prototype was completed within a week. After two weeks of testing, an intelligent, fast, and easy-to-use website was ready to release.
Six months later, the second web developer had his website ready. But the WWW had changed requirements, so he was not satisfied with his website. This web developer could not make major changes to his project because it contained too much code. So he started developing version 2.
The third web developer never successfully finished his work. That professional web development framework was difficult to use, hard to understand, and almost impossible to test.
Take a look at how the first developer did it.。
Other Extensions