Posts tagged javascript
Posts tagged javascript
I created a simple one file project to help people structure their Backbone.js application. I called it module and you can find the source on Github here https://github.com/juggy/backbone-module
Backbone Module is a simple and elegant solution to load your in browser javascript dependencies. It leverages Backbone eventing and Underscore to bring even more goodness.
First of all, it is not a script loader like require.js or a bunch of other libraries. I believe you are better off loading a single monolitic file in the browser and have it cached instead of loading them all by yourself (and doing the browser’s job of optimizing the load).
You might say: “Excuse me mister, but, if I may object, a dependency loader is useless in a monolitic file” and to that I will answer “You are right, if you want to bang your head against the wall everytime you want to refactor something”.
The truth is that you do not develop a web app in a single javascript file. You create multiple files (each with it’s own scope), you assemble them and upload them to a CDN somewhere in the sky next to the moon. I use Jammit to do so in development.
When you do that and do not think about anything, you will end up with loading exceptions in the browser. Oh! that file should load before this one, let’s change the config. Oh! now it is this one. Back and forth and back and forth. No rapid development.
The solution I use is simple. You wrap each file in a Backbone.module call and reference them using that same Backbone.module call.
((mod)->
#... my app code here
mod.start = ->
console.log "starting"
(Backbone.module("app")))
# ...
Backbone.module("app").start()
This is fine when you do not have any dependencies between your modules. When you have dependencies, you should use the define call:
Backbone.module("core/models").define
property: "Quote"
depends: {"core/models" : "EventedModel"}
, (mod)->
mod.Quote = mod.EventedModel.extend
initialize: ->
#...
So that reads: for the “core/models” modules define a property called “Quote” that will depend on the property “EventedModel” of the “core/model” module. You can also define multiple depedencies from multiple modules. That is pretty all there is to it.
My Backbone applications are usually built like that:
My index.coffee looks like this
((core)->
_.extend core,
views : core.module("core/views")
models : core.module("core/models")
helpers: core.module("core/helpers")
routers: core.module("core/routers")
)(Backbone.module("core"))
Enjoy!
You have a cool startup idea. You want to enhance other people’s web application or web site with metrics gathering, analytics, realtime data, two ways communication, chat, blinking or mustaches on cats. Who knows.
You build your startup and application. You do what everyone else is doing since (I believe) Google Analytics: they configure your application and get a code snippet. They install this snippet on their homepage, web app, whatever. Life is good.
Problem is that you are not alone doing this. At Porkepic we happen to love using KISSmetrics, Google Analytics, Intercom and UserVoice. Four services that we use daily. Four services that each load a script. Four services with each a different loading mechanism: from the simple javascript include to the deferred loading multiline script. Two of those services generate DOM elements and load images, CSS.
We load tons of crap with those snippets. Javascripts, DOM, images, CSS. Some even include a complete jQuery version (!). Your browser have to load, parse, execute all of those files on each page load. (Some does a good job, but most do not even minimize their files.)
Not mentioning you have to maintain those scripts and includes within your code base.
This is a pain.
I am imagining a central service that would let you standardize these services behavior for your web app. You log into the service. You configure the different files you want to load, you configure if you are already using jQuery or JSON or anything like this on your web app already and you configure the loading mechanism you want to have. Once that is done, the service goes and fetch all scripts, sanitize them (checks for duplicate scripts like jQuery), minimifies them and send them to a CDN to be served up to your app when needed.
All the config happens in the service. After the initial setup on your application, there would be nothing else to do.
What would be even more useful is that all those vendors standardize their practice to use such service and provide piece by piece code loading. So if you want to load the code to have a helpdesk widget to let your customer enter support message but do not want to load the code for the chat widget you could.
Yeah. I am dreaming.
I have been testing SproutCore for a week now to check if it would be a good fit for a new project at Porkepic. It is not the first time I played with it, I already checked it back 2 years ago and came to the conclusion it wasn’t mature enough for wide adoption. I must say that v1.0 have come a long way since then. Is the Apple backed open source project ready for adoption by the masses?
To recap, SproutCore is among other things:
It is not Prototype or jQuery or MooTools, it is SproutCore. It is close to Cappucino, but it doesn’t reinvent Javascript nor Objective-C
The most striking feature is called Bindings. Just like in OS X Cocoa development, you bind (draw a line, link data from point A to B) data together to avoid glue code. For example, you have an image and a slider determining its size - if you bind the slider value to the width/height attribute of the image, whenever the user will play with the slider the image will resize. Now that magic can be used everywhere in the code - between your models, the controllers and the views.
There is also an extended set of predefined views. You can whip up a sweet UI without much sweat and have something consistent. The default style is a little OS Xish, but you can style it the way you want by providing a different theme if needed. You can create new views and controls within the canvas SC.View is providing you. You can use Mixin (nice stuff there) to enhance existing views.
Talking about views and layout. The layout in SproutCore is absolute meaning that you position each view on the page manually using X,Y coordinates relative to the parent view. SproutCore folks are saying that it is faster, easier, etc. I do believe them on that, but it is still a pain. With bindings you can manage to move views around, but that adds code (glue code?) that I wouldn’t require using relative position.
The actual HTML is buried within the views which tries to abstract it a little. Each view is part of a parent/child hierarchy up until the page. When you build your page, you actually write Javascript code that builds up the views, one by one. Each label, each input, each containers. A simple Haml code like this:
Becomes this huge curly bracket mess:
Now, this is ok for small “demo” apps but it becomes unmanageable quickly once you reach a good number of views. SproutCore ships with development tools that take all your .js files, merge them together and serve them to the client browser. I think that it would be fairly easy to implement Haml style page builder that spits out Javascript code. It would be easier to read, easier to get into and easier to manage.
I know that the SproutCore team is hard at work building an Interface Builder called Greenhouse, but it is far from finished and, I think, it is just overkill. Overkill because perfecting the view creation with an easy non javascript markup would be just enough. The old principle of separating the UI from the actual code - binding is a great step in the good direction, but it is just one step.
Finally, the data sources. Data sources is what is linking the backend data to the SC model. You use them to load the data using JSON. The data source is closely linked to the data store on the client. You can query the store as you wish and load the data from the backend if needed. I don’t know if it is me, the lack of documentation, or the actual data source, but this is one part that took me a lot of time to get going. Following the only sample I could find in the SC Wiki, it just didn’t work correctly. I guess I was expecting the framework to do more stuff for me out of the box especially for RESTfull object and model. There is not much missing and I think it would be beneficial for first comers (reducing the learning curve).
Talking about learning curve, the documentation is not up there. There is a basic documentation up on the SproutCore wiki and an API reference documentation, but it is far from enough. There are some example code, but they are all small application, nothing big, most of them without backend.
Those are the conclusions I have from my week of testing. I must say that the result is nice, but small for a week of work. I guess the learning curve is steep but that in the long run you become more efficient. How long is the curve? Good question, more than a week, maybe a month to get really comfy.
