I want to develop a relatively simple application that calculates some value based on several inputs. I dont want a backend, all the calculation can be done in the browser.
Im a little new to JavaScript and WebApps and I came across Backbone.js.
I really like the MVC design, however, they mention a backend a lot. My question:
Is a backend server absolutely required?
Is a backend server optional but without one there isn't much point in backbone.
Or will backbone will really help me out?
Backend is not required.
Backbone can fully work without any backend if your application doesn't require one.
That depends on your application. If you want to retrieve value of some inputs and calculate a result then Backbone won't do that for you - it will help you structure your code. If you app is simple and don't need support for models, views and collections or routing, then there is no point in using Backbone. Hard to answer this question.
For example: Classic todo example application doesn't use any backend.
Backbone.js implements fetch(), save(), destroy() etc. methods on models automatically performing appropriate AJAX requests and parsing response. So it has a strong support for backend via REST services, but it is optional.
You can still use models, views, routers and events without any server-side code. Just don't call REST methods (or override them at your wish).
You can use localStorage for persistence (you'd have to implement this yourself or find it on the web, like here) but if you don't even need that then you don't need to use any of the persistence methods in backbone.
Backbone is meant to help you structure a medium-large sized application (js-wise), so it doesn't become unmaintainable jQuery spaghetti. With short applications (js-wise) it's really an overkill unless you are trying to learn how backbone works.
Note with js-wise I mean the client side code, if you had a huge backend but the only js would be something that focuses some form, it would not even count as a short application (js-wise).
You can use backbone.js without a backend. However you obviously won't be able to store or retrieve data. Backbone may still be useful for keeping your code organized, however it really shines when you want to separate presentation logic from logic that manipulates your data, which is a goal of the MVC pattern. Generally your data will be stored on and retrieved from a backend.
If you want to play around with data persistence, try out backlift.com. [disclosure, I work on backlift.com] We've tried to make it easy to get a backbone app up-and-running without having to setup a server or deal with compiling templates.
Related
My project would be a kind of craiglist, a site where users could post anouncements (evereday-life objects, cars, flat etc.). So, authentication, profile page, content creation, display the for-sale objects etc.
I have developed a very large part of the backend: I have a RESTful API in three-tier architecture developed in java. It makes the link with the db, to provide me with different urls and send me the relevant JSON.
URLs example:
http://api.mywebsite.fr/user?userid=1 sends me back:
{"user": {"username": "jdoe1234", "email", "jdoe1234#gmail.com"}}
I have urls for all actions performed on the entire site (anouncement creation, last data updates ... everything, and I've carefully declared them POST, GET, UPDATE, DELETE, etc.). There is also oAuth to protect the API from queries that are not allowed for the token.
That's all for the "server" aspect, I think that there is no problem with that.
But if all the actions are managed by the webservice, I do not see the interest that could bring me a big server-side framework like Symfony/cakePHP, Zend, etc., to make HTTP requests on my different entry points, retrieve JSON and populate the HTML.
So I looked at client framework, like Angular, Ember and so on. At first, it seemed very suitable for my case: possibility of http requests, manage what to do in case of success or error, directly exploit the resulting JSON to populate the view etc.
I didn't even manage to make my choice between angularjs and Ember, both being very similar, but with the release of Angular v2, I fear the maintainability of v1 (if I choose Angular, it will be v1 , because the majority of tutorials and questions relate to Angular 1.X).
I don't know if I'm doing the right thing by choosing client-side framework, I am afraid that they 'brident' (not sure of that word, sorry) me. Plus, it's fully instantiated in the browser, so the user can change absolutely all code and data I provide. That seems weird to me.
I want to be absolutely sure of the technology that I use in case I make this application available to the public for example. I want to do things properly, in order to avoid maintainability or security problems.
Summary: With the things I already have (webservice / api), is it a good idea to use a client framework like Angular or should I stay on big server-side framework like Symfony/Zend etc? Knowing that I position myself in the context in which this platform would be massively used (craiglist comparable traffic).
I'd say - depends whether you want to be more frontend guy or backend guy in future. If you want to be full stack developer then it doesn't apply.
In my opinion, both Symfony/Zend or other big server-side frameworks aren't so exciting as dynamic frontend JavaScript frameworks like Ember/Angular/React.
Also, if you have already RESTful API and OAuth authentication implemented in backend part I'd go with Ember. Why? Ember Data is great tool for talking to backend API. It's mature, it lazily loads records when they're needed and it's very customizable.
it's fully instantiated in the browser,so the user can change
absolutely all code and data I provide...
Ember has built in security like sanitizing data which is rendered in it's templating language - HTMLBars. Also, there's CORS and content security policy (CSP) standard which is implemented in Ember.
I want to be absolutely sure of the technology that I use in case I
make this application available to the public for example. I want to
do things properly, in order to avoid maintainability or security
problems .
In Ember you can create mature, secure, production-ready applications, but you need to comfortable with your Ember skills to some degree to build such ambitious web application, but it's part of building every application.
With the things that i already have(webservice / api), is it a good
idea to use a client framework like Angular?
Yes, it's very popular solution to use MEAN stack or go with Ember + RESTful API.
Why should I choose Ember instead of Angular (which have a larger
community/tutorials/answered questions) ?
Angular has larger community/tutorials/answered questions, but when I started some side project with Angular to learn its possible advantages over Ember, I was surprised how there was no consensus in it's community for doing one thing. So, instead of fast search how to declare and use directives (I think it was the thing that confused me) I have to do another research which way is the best. Also, there are lots of ways to setup project (where to put custom directives, different Angular objects) and you have to do another research which one to choose. I ended up using repo healthy-gulp-angular as my template, but you can see it hasn't been updated for 8 months, but I think during these 8 months Angular had a lot of changes and I'm not sure if this repo is the best choice.
In Ember you have Ember CLI tool which is built with Convention over Configuration principle. You have also Ember Data which utilizes JSON API standard - if you don't have JSON API compliant server side right now, you can write custom adapter to normalize server responses or change how backend replies. In Ember you don't have all that headache and different best solutions to do 1 basic thing depending who you ask.
What means "Single page application" ?
Single-page application is basically a page which doesn't have to reload all assets and HTML when you navigate. It's advantage over PHP - when user moves to another location he downloads only new data for that route. More info here.
Does those frameworks allow me to create real routes ? (
www.myapp/profil/userid etc )
Yes, of course. You don't even need # in your URL. With simple rewrite rule and small amount of logic for profile route and specified path profile/:userid, when user will open URL www.myapp/profile/userid he will be automatically taken to profile route, and userid would be interpreted as route parameter, so you can take this userid and find user record from the store in model hook.
Client = speed, Server = stability
JS frameworks updates once per week
Non-Js back-end once per year
Client side depends to behavior depending on browser
Back is related only on machine but not on environment
I chose FE coz I tired to debug code by writing variables values to database to actually see what is going on in controllers -_-
Ive been using MVC frameworks for a while now, and have been through Cake, Codeignitor and have now settled on Laravel (thanks to Jeffrey Way over at nettuts). I heard great things about Backbone so I did some of the tutorials and really liked it.
I have a few questions, I hope someone can answer
In quite a few bb tutorials the controllers are always restful, can bb only work with restful controllers?
I'm really stuck in the paradigm of controller -> view. Now with backbone from what I've gathered doesn't use views at all but templates. Is it possible to still serve a view as normal and then client side create a collection from the rendered view? That way I'm still using a mvc backend as normal but also integrating backbone to keep track of my data on the frontend. if this is possible, is is bad form?
In quite a few bb tutorials the controllers are always restful, can bb only work with restful controllers?
Backbone includes default code to work easily with restful servers. However, that functionality is easily overridable to work with various servers or back ends. There are adapters for localStorage, for example. So if your server is non-rest, you can still work with it, but you'll have to write some code to adapt accordingly.
Backbone Views are sort of hybrid views/controllers and templates handle the actual HTML. Generally, if you want to bootstrap a collection in the browser, you need to make the data available as JSON. Rendering HTML on the server and then trying to extract data from that and hydrate a collection is jumping through extra, awkward hoops that people usually try to avoid. What you can do is include your JSON data inside a <script> tag and have it parsed into javascript objects and used with backbone in the browser.
I'm developing a mostly informational public facing website. My architecture is to deliver JSON data to the client for pages in the site. I plan on caching the JSON in localStorage on client and let it persist there for XX amount of time before it refreshes. I'm using client side templates (jsRender) for rendering JSON into UI widgets that are then pushed into view using jQuery.
In my research for this, I stumbled upon JavaScript MVC approaches like backbone.js and spine.js among others. I've read through them and am comparing them to my approach above and am not sure if/why I would need something like backbone.js or spine.js. I'm not doing hardly any data entry except having users fill out contact us form or sign up for our newsletter. So, really no need to keep view and model in sync. I'm just retrieving JSON from my server and rendering it using templates and caching JSON for a period of time in localStorage.
I want to check with the experts out there if my approach seems appropriate and to see if I really "need" backbone.js or spine.js. How would any of these approaches help with my architectural direction?
If you feel you don't need anything else, I would suggest not to use it. "Premature optimization is a root of all evil". When you will run into trouble because your application becomes messy and you spend a lot of time implementing new features or solving bugs then all this stuff will start to make sense to you. Then you will learn why it's very convinient and elegant to implement MVC in your app from the very begining.
I'm searching for a simple architecture for my UI that will have some basic javascript functions in like: select all checkbox's, image crop, some pop-ups and some other plugins.
I found this article: Organizing Your Backbone.js Application With Modules
My application is not a SPA (Single Page Application). I want to know if Backbone.js with jQuery will help me even if my application is not a SPA.
The strength of Backbone is really in its ability to manage many models (even complex ones) and keep the rendered page in sync with their current values. It provides an interface to getter/setter functions so that the changing of a model value (there are many different flavors of "change") will call render on the corresponding view and the page will correctly reflect the underlying models. Furthermore, it provides interfaces to saving, paging, and routing actions on models.
I have used Backbone extensively for both SPA's (where it shines) as well as more traditional, multiple page applications. It has no special support for UI and DOM manipulation, but combined with jQuery/Prototype/Zepto it manages their rendering/manipulation.
Basically, backbone works best to untangle elaborate chains of rendering logic and model updating. If you feel that your application has a lot of view elements that need to stay in sync with models that the client will be updating on the page, Backbone is a wonderful solution. If you just need to select and manipulate DOM elements, it's overkill. jQuery alone can handle that.
Backbone is really not about the things you mentioned, but I wouldn't say it is strictly for single-age apps (SPA) either. I'd say it is for any case where you've got quite complicated pages and it would benefit you to break them up into multiple pieces (for example, several views that all pull data from one model).
However, I would say the strength of Backbone.js is in the SPA realm.
You could probably find some jQuery pieces that answer some of your needs if you're not already using jQuery as part of your app. However, jQuery is all about the parts you mentioned (easy DOM manipulation, popups if you use jQuery UI, etc.) and not about structure or organization.
I believe that the principal idea of backbone, is organize you JS code in complex app using the MVC concept.
This way your app becomes easier to mantain and add new features, It get easy to use frameworks tests like jasmine.
Backbone also make possible (and very good) work based on SPA approach, using ajax request to server. It is completely based on Restful concept, to get a code using backbone, is important to understand what is Restful.
Basically Backbone have a Router (that can work like a controller. but is not a controller).
Model that is where you can manage all the data logic of your application.
Collection that is like a list of models.
View that is where you will react accordingly the model changes.
There are other things, but basically, is this.
But as I said before, you can use it without have a SPA.
The most important thing to have in mind is that the concept of MVC must be followed when using backbone. If you don't do that, it doesn't make sense use backbone.
I'm building a simple client-side survey tool. Users create and edit short surveys and export them as XML (or something similar) when they're done.
I started off using jquery, but realized that it was going to be a headache to map back and forth between the HTML DOM and the underlying XML. It's easy to edit one or the other, but keeping them in sync is a pain.
Anyway, this seems like a standard MVC problem, with a few extra wrinkles:
I want to do all this work clientside.
Lightweight is definitely better.
Any thoughts? I looked into backbone, but it seems to be build around REST-ful interactions with a server-side model, which doesn't work well for me. JavascriptMVC looked really bulky for something this small.
Check out AngularJS which states that it brings to HTML what is required to use HTML for JS driven web applications. You can find a simple example of it's usage in form of a showcase of a very simple todo application on the starting page.
you should have a look at KnockoutJS, which is a JavaScript MVVM framework, which lends itself very well to what your doing.
You can use jQuery to turn the xml into JavaScript objects and add a little Knockout model magic and your UI will automatically update itself when the model changes.
You can use Backbone without server sync by creating your custom storage backend providing in-memory persistence
Look at a sample localStorage backend: http://documentcloud.github.com/backbone/docs/backbone-localstorage.html which overrides Backbone's sync method
I know it's not a true "MVC" framework, but you may benefit from checking out the jQuery template plugin - http://api.jquery.com/category/plugins/templates/ . You can create a template (in this case could be the XML template) that you can use to build the output from a JSON object. This would allow you to maintain the data in one place and allow the "rendering" to happen automatically from your data object.
You can use JavaScriptMVC via it's download builder: http://javascriptmvc.com/builder.html. Just check the model, view, controller and you are off! Here's a walkthrough of using just those parts:
http://javascriptmvc.com/docs.html#!mvc