4 ms·
As with all technology choices, you've got to draw the line somewhere - new and risky, or old and proven, or somewhere in between. What matters these days is p
by Torn 14y ago
As with all technology choices, you've got to draw the line somewhere - new and risky, or old and proven, or somewhere in between.
What matters these days is probably how well you and your team already know the technology, how good the documentation is, community size/takeup, how quick the devs are to respond to issues, and how mature and stable the API is from release to release. How popular/old the technology is also counts for more if you're looking to hire people with experience in it.
MVC on the client is becoming more and more important, once you start slapping a lot of js on a page it can quickly become un-maintainable. We went with Backbone as Ember was changing too quickly in backwards-incompatible ways.
MVC on the server (Django/Rails/Express/whatever) still has a place - you want something serving restful data / html skeletons and mapping urls to responses. In my day job that's Spring MVC because that's what people here know and it ain't broke.
Frontend language choice: Learning JS seems to be the natural choice here. Things that compile to JS e.g. CoffeeScript or DART might also work for you; I don't have experience with them but I'd imagine debugging problems in the resulting js would be a pain until browsers support them natively.
- Kototama 14y agoI used to develop with JavaScript, and JavaScript with Backbone before we switched to ClojureScript. Backbone helped me to better structured my code but I found it also brings its own problems. There is a quite a lot of boilerplate code and views composed of other views were for me hard to manage. I also wrote some macros to use Backbone from Clojure but the mismatch between object/mutable and functional/immutable is too high. Finally the approach from http://clojurescriptone.com/ http://clojurescriptone.com/ seems promising. It uses a simple yet flexible event dispatcher. Add that a templating engine and you are done. Debugging ClojureScript within the browser is harder than normal JavaScript but it's easy nonetheless to find what generated JS functions corresponds to your ClojureScript code. If you compile in debug mode you can set a breakpoint as usual. Compiling ClojureScript adds a bit of overhead to the workflow but I compiled it continuously in the background via Emacs and forget about it, it just popups when an error occurs. In general I found ClojureScript much cleaner than JavaScript and it's easier for me to write cleaner code with it when the data manipulation or the logic is not trivial.
- Torn 14y agoYeah, we had to write our own view nesting logic and allow this to be used within our dustjs templates. Marionette (https://github.com/marionettejs/backbone.marionette https://github.com/marionettejs/backbone.marionette) lets you do all of that stuff out of the box; I've not used it though so can't comment.