Klook.com
jasa pembuatan repository kampus

Can We Really Do Without Java?

Initially when computer resources were scarce it was advisable to work as close to machine level as possible. But as hardware resources became easily available and development time became crucial, higher level languages began to come into the picture. Development moved on from C to C++ and then Java and C#. Along with this trend the server programming got dominated by scripting languages like PHP, Python, Perl, and Ruby. Java and C# fall somewhere between so called “real programming languages” and “scripting languages”. C# can be termed more as Microsoft’s substitute for Java. So many facts that hold for Java also go well for C#.

Since Java came with a promise of platform independence, it quickly gained popularity. It is neither a scripting language nor a compiled language and returns byte code that can run on “Java Virtual Machine”. So JRE serves as an engine for Java just as other scripting languages require an engine for interpretation. Java definitely changed the way we looked at real programming languages. Java got faster every year and gave tough challenge to C++ in terms of performance. And the platform independence of byte code gave people the kind of freedom they have with scripting languages. Java was designed to be one solution for every platform i.e. desktops, browsers, servers and embedded systems.

But as with every good technology there were certainly some problems with Java too. Java failed to make its mark when it came to browsers. Though applets and java web start were designed to make it a good choice for deploying web applications but somehow it did not work too well. Applets soon became outdated technology. But misfortune of Java did not end with applets, it got carried forward and developers faced problems with GUI libraries of Java. No matter how hard Sun worked in making GUI toolkits for Java, developers never seem satisfied with any of them. Though, most of the components of Java Swing Toolkit worked perfectly fine still, building a beautiful front end interface remained somewhat distant dream for a Java developer.

The surge of internet brought with it a series of scripting languages for both server and client side. As the web applications started gaining popularity these scripting languages started dominating the programming world. Though server scripting offered flavors PHP, Python, Perl, ASP etc, client side remained predominantly dominated by JavaScript. Recently the popularity of AJAX has put JavaScript on forefront when it comes to developing web applications.

The web community has got so much driven by the potential of web applications that Flash, Action Script, HTML5, JavaScript, Silverlight, AJAX are the only technologies they think will survive on client side. All this because other technologies cannot deliver beautiful client side GUIs independent of operating system. So according to them only option left is creating all the feature rich beautiful interfaces within the browser and keep the entire processing and data on server side. The inclination of the entire world towards cloud computing just proves this mind set.

No doubt server side computation and data management (cloud computing) has tremendous benefits. But planning it as the ultimate solution for future of computing does not seem to be a prudent action. If we say cloud computing is next generation computing then we are directly saying that our computing process will be split into client and server side processes. And we are hoping everything to be more efficient i.e. sum of processing time of server and processing time of browser to be less than time of processing everything on client side. Now this assumption is logically incorrect.

Moreover, giving client side in hands of scripting languages we ensure that we will never be faster than the fastest client side scripting language. So, by doing this are we not going to throw away our years of performance optimization efforts done for languages such as Java into drain? Of course, Java can and will survive in many more forms, but by embedding nearly every application from text processing to gaming into browsers we will definitely be slowing down our computing experience. We would be at the mercy of our internet bandwidth, scripting languages and browser capabilities.

This trend can be justified if we really lack technology to make efficient and interactive client side applications. But hampering the flow of fast computing just because our language APIs and toolkits somewhat failed to develop platform independent feature rich GUIs, seems uncalled for. We want to develop browser as an engine for running all our applications. But unlike existing engines it will just make a GUI and perform basic computation for us and delegate remaining work to other server engines. It is unlike the true engine, JRE which alone is capable of doing every operation. Obviously, browser as an engine for running apps is favorable when application needs to handle data stored on servers or information is shared and modified by group of people like on social networking sites, forums etc. But embedding every other application into browser is like putting elephants into bird cages. Every application has its own requirements of hardware resources and computing power, which are required for a good user experience. And just because some people have access to huge bandwidth we cannot deprive others of the true computing experience.

Owing to ease of development, platform independence, large number of APIs and high performance Java still has potential of creating fancy desktop applications. It only needs continued attention of developers. Not just desktop applications it can be used to create fat client applications which perform most computation on client side and exchange data with server as per requirements like chat clients, multiplayer games etc.

%d bloggers like this: