HN Explorer

Ask HN: Is jQuery really awful for Single Page Apps?

6 points by notastartup ↗ HN
This is what I see when I read the introduction to backbone.js

    When working on a web application that involves a 
    lot of JavaScript, one of the first things
    you learn is to stop tying your data to the DOM. It's 
    all too easy to create JavaScript 
    applications that end up as tangled piles of jQuery 
    selectors and callbacks, all trying frantically to keep 
    data in sync between the HTML UI, your JavaScript logic,     
    and the database on your server. For rich client-side 
    applications, a more structured approach is often   
    helpful.
Is this really justified? Meaning is learning and writing more javascript code a solution to the potential problem highlighted in that paragraph? I am not convinced because I can do so much more in my head using jQuery nor have I experienced a great deal of difficulty for building Single Page Applications with a LAMP backend.

8 comments

[ 3.6 ms ] story [ 35.6 ms ] thread
onion2k
I'm a huge fan of both Backbone (I'd recommend using Marionette though) and jQuery, and I've spent the last 3 years building single page apps with both. The number one thing that Backbone makes easier is testing - by abstracting your code away from the UI and in to encapsulated blocks of models and views you can write unit tests much, much more easily. When you start doing things with promises (and you will) you'll find it's so, so much better. Debugging a race condition between two jQuery events because something bubbled up further than it was supposed to is a full-on nightmare.
anonyfox
You may have a look into angular testing. Karma/Testacular is just awesome.
glimcat
It depends on the project's complexity, and also on how many generations of developers have dogpiled horrible kludges onto the original code base.

For simple apps, it doesn't matter much. Do what gets you in front of users soonest.

For more complex apps with a lot of client-side state, you may quickly find yourself outside of jQuery's intended use case. Note that simple apps often become much more complex under ongoing development.

What creates problems is trying to pile on a lot of questionable commits without enough structure or organization, and trying to shoehorn it into use cases which it's really not appropriate for. In practice, these situations occur much more often than people anticipate.

notastartup
do you think that it's better to rewrite the jQuery app with a framework like Backbone.js once it reaches an increased level of complexity and developers or should it be built from scratch with Backbone.js or a framework like Ember.js or JavascriptMVC in the beginning? It seems awfully slower than just cranking something out in jQuery but I will admit that something like JavascriptMVC looks rather nice.

Ideally I would like to avoid having to hunt down jQuery libraries by using one of these frameworks. For example, I am already relying on the following libraries:

LAB.js (because I discovered some edge case where things don't load in order)

Cookie.js

Mustache.js

JSON3.js

These are rather great for displaying JSON data in a template with jQuery but I had to actively look for these things.

glimcat
If you're going to be building or maintaining apps in JavaScript, it's absolutely worth your time to learn tools like Backbone, Angular, Ember, or something else in that vein.

If you're more concerned with building a business, the optimization criteria are different. Your priority should be building the business - or at least building enough of the business that you can start acquiring customers and pitching to investors. That gets you runway, market leverage, knowledge of what you should be building to acquire and keep customers.

You can worry about implementation details like tech stack after the business exists. Worrying about it before you know the business is even valid is premature optimization. You are orders of magnitude more likely to fail because you don't start than because you chose the "wrong" tools.

[dead] ursul_fram
the short answer is: you have no choice! throw in the equation custom ui controls, websokets, web-sql and your single web app page quickly becomes a cluster fuck tango. the browser in his current state is nor ready for complex web apps!
gioi
I think the best approach to single-page apps is simplicity and elegance (and often they coincide). You will need some abstraction to achieve simplicity and elegance, and in the end you will be more productive. That's it.

<rant>I have a personal aversion for jQuery... It's awful because you probably don't need 99% of it.</rant>

dave_sid
I expect backbone forces you to follow good principles such as separation of concerns (data-model from UI code etc.)

However, it's still possible to follow good principles using your own design and JQuery, which means you're tied into one less framework and have more flexibility.

If you're developing with a small team, or on your own, then maybe you're disciplined enough to go down the more flexible JQuery route.

If you've got a larger team, then maybe you need the more rigorous constraints of a framework like backbone to make sure everyone is coding to a sensible structure, and you don't end up with 5 design ideas merged together in one big mess.

That's my thoughts anyway. Frameworks can offer essential constraints to help avoid a mess but they might be an unnecessary burden of constraints aren't required.

If I was doing a project on my own. I'd use JQuery and unshackle myself from a higher level framework. If I was working in a team, I'd favour the safety of a framework to prevent too many people doing things their own way.