Tag Archives: DOM

Augo27

Christian Decker

0

Framework Disagreement: JQuery: (Mis)leading the Pack

ustin Palmer has taken issue to some of the statements made by jQuery and writes JQuery: (Mis)leading the Pack as a retort of sorts to “Why JQuery’s Philosophy is Better”.

He makes some good points about:

  • DOM Insertion
  • Chainability
  • CSS Selectors/Xpath
  • Plugin Development
  • Automatic Looping
  • Ajax Updating
  • Adding a class to an element
  • Adding a class to a group of elements

A pretty honest and inclusive set of comments (not a “they suck, we rule” type post).



Technorati Tags: , , ,
Did you like this? Share it:

Augo23

Christian Decker

0

qooxdoo 0.6 RC1 released

While reading the Ajaxian newsfeed I found a really nice screenshot about Qooxdoo 0.6 RC1 and I was impressed. Trying out the demos I decided that soon I would have to take a better look at this cute little library (or is it little at all?



Just take a look at it for yourself. It’s one of the nicest DOM-Manipulation libraries I’ve seen yet. If you need a full Windowing system it’s totally what you need :-)
Technorati Tags: , ,
Did you like this? Share it:

Juno20

Christian Decker

0

The JavaScript World Cup

One of the most common question on newsgroups and forums is “What Ajax framework should I use?” and SitePoint has a nice abstract look at the four most common Frameworks:
Over the past year or so, as DOM Scripting has exploded in the mainstream coding arena on the back of AJAX, a seemingly endless number of JavaScript libraries have joined the list of contenders. Fortunately for our poor brains, there are four libraries that have emerged as the clear forerunners in terms of their levels of adoption, documentation and community support:
  • Dojo, a powerful library developed primarily off the back of JotSpot
  • Prototype, the backbone of Ruby on Rails excellent AJAX support
  • Mochikit, the Python library that makes JavaScript suck less
  • Yahoo UI Library (often shortened to just YUI), the new kid on the block
Of these four, there is no clear front-runner yet. Each library differs enormously from the others not only in features, but in less tangible aspects like ease-of-use, community support and philosophy. One of the most important factors in choosing a development platform is how well its philosophy fits with the way that your brain works. In this article, I’ll examine each library to help you decide which one best suits your development style and project needs. While it would be impossible to cover every aspect of each library, I’ve done my best to cover the highlights of each of them, as well as give some insight into how they handle the bread-and-butter tasks of DOM manipulation, event handling and AJAX.
Technorati Tags: , , , ,
Did you like this? Share it:

Maro30

Christian Decker

0

Why Ajax is conceptually better

Ajax has been around for quite some time now (it is a bit more than a year ago that Jesse James Garret coined the term) and it has quite some lovers, and just as many haters. First of all let’s distinguish between two different things that are often confused when we talk about Ajax. What many think to be Ajax are relly two independant things:
  • Asynchronous Communication: allows fetching and sending data asynchronously, in the background.
  • DOM-Manipulation: which allows all those fancy flash-like effects on webpages, such as zooming images, floating windows, but also really basic stuff, like swapping text in boxes.
If we want to split hairs there is a third thing that makes up those Web 2.0 applications: a logic layer, which takes care of the execution of the applicationMany of the haters argue that by using these techniques the programmers make nice applications but make things more difficult, adding complexity to the client, which before Web 2.0 was a viewer, creating portability issues and last but not least excluding all those visitors that do not use a supported browser. But let’s go a bit deeper into the things involved, when building a web service. First of all we’re able to identify three different parts:
  1. The Server side application: this may be as complex as you want but for our purpose we’ll just assume that it gets some input from the user, processes it, updates its internal state and returns some data to the user.
  2. The data: the input and output data of our service.
  3. The User Interface: this is where the user gets to see the data in all its beauty (or uglyness as it often happens).
Now in the “old” way of doing things, let’s just call it Web1, parts 2 and 3 where clustered together. With the current development in the Web 2.0 we tend to divide the layers 2 and 3 again by completely dividing the layout from the data. The idea is to download a relatively small engine that takes care of what happens on the page, and fetches asynchronously the data it needs from the server, often using data encapsulation methods such as JSON or XML. This is actually one step forward, but in the meantime a return to the roots of the Web: we now serve “pure data” or content, without all the formatting clutter that scrambled our data back in Web 1. The reduction of redundancy is a nice side effect, not having to download the layout on every refresh. The fact that we serve pure data using standard formats and standard protocols allows us to create non-human interaction between a web service and a client, the data is available for further elaboration and is independant of its actual representation in the User Interface. And here we are, welcome to the Semantic Web.
Humans are capable of using the Web to, say, find the Swedish word for “car”, renew a library book, or find the cheapest DVD and buy it. But if you asked a computer to do the same thing, it wouldn’t know where to start. That is because web pages are designed to be read by people, not machines. The Semantic Web is a project aimed to make web pages understandable by computers, so that they can search websites and perform actions in a standardized way. The potential benefits are that computers can harness the enormous network of information and services on the Web. Your computer could, for example, automatically find the nearest manicurist to where you live and book an appointment for you that fits in with your schedule. A lot of the things that could be done with the Semantic Web could also be done without it, and indeed already are done in some cases. But the Semantic Web provides a standard which makes such services far easier to implement. [From Wikipedia]
The potential of the Semantic Web is just unimaginably huge, to say it with The Hitchhikers Guide to the Galaxy’s words: it’s big. You just won’t believe how vastly hugely mindboggingly big it is. And there are already some examples: Remarkably we can find almost every big player of the Web 2.0 movement in the list, because it many services already rely for their internal workings on XML or JSON, so it becomes really easy to access them, even without the original “Web Frontend”.
Did you like this? Share it:

