* I started out with Backbone. It seems ok as far as it goes, but a bit annoying in that there's enough "magic" and stuff going on that I don't quite understand it completely, but without enough magic to really make things simple and easy.
* Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being.
Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance. I found that very irritating about the Angular tutorial, which is otherwise very nicely put together.
Now I'm testing out jquery-pjax, and... so far I'm happier. It behaves more like a web application that I'm used to, sending around HTML, and staying out of my way. And, seeing as how all of these things require that the server do its job in any case, it has more of a "don't repeat yourself" feel to it: click on the button, and the server gives us some new data, without repeating the whole MVC cycle on both the client and server. I got the idea from this post: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...
> a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application
The backend in the tutorial is in C#/WebAPI, but it's very easy to apply the concepts to any server - the server is tiny and very simple. I'll be doing a Python tutorial with Flask-Restless very soon.
I'd be interested to hear any feedback. I'll be adding video wall-throughs in the next week or so too.
i've went the backbone/knockout/angular route and i think all of them works great for simple things. but if your project gets a bit more complex (or where your code-base changes frequently), you'll start running into all kinds of problems. yes, you can usually hack around them after several exchanges on the mailinglists/irc, but very time-consuming nevertheless.
now, i'm back to plain javascript/jquery. i run into less headaches and more control, therefore more productive. my gripe is the same as op, the "magic" is what throws me off. angular is a bit too buggy, last i used was 6 months ago, and still lot of things they didn't support like proper callbacks upon rendering, etc ...
basically something really easy to do in plain js, becomes like a rubik's cube with all the magic going on. just be prepared to write a lot of extra code/hacks/patches for certain things to just "work" if you decide to go the i.e; angular route. but don't say i didn't warn you :)
Angular is used internally by Google for bit-more-than-complex projects so its possible my friend. It was also used for the Double Click for Advertisers rewrite.[1]
>and still lot of things they didn't support like proper callbacks upon rendering, etc
Heh render callbacks in Angular? That's so Backbone. Did you read the hello world tutorial?
well, if you got the authors of angular on the team, anything is possible, no complaint there. magic is only 'magic' if you aren't the one who created it.
also i don't know why not too many people bring up such issues as the 'if/else/switch' flagging nightmare that comes with maintaining an angular code-base. it makes your code a very verbose in that regards.
backbone? magic? backbone is 1534 lines of straightforward, well written, well documented javascript. backbone is about as simple and un-magic as MVC gets, by design.
I feel stuff like this takes a lot of mental power to understand the context that it is being executed in and what exactly it is doing. It feels like I am knee deep in some obfuscated C code.
It's not that hard when you know the idioms. && is a guard and || is a default. With a little bit more context and experience in writing concise javascript, it's actually pretty clean.
I wouldn't go so far as to say this is horrible code, I also wouldn't say this is good refactored code.
It definitely gets the job done; however, I would imagine someone figures they'll come back and refactor at some point. Code is never finished, it is merely shipped. This is shipping code, but it certainly can be refactored into a more intention revealing function.
It's a trade-off. If you pull it into a new function, it adds LOC. It also is another layer of abstraction. Is it worth it? Perhaps...but maybe not. Just looking at this one line of code in isolation without context is a bit unfair though.
I understood what pjax was doing in about 5 minutes. Backbone.js is more complicated than that, and while I'm certain it's not that hard to figure out, I felt a bit like "ok, it's doing stuff I don't immediately understand, but it's also not doing any deep magic that makes difficult things super-easy, either". Very subjective, but it just didn't feel like a sweet spot. Angular.js actually seemed like more of an "all-in" play with the fancy stuff, but that datepicker issue was a wake up call about getting to a point where even doing something simple might be quite difficult.
Backbone and pjax are not similar so maybe the issue is picking the right tool for the right project. PJax is great if you are looking to help navigate. Backbone is useful with managing objects and collections while keeping them separate from the DOM. It also provides its router to coexist with its views.
you aren't the only one. i too went through troubles and concerns when i started venturing out to use some of the plugins out there, notably datepicker, select2, jqmodal, actually just about any other "cool" plugins out there. creating your own directives to get something to work is something i'd just rather stay away from.
Exactly. If you run into something beyond the docs in Backbone you can just step through the code and see what's happening. It seems to do just enough without drowning you in "other people's code".
I had a similar experience. I use backbone for interactive parts of the app and ended up going with jquery-pjax for almost everything else. Another option is to create handlebars templates that are compiled with the asset package. But that introduces some other problems that need to be solved.
I'm ready to get on board with something cohesive that's Ember-ish whenever it matures.
I've been using PJAX as well. Basically, when you click a link, jquery/pjax intercept the click action, make the request to the server, and on the server-side you look at the request to see if it came as a PJAX request. If-so, you just send back the "partial" section of the page that's being loaded/updated. At the same time, you use push-state to update the URL in the address-bar to conform to the page you've loaded. If the server doesn't detect that the page was a PJAX request, it should respond with the entire page contents - header, contents, footer, etc.. If somebody copies and pastes the URL into a new tab, your site will behave the same was as-if no PJAX header were passed - loading the entire page. This is the same way a search-engine spider will behave. They should "see" the same experience content-wise as a user navigating the site using PJAX.
This particular project runs in kiosk mode, more or less, so I don't care about it at all. Also, if it's just pages, rather than an application, you probably don't need this whole extra layer of junk.
>Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date.... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being.
To be fair, you can just use Angular UI as that article says:
<input ng-model="date" ui-date> for a date picker and the ui-jq directive for any other jQuery plugin.
"Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance."
Couldn't have said it better myself. I can't count the number of times I had been excited about learning some new framework, only to discover that their documentation is non-existent, poor, or written for rocket scientists.
* I started out with Backbone. It seems ok as far as it goes, but a bit annoying in that there's enough "magic" and stuff going on that I don't quite understand it completely, but without enough magic to really make things simple and easy.
* Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being.
Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance. I found that very irritating about the Angular tutorial, which is otherwise very nicely put together.
Now I'm testing out jquery-pjax, and... so far I'm happier. It behaves more like a web application that I'm used to, sending around HTML, and staying out of my way. And, seeing as how all of these things require that the server do its job in any case, it has more of a "don't repeat yourself" feel to it: click on the button, and the server gives us some new data, without repeating the whole MVC cycle on both the client and server. I got the idea from this post: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...