Clearly it's highly biased because it's not a newspaper article, it's a post on what I think.

> People wouldn't query the DOM if that wasn't the most effective way of getting stuff done. jQuery has a UI kit, it's called jQuery UI. And how is using jQuery equals to not using JavaScript to the fullest?

Have you ever used Gmail? Or MobileMe? Or any of the world class web applications built without jQuery? At no point did I say jQuery was invalid, and jQuery UI is a prime example of where I want the web to go. With it, you use jQuery to find the elements you want to work with, and then you use and object based hierarchal to enhance them and work entirely in Javascript, above the DOM. See http://jqueryui.com/demos/slider/#slider-vertical, a prime example. The code selects the slider, and then uses $.slider to perform all the meat of the problem. Selecting the element is a mere convenience, the cool stuff is done by the UI kit.

> The author said "using JavaScript to the fullest" and now the author tells us to create "extendable view classes" in JavaScript. JavaScript is a prototypical language, you can't use it to the "fullest" if you force OOP on it.

Use whatever programming paradigm you like. HN wouldn't accept a comment listing all the successful JS frameworks that use class based inheritance because it would be too long.

> If desktop apps are so good, then how come web apps are still around?

Your understanding of web development may be amiss, how the tables have turned! Web apps are around because of the delivery mechanism: the web. Not because they offer astounding experiences compared to a hypothetical desktop counterpart, but because cloud storage and scaling, always on availability, and browser ubiquity can be leveraged by users for great gains. Web application developers constantly struggle to provide the "native" experience while leveraging all the benefits of the web, but its hard, hence the post.

I do however understand your desire to keep using jQuery. As mentioned below, its an extraordinary tool that it seems you and I both use religiously. However, I have found that its hard to scale up a large complex client side app using only jQuery, and I and seemingly many other feel the need for more structured frameworks to leverage in that domain. Do you disagree?

edited to remove unwarranted hate

> HN wouldn't accept a comment listing all the successful JS frameworks that use class based inheritance because it would be too long.

That certainly doesn't mean that class-based ones are the most successful.

> Your understanding of web development may be amiss, how the tables have turned! Web apps are around because of the delivery mechanism: the web. Not because they offer astounding experiences compared to a hypothetical desktop counterpart, but because cloud storage and scaling, always on availability, and browser ubiquity can be leveraged by users for great gains. Web application developers constantly struggle to provide the "native" experience while leveraging all the benefits of the web, but its hard, hence the post.

The browser would be long dead if it wasn't for JavaScript.

> an extraordinary tool

Agreed.

> you and I both use religiously

There is no religion on my part, it simply gets the job done, and allows me to focus on architecting my application instead of DOM bugs.

> However, I have found that its hard to scale up a large complex client side app using only jQuery, and I and seemingly many other feel the need for more structured frameworks to leverage in that domain. Do you disagree?

This is not a yes or no question, it depends on what's the problem, as I said in another comment, it's really easy to fix your dual validation problem, by writing a small micro framework, if there isn't one out there yet. It has become really easy to bridge the server and the client. You could abstract away any problem, but you shouldn't get too carried away with hierarchies, JavaScript is a semi-interpreted language and as I said, it's more function and prototypical than object(class) oriented .I agree that web development is hard, but as I said earlier, it's hard because of archaic browsers.

> People wouldn't query the DOM if that wasn't the most effective way of getting stuff done. jQuery has a UI kit, it's called jQuery UI. And how is using jQuery equals to not using JavaScript to the fullest?

All UI toolkits leverage the DOM, that's not the point. The point is whether the DOM is at the appropriate level of abstraction for writing business app UI logic. I wrote at the level of the DOM for years, and when I switched to ExtJS it felt like a liberation. I spend way more time on business logic and experimenting with different UI designs, and far less time fighting with browsers.

> JavaScript is a prototypical language, you can't use it to the "fullest" if you force OOP on it.

OOP and prototypal inheritance don't conflict. You don't have to use classical inheritance to have a clean OO design.

I think there are only a handful of people in the world who truly understand what building something on the level of complexity of a 280 Slides or GMail in jQuery really is. And I think even those people would agree that they'd be better off with a more structured framework, even if that was something built on top of / in conjunction with jQuery. In some ways I think that's where Backbone is trying to fit itself into the ecosystem. I think one of the fundamental realizations of building something complex that's fast and maintainable is that using the DOM as your source of application state is usually not the right way to do it.