Maro15

Christian Decker

2

Aine: AJAX is not everything…

While I am a supporter of the technologies for which the abbreviation AJAX stands, I’m also convinced that AJAX is not the solution to everything. Right now every tutorial, library or comment that is even remotely AJAX-Related is getting a huge amount of attention, just because we’re in the middle of an AJAX-Hype. Yes, it is in fact a hype, because people hear of it and run to the next book store and buy a book without having the remotest idea on what AJAX is good for (the book buying people are the ones I prefer over those Newsgroup posters that post hundreds of posts like “I’m new to AJAX”, “What is AJAX good for”, …).
AJAX is a technology like thousands of others, no more no less, with all its strengths and weaknesses.

I came across a post in the JavaLobby Forum:
After attending an interesting AJAX seminar in NYC I did not change my mind. Initially, I was prepared to ask specific technical questions about AJAX problems, but even without my tricky questions every presenter was talking about lots and lots of issues they were facing while developing AJAX applications. This was the most honest team of presenters I’ve seen so far (btw, the team has included Jesse James Garrett, who named a set of existing technologies AJAX).

After hearing all their testimonies about the plethora of AJAX issues, during the evening I decided to ask a generic question, if the panelists believed that AJAX would be around in three years. Most of them answered that it’ll be around in three, but they were not sure about 5 or 7 years from now. Fair enough. I had an impression that all of them enjoyed the technology, understood the issues, and were willing to try to solve them… somehow.

So far I coded both AJAX applications and Java applications, and both have advantages, but let’s focus on AJAX:

Strengths

  • Easy to deliver: (nearly) every browser nowadays supports JavaScript, thus an application written in JavaScript, on top of other standards, like DOM, will probably run on most Browsers.
  • Complex is easy: AJAX is pushing the development of applications in a direction where complex workflows are wrapped in a really easy to use presentation, hiding complexity and making important things visible.
  • Software as service: for long time software was a piece of code that you bought, now it’s a service that you subscribe to. Where’s the difference? Its easy, with AJAX the code is no longer kept secret (can I hear some OpenSource Developers cheering? =D) and businesses are shifting from selling the code to offering a service. 37signals is probably the best known and most successfull company that uses this model.
  • Everybody can use it: the steps are easy open your browser (remember not to click on the blue ‘e’) and point it to a URL, that’s it. From there you are driven through the rest of the application, with nice popups, overlays explaining what you have to do, and telling you where to fill in what. It feels smooth.

Weaknesses

  • Hard to code: because JavaScript support in the browsers is not standard compliant, and every browser adds its own “enhancements” the developers have to work around to those heterogenic environments and add abstraction layers in between, slowing down the application.
  • The URL-Paradigm is lost: URL stands for Uniform Resource Locator and it basically used to locate resources, such as Documents, Audio files, Images, and alike. With AJAX this is lost because what good is it to locate the resource if what it looks like solely depends on the means to access it? AJAX applications look different and react different in each browser. Many developers now complain that AJAX takes away the bookmarkability, in my opinion this is good! A URL may solely be used to locate the application, and not the states in which the Application currently is. It’s not good to bookmark states of of an application.
  • It’s slow: yep, JavaScript, being a purely interpreted language, is really slow, no way to argue about this.
  • It’s easy to make errors: JavaScript applications may grow really complex and we don’t have necessary tools to debug and test the applications, furthermore in one environment (browser) an error might occur at a certain point while in another it runs smoothly. The testing and debugging efforts grows exponentially with the amount of code and the complexity of the application, while this is true for all languages and applications, in AJAX this is particularly dangerous, because we can’t automate these things, and tools are scarse. This might still improve over time, we’ll see.
  • Code is readable: I’m not a big supporter of the security by obfuscation method, which is secure as long as an attacker cannot access the code of the application, but being able to read the applications gives an attacker better tools to attack the application. This is also the main reason you won’t see big applications from non-OpenSource teams: no one wants the others to see your code if your going to sell it…

AJAX is surely a step into the right directions, but one must ask himself if AJAX is the way to go further on. While AJAX does very well for small applications it is not usable for larger applications. Applications such as Writely are on the very limit of the AJAX Universe, to go beyond this we have to rely on other technologies.
One that comes in mind is Java, it is nearly as widespread as JavaScript is and programmers can rely on extensive library support. Java is currently seen a bit as an overkill, slow and useless among many users, but it is a powerfull tool to create thin client applications, that is to say that you load the application from remote without having to install a program locally, and just run it off the network.
Thin clients are a new approach, first embraced by Sun Microsystems, that tends to minimize the administration effort, and maximize the user experience, almost exactly what AJAX stands for right now, don’t you think?
Nearly as distributable as AJAX, Java has several advantages, being easily portable, offering modern GUIs and being faster than JavaScript, it may become the successor of the AJAX hype.
Using Java we can easily create complex software that it intuitive to use (as the Web 2.0 phenomenon is experimenting about right now) that scale well, both while developing and once deployed, and gives the developers the power of thousands of ready to use Libraries.

AJAX is here, now, but how long will it stay?
Did you like this? Share it:

  Recent Entries »