An interesting entry about teachers and their ignorance toward open source software has made me happy. Not the teachers, the fact that people are willing to voice the problems caused by proprietary software in the education system.
The entry states that Canada is making larger steps than the US to improve open source adoption in schools. Unfortunately, I highly doubt that is true.
I think there should be a huge sense of urgency here. Instead, it seems some of the teachers that aren't completely oblivious think "OK, there is Linux, but there is nothing I can do about it".
Perhaps teachers should encourage students to use Linux and other open source projects outside of the classroom. Rather than merely "allowing" it. Let the students insist on bringing open source into the education. I would think this would be a much easier task with student support.
Showing posts with label iesucks. Show all posts
Showing posts with label iesucks. Show all posts
Thursday, January 29, 2009
Tuesday, January 27, 2009
Friday, January 2, 2009
Is javascript ready for the desktop?
The web browser has come a long way since its' inception. The first basic requirements of the web browser were to retrieve and format hypertext. Now, you can pragmatically display content within the browser using javascript. Firefox offers another level of programmatic customization using XUL.
This is nothing new. The web browser and javascript have both been around for some time now. Also not new is the fact that the web browser runs on the desktop. So the question is javascript ready for the desktop seems a little obvious at first glance or perhaps even just plain wrong. Another form of the question might be can javascript applications replace the majority of existing desktop applications. To most developers, or desktop users for that matter, this question of javascript desktop readiness simply leads to endless other questions.
The most important of course being why bother. If we already have all these applications that run perfectly well (and fast) on the desktop, why replace them? I would argue that as of right now, there probably is no reason to replace desktop applications. However, I would also argue that the possibility and feasibility of replacing certain desktop applications is certainly worth thinking about.
The speed argument may be a show-stopper in many cases. Especially when the latency involved arises as a result of loading the code that is the application. If a javascript application is running on the desktop, the javascript code already exists on the desktop and therefore the latency involved in delivering the application is removed. What about the data involved in application? If the data is remote, the same latency is going to be involved regardless of the client using the data. In fact, the tricky part is when the data resides on the same desktop as the javascript application.
Trying to perform read and write operations on the desktop hard drive using javascript is hopeless. So how do we make the hard drive operations available within javascript? My solution would be to create a simple HTTP data server that runs on the desktop. This server would provide only what is required to manipulate the hard drive. The server would not host the application code or any static files for that matter. It is not needed since all the application resources are local. The only need for the server would be raw data access.
Here, a simple node depicting the desktop computer contains the server component and the browser component.
Now suppose this worked (I have not actually tried it), that would mean it is possible to write javascript applications for the desktop. What now? We need some rationale for doing so. On the development end, productivity levels increase when building GUIs using a combination of javascript+HTML+CSS. In my opinion, as a developer (I'm by no means a GUI designer), I find writng javascript much simpler then trying to use a traditional GUI kit such as Qt. Especially given that talented CSS designer can create exceptionally beautiful work using only CSS.
The work is also simplified with javascript toolkits such as dojo. The dojo toolkit provides a multitude of GUI widgets that are already themed quite nicely. I also find interesting the fact that these toolkits have come into existence. It goes to show that there is a real desire to use the web browser as a platform.
Where to start? What would be the first desktop application to re-write in javascript? How about a file browser? It should be a fairly simple application to write and would serve as a useful proof of concept. Text editor? There are some reasonably powerful editor widgets which provide half the implementation.
So, as a quick summation, there is no real pressing reason to develop desktop applications using javascript. However, for the future, it may be worth exploring now. Especially considering the recent major speed enhancements made to the Firefox web browser. Opera is another quality in which to use this future platform. Although IE sucks, its' market share is currently a reality.
This is nothing new. The web browser and javascript have both been around for some time now. Also not new is the fact that the web browser runs on the desktop. So the question is javascript ready for the desktop seems a little obvious at first glance or perhaps even just plain wrong. Another form of the question might be can javascript applications replace the majority of existing desktop applications. To most developers, or desktop users for that matter, this question of javascript desktop readiness simply leads to endless other questions.
The most important of course being why bother. If we already have all these applications that run perfectly well (and fast) on the desktop, why replace them? I would argue that as of right now, there probably is no reason to replace desktop applications. However, I would also argue that the possibility and feasibility of replacing certain desktop applications is certainly worth thinking about.
The speed argument may be a show-stopper in many cases. Especially when the latency involved arises as a result of loading the code that is the application. If a javascript application is running on the desktop, the javascript code already exists on the desktop and therefore the latency involved in delivering the application is removed. What about the data involved in application? If the data is remote, the same latency is going to be involved regardless of the client using the data. In fact, the tricky part is when the data resides on the same desktop as the javascript application.
Trying to perform read and write operations on the desktop hard drive using javascript is hopeless. So how do we make the hard drive operations available within javascript? My solution would be to create a simple HTTP data server that runs on the desktop. This server would provide only what is required to manipulate the hard drive. The server would not host the application code or any static files for that matter. It is not needed since all the application resources are local. The only need for the server would be raw data access.
Here, a simple node depicting the desktop computer contains the server component and the browser component.
Now suppose this worked (I have not actually tried it), that would mean it is possible to write javascript applications for the desktop. What now? We need some rationale for doing so. On the development end, productivity levels increase when building GUIs using a combination of javascript+HTML+CSS. In my opinion, as a developer (I'm by no means a GUI designer), I find writng javascript much simpler then trying to use a traditional GUI kit such as Qt. Especially given that talented CSS designer can create exceptionally beautiful work using only CSS.
The work is also simplified with javascript toolkits such as dojo. The dojo toolkit provides a multitude of GUI widgets that are already themed quite nicely. I also find interesting the fact that these toolkits have come into existence. It goes to show that there is a real desire to use the web browser as a platform.
Where to start? What would be the first desktop application to re-write in javascript? How about a file browser? It should be a fairly simple application to write and would serve as a useful proof of concept. Text editor? There are some reasonably powerful editor widgets which provide half the implementation.
So, as a quick summation, there is no real pressing reason to develop desktop applications using javascript. However, for the future, it may be worth exploring now. Especially considering the recent major speed enhancements made to the Firefox web browser. Opera is another quality in which to use this future platform. Although IE sucks, its' market share is currently a reality.
Subscribe to:
Posts
(
Atom
)