The way I see it, there's a big difference between making fancy websites and making fancy web applications. Making a fancy website, presenting information to a user and maybe collecting a bit of data along the way, you're unlikely to collide with the frustrations outlined in the article. jQuery is more than adequate for the majority of things.

Making a desktop-style web application, however (such as his examples), is a whole different kettle of fish. Once you're dealing with state that exists outside of the DOM, you're going to be struggling to keep up without some variety of model/view concept to rely on.

They're really two separate domains. One was born in the world of desktop applications, the other was born in static HTML.

If you have a huge dataset with complex validation rules, implement a server side validation engine, and do the same in client side and expose the rules to both parties, it's not hard at all.

jQuery is not only about the DOM, it's a tool, it doesn't force you to write code like this:

$('#foo').hide();$("#foo").css('color':'white');

You can write very clean structured code in JavaScript using jQuery.

* It must be real hard to call your JSON encode function on your data set, that would make it 1 line longer. :) *

Unless you don't want to always transfer the entire dataset between the client and server every time.

That problem could occur in other scenarios, and not particularly tied to web development.

That doesn't mean it's not a problem worth trying to solve...

I agree with a lot of your points, except where it comes to JSON encoding. In many of my apps I use an ORM, NHibernate to be specific. I've found that this makes a lot of operations on the server side much simpler as there is less code for me to write and debug.

The problem comes though when I'm ready to encode to JSON to send to the client. Your correct that it is just one additional line to encode to JSON, but NHibernate creates objects that have relationships to other objects, and serializing those relationships can be very tricky. I have not found a great way to do this and often end up writing simplified versions of the server side classes and code to map from a server side class to a client side class.

Now you could argue that my framework or language sucks, but I think this goes to the point of the article. I feel the code I am writing on the server side is pretty solid and I am happy with my productivity. But as soon as I introduce any complex behavior on the client side, I end up with a lot of duplication and the entire code base gets much harder to manage.

I feel your pain, but it's not a new problem.. I spent years building server side apps with Hibernate, and before there was JSON, there was XML, or transfer-objects, or even hibernate entities that were disconnected from the backend (and would throw arbitrary exceptions when calling across un-fetched relationships). There's always a need to sort out how to represent these models across tiers.. In general, I favor only serializing relationships to things that are completely dependent (ie: dependent children who's lifecycles are married to the parent).. I try to never serialize relationships to independent entities.. let those get fetched by id if the client needs them.

I'm sorry to hear that, in most places it's just one line. Let's hope the Hibernate people fix this.

You might need to enlighten yourself on exactly which browser first brought us ajax. And are you too young to remember just how bad Netscape Navigator was?

IE was brilliant when it came out. It was MS's strategy of making it free to kill off Netscape and then never updating it to eke a few more years out of the desktop app infrastructure that sucked.

> You might need to enlighten yourself on exactly which browser first brought us ajax.

AJAX is older than XMLHTTP Request, virtually you can do AJAX with [i]frames, and this method is not even obsolete, because to my knowledge, that is the only way you could do a file upload(that works even in ancient browsers).

> IE was brilliant when it came out.

That still makes it a curse today.

Not really. As the other poster said, IE was intentionally abandoned after Microsoft "won" the browser war to drag out the desktop market a few more years. Honestly, until the last few years, web development technology stagnated HEAVILY because of Microsoft's abandonment of IE. They were able to vastly slow the forward movement of web technology for almost a decade.

> furthermore, isn't blaming IE close to blaming the customer?

Not even near. I'm blaming Microsoft for this one.

> The customer has chosen (even if the decision was made for them)

This is self contradictory.

> and that is something that we as developers have to live with

Sorry, but I believe in innovation.

> "proven paradigms" is a ridiculous term by itself in software development, putting it in web development context just makes it dumber. If desktop apps are so good, then how come web apps are still around? There is a reason why people still prefer jQuery over many of those.

I'm not sure usage counts are an indicator of quality. I bet the majority of javascript developers use jQuery because it's what everyone else is using, similar to why they're using php for writing their apps.

I'm not saying that jQuery is bad, just that usage counts is often a bad indicator.

I think it's popular because it's: simple, small, efficient and documented.

For hugely complex web applications you would probably desire more, but the fact of the matter is that the browser world is not ready for huge stuff, we still have IE, we recently got iOS, Android and many others. Progressive enhancement doesn't really allow you do those complex client side apps.

Look behind you, we're already building them. Not everything needs to work in every old browser.