Perhaps this isn't a good place to ask this, but I'll try to make it as objective and answerable as possible.
I've been playing with Angular.js and really liking it, but I have a question about its philosophy. Here's a snippet of code from the Angular site for a controller.
<div ng-controller="TodoCtrl">
<span>{{remaining()}} of {{todos.length}} remaining</span>
[ archive ]
<ul class="unstyled">
<li ng-repeat="todo in todos">
<input type="checkbox" ng-model="todo.done">
<span class="done-{{todo.done}}">{{todo.text}}</span>
</li>
</ul>
<form ng-submit="addTodo()">
<input type="text" ng-model="todoText" size="30"
placeholder="add new todo here">
<input class="btn-primary" type="submit" value="add">
</form>
</div>
This is basically HTML with Angular directives sprinkled in. The one that I find potentially susupect is this: archive.
When Jeffrey Zeldman wrote Designing With Web Standards, it became a best practice to separate markup (HTML), presentation (CSS), and interaction (JS) into different files for maintainability.
My question is, how does Angular not violate that? I'm actually really enjoying it, and finding it quite powerful, but what is the difference between binding a click event to an a element like that in the markup, and writing this vestige of pre-web-standards code:
<a href='#' onClick='showAlert()'>Click here</a>
<script>
var showAlert = function(){
alert('hey');
}
</script>
Helpful answers might refer to documentation in addition to personal experience with using the framework.
I'll start with the piece of code that you find suspect and the fundamental difference between how it is handled in AngularJS vs. plain HTML and Javascript.
This is basically HTML with Angular directives sprinkled in. The one
that I find potentially susupect is this: <a href=""
ng-click="archive()">archive</a>.
This looks awfully similar to something we would have written 10 years ago:
archive
However, there is a fundamental difference between the above HTML and the AngularJS implementation. For AngularJS, the archive function is located on a scope that we control and can manipulate through the use of controllers. The raw JS example requires that archive be in the global namespace (which is bad for many reasons).
But, we can still see what the onclick event binding was meant to do; it was meant enable one to declaratively build behavior into a view, and let JS handle the implementation details. AngularJS does this, AND provides a way to organize the difference scopes/contexts of our view in a way that is not possible with regular HTML.
Yes, AngularJS involves extending HTML by moving more of the presentation and binding concerns into the view. The good news is we are heading that way with HTML6. Here are some select quotes from http://html6spec.com/:
Imagine being able to mark something up the way you want to mark it
up. Imagine changing <div id="wrapper"> to <wrapper>...
The web is moving towards a giant app store and we need to embrace it.
The markup we use shouldn't work against us, it should work for us.
This spec is to do just that. To finally break free of fatuous rules
and standards and to give us, developers, total freedom to code as we
please bringing the web a more semantic, clean, and human readable
markup.
In a way, AngularJS brings us all the goodness of HTML6, but allows us to use it today. How the web is used has changed drastically in the past 15 years and our tools are still lagging very far behind. Lucky for us, the future is a beacon of light and hope, and AngularJS brings the future back to the present.
Quite an interresting observation and question, and a good answer by #mortalapeman.
I'd like to add that the function of the html, and our expectations of what it's supposed to do is changing. We've been taught to keep our behaviour completely out of the document (html) and rather set up our code to hook into the document without polluting the document.
With Angular the job of the html isn't simply to be a document, it is to be the presentation layer of an application, which to me is a much bigger job. And to fill this job Angular (and similar frameworks) allows us to do two-way binding with our data and behaviour in a declarative way while, as mortalapeman points out, keeping our data and behaviour nicely scoped and separate, as well as testable.
In fact, now that I think about it, it's actually a bit silly to maintain a position that your html should be a pure document, but at the same time contain buttons and other controls, indicating that it is more than a document. Maybe it's just me, but I find that paradoxical. It makes perfect sense to me that we declare what action should be triggered when operating a control.
I was studying Angular recently and had the exact same thoughts, doesn't this violate separation of concerns? The examples they give at their site "Do violate separation of concerns!" After being involved with MVVM and MVC over the past 10 years, I'm thinking that Angular is a step back to the Cold Fusion days. Not that Cold Fusion and Angular are not strong, they just are enablers for bad design.
All SDLC studies show that 50-60% of total cost of software is in maintenance, not development! But most developers think (because of due dates) they just have to get it out there, and to their credit, they do! However, projects end, developers leave and the rest are left wondering how to support this code base.
We've know about OOP and OOD for years and just recently saw attempts to bring Javascript into this concern with extensions like JQuery Although until Javascript truly becomes an OOD language it and all extensions of it, will not truly get there. The comment above "gloabal variables are bad" is a good comment, but in strongly typed languages, it's NEVER a concern. The only time these types of issues happen is when the framework supports it out of the box! Strongly typed languages can have global vars if needed but scoping is king in those languages and it is one of the first things taught.
My experience over the years is that programmers are first 1) Quick to get the job done before they recognize the patterns that make up good technique. 2) There are tons of code in every major institution that needs severe re-factoring 3) Problems in extensible are not seen until many years later 4) The effort to re-tool is huge! All of this is good news for job security, yet at the same time, why not just do it correctly from the start?
JQuery, Javascript and even Angular have their place, but they are also frameworks that encourage bad design for those unaware. I've found the single most important pattern in all of programming is the "Observer Pattern" which we see in the ability to create Event Handlers and to create Events. Decoupling then becomes very high on the list as well. If you have code that is big on events and event handling chances are, you are headed in the right direction. If you are reusing code and being strict about not repeating things you are doing well. Finally if you are into re-factoring with a passion and really understand the power of interface based programming techniques you are doing well. Oh yes one other thing, if you know what dependency injection is all about, you are a 5 star general in the Army of Programmers. March on, good soldiers!
I have been using Knockout.js (which is pretty similar to angular regarding the data-binding concepts) for the past two years on a large project. The main advantage I see in having only some function names in the markup, instead of the entire function implementation is that the implementation can be easily changed without altering the markup. Especially if the markup is not fully controlled by you, as was in our case.
The designer altered the markup to suit the visual requirements, while we just told him not to mess with data-bind attributes. Of course, sometimes he changed the markup so heavily that we needed to alter the data-bind attributes, but this mostly meant moving them from one tag to another, the implementation was unchanged.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the best practice for Dojo dijit creation?
A purely declarative approach (D)
A purely programmatic approach (P)
A combination of the two (D&P)
Criteria
Easiest to maintain
Fastest to develop with
Most intuitive
Best performance
Most functionality and flexibility
Context
I've been working with Dojo for a little less than a month now, and I've recently started working with the dijit library. One of the well-advertised aspects of dijits is that they can be declared programmatically or declaratively. I always like to approach a new set of tools with an understanding of best practices and some general idea of which approach has which strength/benefits for a particular application.
The information below comes from some personal experience with both styles, as well as the reference material I've been able to find, which isn't a whole lot. This link is the only one I've found in the official Dojo documentation on the subject, and this post provides some outside perspective with a basic presentation of how the code for each looks for simple scenarios. Both links are for older versions of dojo, before AMD was introduced in version 1.7.
Programmatic
Separates Dojo from HTML, which preserves semantic purity of HTML
Puts event handlers and widgets in the same place, increasing readability
Seems to make it easier to assign values to attributes dynamically (e.g. create unique IDs using a function)
Declarative
Rapid development -- intuitive, implied nesting, widgets defined like normal HTML elements
Valid HTML5 through use of data-jojo-* attributes
Does not preserve semantic purity of HTML
Event handlers come from outside scripts, creating some complexity and reducing readability
Initial parseOnLoad can slow up-front widget setup
A note on responses: Please address each of the criteria in your response. Feel free to propose any additional criteria you think are important. I am by no means an expert at evaluating best practices.
Update:
After browsing around for more info on this, I found another post with similar thinking, which provides some useful context on what implications these style differences have.
I don't think there isn't a best practice. Personally I like to use a combination of both programmatic and declarative code.
I think it makes more sense to seperate the presentation layer from the business logic layer (somewhat like the n-tier architecture). I mean, what's the difference between a dijit/form/TextBox and the standard <input type="text" /> HTML element? They're both part of the presentation layer and they both have the same purpose. The only difference is that the one is a custom element while the other one isn't.
But on the other hand, I consider event handling and validation as business logic, so I would put these into a JavaScript. You could also declare your dojo/store objects declarative, this is also something I don't like because it doesn't have to do with my presentation layer.
Now, back to addressing your points:
Easiest to maintain: If I had to change a dijit widget, then I would probably look into the HTML (seperation of concerns; presentation <--> business logic). It's also easier to find. For example, if you know that the dijit widget is right below the title and just above a button, then you exactly know where to look for in your HTML code. If we made it programmatically, it could be anywhere in your code.
Fastest to develop with: Well, maintaining and developing is a bit the same, but another advantage of declarative markup is that the markup you write actually serves as a placeholder while programmatically you will have to assign each property to a value.
Most intuitive: I also address this in the first part (easiest to maintain). I also think that it's pretty good that they also use a few standard HTML attributes like title, value, placeholder, ... . I don't think this pollutes your HTML markup, but increases readability too.
Best performance: It's not the fastest way, I'm well aware of it. But the margin is pretty small, it's not that it is a huge difference. You could also tweak it by disabling parseOnLoad and manually parse the nodes you need to be parsed. Another nice thing is that the end user "sees" something. For example, if you write the following code:
<select data-dojo-type="dijit/form/ComboBox"></select>
<input type="text" placeholder="Text..." />
The end user actually sees something when he loads the page (and it's pretty representative of the real result), even is the page is not parsed. When you create everything programmatically, the only thing the user will see is a white page.
Most functionality and flexibility: Because I think combining declarative and programatically way of developing, I can enjoy the benefits of both. You're somewhat blocked in doing everything in a declarative way (event handling really looks messy if you put it all in your HTML), but I would write those in JavaScript code.
On the other hand, it really looks messy when you're creating a widget programatically (that's an opinion), so I can define these in HTML where it's a lot easier.
So in the end I like to write a combination of both. Event handlers indeed come from outside scripts, but if you write proper MVC applications, they always will (since it is a part of the controller while the markup itself is part of the view).
I'm not saying you have to put all event handlers in one file, no, thanks to the AMD loader you can easily add other scripts. If you group all interaction of a certain widget (or a group of widgets) into files and name these correctly, it's pretty easy to find things.
The more files, the smaller the files usually are and the easier they can be read (so complexity goes down and readability goes up). You might end up with a lot of files, but if you name these correctly (and document them maybe), there should be no problem.
But in the end, this is an opinion, there are probably other opinions too which are as good or even better than mine. Sometimes it's also depending on the situation, if performance really is one of the biggest requirements, then defining everything in JavaScript might be the best solution too. It's not like these rules are carved into a stone somewhere.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to create a custom UI framework in JavaScript for web applications (like Google Docs ui) (do not confuse with web application that deploy using languages like PHP, Python, etc.). However, after reading several books about web development, I understand that the best website is layered as follows:
Structure in HTML
Presentation in CSS
Behaviour in JavaScript
So there are several approaches to creating my own HTML document and control it in JavaScript. However in this approach HTML and CSS will be mixed, like in case of extJS UI. I am confused now, and I need some answers from experienced developers on how to write this kind of framework.
If HTML, CSS, and JavaScript is mixed.
What was advantages?
What was disadvantages?
Is there are other methods?
What was the usual type of creating UI frameworks?
I apologize that this answer is extremely long and at times may seem somewhat off-topic, but please keep in mind that the question was not very specific. If it is improved, or made less general, then I will gladly remove the superfluous parts, but until then, just bear with me. This is somewhat of a compilation of the other answers here, in addition to my own thoughts and research. Hopefully my ramblings will be at least somewhat helpful for answering this question.
General Tips for Frameworks
Frameworks are a ton of work, so don't spend all of that time for nothing. Work Smarter, Not Harder. In general, you should remember these things when creating a framework:
Don't Reinvent the wheel: There are tons of great frameworks out there, and if you create a framework that does the exact same thing as another framework, you've wasted a ton of your time. Of course, understanding what goes on inside another library is a great way to make your own library better. Quoting #ShadowScripter, "knowledge -> innovation." However, don't try to rewrite jQuery by yourself. :)
Solve a Problem: All good frameworks (and programs) start with a problem they are trying to solve, then design an elegant solution to solve this problem. So don't just start writing code to "create a custom UI framework," but rather come up with a specific problem you want to solve, or something you want to make easier. jQuery makes selecting and manipulating the DOM easier. Modernizr helps developers identify the features supported by a browser. Knowing the purpose of your framework will make it more worthwhile, and may even give it a chance of becoming popular.
Fork, don't rewrite: If the problem you aim to solve is already partially solved by another framework, then fork that framework and modify it to fully fit your needs. There's no shame in building of the work of others.
Optimize and Test: This is kind of a no-brainer, but before publishing version 1.0 on your website, test every single part of the function, under every single possible scenario, to make sure it won't crash and burn in production. Also, another no-brainer, minify your code (after testing) for performance benefits.
DRY and KISS: Don't repeat yourself, and keep it simple, stupid. Pretty self-explanatory.
Stick to Stable: (This is mostly my personal opinion) Unless you're trying to create a framework specifically targetted to HTML5 in Chrome 31, using experimental features and unstable code will make your framework slower, uncompatible with older browsers, and harder to develop with.
Open Source: (Another of my opinions) It takes years for huge companies like Google with thousands of dollars invested to create frameworks (e.g. AngularJS) so it is an excellent idea to make your source openly available. Having a community of developers contributing to your project will make development faster, and will make the end product faster, bug-free, and better all around. Of course, if you're going to sell it, that's another story...
For more information about best practices when making libraries, take a look at these links:
Javascript Library Design
Javascript Module Pattern: In Depth
Best Practices in Javascript Library Design
Building a Javascript Library
Types of Frameworks
The first thing you need to think about, as mentioned above, is what functionality you want your framework to provide. Here are is the list of types of frameworks/libraries (thanks to #prong for the link). For a much more comprehensive list, see jster, which has 1478 libraries, put into 8 categories, each with several subcategories.
DOM (manipulation) related
GUI-related (Widget libraries)
Graphical/Visualization (Canvas or SVG related)
Web-application related (MVC, MVVM, or otherwise)
Pure Javascript/AJAX
Template Systems
Unit Testing
Other
As you can see from the link, there are already dozens of libraries and frameworks in each of these categories, so there's not exactly much room for something new. That being said, I don't want to discourage you- who knows, you could create the next bootstrap or jQuery. So, here are some resources about each type of framework.
Note: you can't say that any type is better than the others, they simply are designed for different goals. It's like comparing apples and oranges.
DOM (manipulation) related
These types of libraries are designed to interact with, modify, and control the DOM of a website. Here are just a few of the things they do:
Select Elements in the DOM ($("div#id .class"))
Add/Remove Elements in the DOM ($("div#id .class").remove())
Edit Attributes of Elements in the DOM ($(div#id .class).height("30px"))
Edit CSS of Elements in the DOM ($(div#id .class).css("property","value"))
Add listeners for various events taking place in the DOM ($(div#id .class).click(callback))
The most notable of these, of course, is jQuery, and it has one of the largest user bases of any Javascript library. However, it is by no means perfect, and if your library wants to compete, the best thing to do would be to make it excel in the areas that jQuery fails- speed, fragmentation, and "spaghetti" code. (The last two aren't completely in your control, but there are certainly things that you can do to make it easier for users to use the most update version, and keep their code maintainable)
GUI-related (Widget libraries)
I think that this may be the type of framework you're looking to create. These types of libraries provide widgets (datepickers, accordians, sliders, tabs, etc.), interactions (drag, drop, sort, etc.) and effects (show, hide, animations, etc.). For these, people are looking for quantity- the best frameworks out there have several useful widgets/effects that work well. This is one case where it's "the more, the merrier," of course, if it works properly.
Graphical/Visualization (Canvas or SVG related)
The purpose of these libraries is to control animations on the page, specifically on an HTML5 Canvas. These feature animations and sprites for games, interactive charts, and other animations. Again, successful graphical libraries have many, many sprites/animations. For example kineticjs has over 20 different sprites available. However, make sure that quantity does not compromise performance and overall quality.
Web-application related (MVC, MVVM, or otherwise)
Basically, the idea is to provide a layout for the users to put their code in, typically separating the model (data) from the view(what the user sees), with a small controller to provide an interface between these two. This is known as MVC. While it is by no means the only software pattern to base a framework off of, it has become quite popular recently, as it makes development much easier (that's why Rails is so popular).
Pure Javascript- AJAX
This should really be two categories. The first, AJAX libraries, are often paired with a server side library and/or database (though not always) and are designed to make connections with a server and get data asynchronously. The second, "Pure Javascript" are designed to make Javascript easier to program in, as a language, provide helpful functions and programming constructs.
Template Systems
This might also be the type of framework you're looking to create. The idea is to provide components that developers can use. There's a thin line between Template Frameworks and Widget Frameworks (which twitter bootstrap, one of the most popular template frameworks, crosses a lot). While widget frameworks just give a bunch of little elements that can be put in a site, template frameworks give structure to a website (e.g. responsive columns), in addition to making it look good.
Unit Testing
This type of framework is designed to let developers test, or systematically ensure the correctness, of their code. Pretty boring, but also really useful.
Other
This type of framework is for really specific purposes that don't really fit into any of these other categories. For example, MathQuill is designed for rendering math interactively in web pages. It doesn't really fit into any other category. However, these types of frameworks aren't bad or useless, they're just unique. A perfect example is Modernizr, a library for detecting a browser's support for features. While it doesn't really have any direct competitors, can't be put into any of the other categories, and does a very small task, it works very well, and is very popular as a result.
More Types
There are a bunch of other types of libraries. Below are the categories (I'm not listing subcategories because that would take half an hour to copy down) that JSter puts their 1478 libraries into:
Essentials
UI
Multimedia
Graphics
Data
Development
Utilities
Applications
It depends on what you really want. The first distinction that needs to be made is between a Javascript UI framework (which provides structure to the app), an HTML UI Framework (Presentation) and Widget Libs.
Javascript Frameworks such as backbone, angular, ember, and knockout provide MVC-like structure to the app.
UI frameworks such as YUI, bootstrap, and Foundation provide a consistent HTML and CSS base.
Widget Libraries such as jQuery UI, Fuel UX, and Kendo UI provide ready made widgets.
There are also fully-fledged frameworks which provide things across the board, such as Google Closure tools, Dojo with Dijit.
This Wikipedia list pretty much sums it up, and here is the comparison.
In order to find the best way to create a framework, first ask this question: Can any of the above frameworks/libraries solve all or some of the problems/requirements I have?
If something solves all the problems, you can use it right away.
If something solves your problem partially, you can start by extending/forking that project/framework.
Follow DRY and KISS rules. Only solve a problem which nobody has solved as of now.
Fortunately, there is already a good solution: Google Closure Library. This is what Google uses. It shows the approach of mixing HTML, CSS and JS. I wouldn't say it's perfect, but I believe it's one of the best ones at this moment. Its architectural principles rely on proven component based and OOP concepts, and it's accompanied with a static compiler for Javascript. It's definitely worth of studying before baking your own solution.
I'd like to say that cloudcoder2000's answer sums it up nicely. I'm just writing this answer because it didn't seem right in the comment section :P
If you are thinking of making another framework, my suggesting is to stop thinking.
First find the thing in current implementations which troubles you the most, and try to find how you can improve it. Contribute to existing projects, nearly all of them are open source anyways. Also, you don't really need to be a JS-ninja to get into their midst. Take a fork, and get started. Once you're done, and feel that you're code is good enough, make it known to the original repo's maintainers that you have done improvements, and are looking for it to be merged into the project.
Keep in mind here that I'm not discouraging you from solving the problem at all.
I'm just pointing out that there are so MANY frameworks out there, wouldn't it be better if you went ahead and contributed to one of them instead of going for complete glory and implementing a full framework yourself? Making a framework is hard, but getting people interested in your framework is HARD. Really Really HARD, even for Google! Only once Angular got a very good documentation (which itself took quite some time, and resources, of Angular evangelists), that it has gathered so much steam. So, I'm just saying that instead of creating your own monument, perhaps lending a hand to others would be a more worthwhile exercise.
Most importantly though, is the fact that since you are just starting out, I presume you wouldn't have much experience designing frameworks, or thinking in those design terms even. It would of immense value if you contribute to existing projects. Then you will be gathering knowledge and experience of how things are built. Then, you'll be more confident. Then, you can go ahead and make your own framework! Then you'll be more equipped to tackle mammoth projects such as designing a framework. And Then, my friend, will you make something which would be worth the time of countless developers.
Short answer
Build a skinny DOM and only focus on JS code to make it more efficient.
Long answer
A good architect always replies with "it depends." You can't have one single framework that enjoys all others' benefits and suffers from no disadvantages, all at once. There's always a trade-off.
In order to create a framework that is really lightweight, you would probably want the lightest DOM (HTML) structure. However, having a skinny DOM might have the cost of more JS code. So you would probably try to write the most efficient code. You can start here.
Needless to say, you should be keeping the open-close principle, and have the stylesheets separated from HTML, using only classes and never inline styling. I would suggest using less. It makes the implementation faster, and the result is pure css so you suffer from no performance issues around it.
I must respectfully disagree with cloudcoder2000,
From a young age I have been being told don't re-invent the wheel, but why?
During the last 3.5 years, I have re-invented almost all of my web controls using javascript/html/css. From the extremely complex; for example a grid, rich text editor, tree view, dialog. To the very simple, like a progress bar, dropdown. What I gained is a better understanding of html/js/css.
No pain, no gain. I'm so happy with what I was doing these years as I learned more than others.
Some of the controls I re-invented, I think, are much better than the popular ones, like telerik, jquery mobile, extJS. For example, my tree view is fully customizable, with it one can build very complex trees.
So, I encourage you re-invent the wheels, and you will definitely get more than you expected. But also, from the beginning, you need to learn the source code of the popular controls, and re-invent them. You will be very happy when you find yourself be able to make the controls better.
Then the tips on creating HTML controls:
1. use jquery;
2. write jquery plugins(jQuery.prototype...) for simple controls, while define classes for complex controls;
3. separate css from html and js files. Define the html template in js, don't use html files, which make using the controls hard.
Regards,
Leo
For best performance in your UI design, you need to use a lightweight JavaScript framework like angular or backbone, Twitter Bootstrap for the UI, AJAX for base script load and use gzip compression in your app to make it lightweight and help the UI render faster.
I've recently got up to speed with Knockout and I think it's a fantastic framework. However I have one concern.
I'm finding that in non-trivial binding cases, I have snippets of javascript code creeping into my view (markup). In fact quite a few code samples in the Knockout documentation demonstrate this too.
Does this make Knockout inherently obtrusive?
Should I just accept it for what it is and not be worried in practice?
Or are there any patterns/techniques I should be employing to make Knockout unobtrusive?
Great question. I've been writing complex KnockoutJS views for awhile and was never satisfied until I switched to Ryan Niemeyer's class binding provider.
The Knockout ClassBindingProvider allows you to declare your bindings in a JavaScript object and then reference them from a data-class attribute similar to how css classes work. It works great!
See an example TodoMVC app.
Try to keep Javascript out of the bindings and only use it for metadata
so instead of doing
<span data-bind="visible: errors().length > 0">You have errors</span>
Use a computed observable
<span data-bind="visible: hasErrors">You have errors</span>
Update: I went ahead and created a Convention over configuration API for KO
It can be found here https://github.com/AndersMalmgren/Knockout.BindingConventions/wiki
Instead of doing <button data-bind="click: save">Save</button> you're doing <button data-name="save">Save</button>. The library will understand by convention that you want to hookup the save function to the button click handler. By convention it will also bind enable if a canSave member is present.
http://jsfiddle.net/3Ajnj/15/
Should I just accept it for what it is and not be worried in practice?
My understanding is that "unobtrusive" means a few different things.
One aspect of "unobtrusive" is that websites should maintain core functionality on browsers with limited JavaScript support or none at all. To that end, your concern for this principle should depend on your target audience. I've worked on projects where I knew my target audience well enough that I had the luxury of saying, "if you want to take advantage of this web app, use a modern browser like Chrome, with JavaScript enabled." In this case, feel free to go buck wild with the latest, awesomest front-end frameworks out there.
I've worked on other projects where this was not the case we had to be very careful with our usage of frameworks like Knockout. If you're relying heavily on Knockout to do core functionality in your application, then your application is inherently obtrusive. Whether or not this should bother you depends on your target audience.
Another principle of "unobtrusive JS" is a separation of concerns between JavaScript and HTML. I actually debate how strictly important this principle is. I think a more important principle is a separation of concerns between view model logic and display logic, following the MVVM pattern. Knockout does a fantastic job of encouraging clean separation of view/vm concerns, even if you put a bit of JavaScript logic in your data bindings. As long as it's strictly view logic, I think it actually belongs in the view.
I recommend you, that you pay a visit to Ryan's blog and read: "Simplifying and Cleaning Up Views in KnockoutJS", if you haven't done so...
http://www.knockmeout.net/2011/08/simplifying-and-cleaning-up-views-in.html
It explains some nice ways for you to refactor your code, so it doesn't clutter the html and keep it more clean.
An alternative, to the binding provider suggested in the selected answer, is the knockout.unobtrusiveBindingProvider, which is "an unobtrusive, convention-based binding provider for Knockout JS that enables a clean separation of HTML and Knockout databindings".
Is OOP justified here?
Today was my first day at work at a small start-up. The start-up has a whiz JS developer who has A LOT of custom js using OOP for features such as modal window. More importantly, he has made almost all data display(such as rows of data to be displayed with edit/delete buttons) into some form of javascript OOP representation.
One of the things we are trying to do is remove a bunch of use of modal and just display the contents outrightly on the main window. Usually this would just mean copy/pasting a bunch of html/php code that was otherwise shown in the modal window. However, since this dev has developed everything in OOP and all these UI-related objects are closely tied to each other, moving away from modal window appears to require a lot more labor/fixing.
When I took this job I was excited and thought I'd get some experience getting knee deep with practical OOP. But a day later, I am yet to see its utility and at worst seems very counterproductive.
Am I missing something? When is it a good/bad idea to use OOP in javascript?
I think it's a good practical approach, but as with OOP in any other language, it can be either implemented well or poorly. OOP techniques for JavaScript can properly separate code instead of having strictly utility methods, so I don't believe it's a bad idea. But from the sounds of it, you may want to try to refactor the design to make it more simplified, and then move code around...
There are concerns with doing everything in JavaScript, depending on what's being done in it, such as security, maintainability, cross-browser support, and more.
HTH.
OOP can be a very powerful tool to ensure that rewriting code is not necessary and that code is maintainable, but if it is improperly done, it can have the opposite effect. Design Patterns are employed to make sure that code is maintainable, and OOP is a big part of that. This book seems to be an authority on the subject.
Without knowing more specifics of his implementation, its hard to say whether or not is approach is good. However, there is a strong trend in web applications to do heavy OO design (along with MVC or MVP design patterns) on the client in Javascript. Additionally, much of the rendering of the page is done with Javascript as well- frameworks such as Backbone.js (or Knockout.js as mentioned above) for this purpose are very popular, and quite interesting.
Javascript itself is actually an extremely good Object oriented language (see what Douglas Crockford has to say about it), and is currently undergoing a sort of renaissance, especially with younger developers.
Since pretty much everything in JavaScript is an object, it's difficult to avoid some degree of OOP-iness in your code. OTOH, most JavaScript frameworks focus more on the functional aspects of the language.
In any event, I suspect the problem you are really getting at is that there is insufficient decoupling between the UI and the data model. If so, then look at frameworks — such as knockout.js — that explicitly separate them.
I will say that OOP has a tendency to bend the brain into the wrong shape. I remember that in the early days of OOP and OOAD, the idea that objects should be responsible for rendering themselves to a GUI was extremely common. As problematic as this is, it was a direct consequence of the core OOP principle that the behaviour of an object should be coupled with its data.
Aside from the language differences Javascript vs. Objective-J what benefits does Cappuccino provide over SproutCore and vice-versa in your experiences?
In terms of a long-term forecast, is SproutCore more "supported" than Cappuccino because it is backed by Apple?
I am trying to choose between the two. I am both familiar with JavaScript and Objective-C.
This is an interesting question, and one that has been popping up fairly frequently on various messages groups, twitter, and even IRC. There's a couple of ways to evaluate SproutCore versus Cappuccino, but, perhaps, some of the immediate caparisons that people look at are the following:
1) Their respective feature set
2) Ease of use
3) Community support and documentation
Let's look at the first point -- there respective feature set. By "feature set" there's a couple of ways to look at it. From the number of UI widgets they have; the foundational support to connect things together and communicate with some kind of back-end; the framework's general architectural approach, although not necessarily a "feature", but still important; and, yes, even the language you can use.
Regarding language, I think it's important that you do not dismiss what is being used (JS versus Obj-J). Why? Because of adoption and where you are coming from. SproutCore came from the perspective that JavaScript is indeed the language of the web, so it's what you use to program against the framework. Where JavaScript lacks in language OO completeness (proper object-object inheritance, etc) it makes up for in the framework (e.g. MyApp.Foo = SC.Object.extend({...})). Cappuccino comes in from a different angle. They use Obj-J as a primary language enhancement to JS in order to inject language features that JS is missing; this instead of injecting those language features directly into the framework (Cappuccino) itself. Of course, as the folks over at Cappuccino have noted before, you can still use JS to program against Cappuccino proper, but, then, you miss out on what Obj-J provides. Note to the Cappuccino community: Please correct me if I'm wrong :-). Finally, if you're someone who is already familiar with Obj-C then Obj-J may be more your cup of tea. Hey, even Sony is apparently now jumping on the whole Obj-C bandwagon to develop against their mobile platform :-P.
Looking at the architecture of the two frameworks, they both looked at Apple's Cocoa framework for guidance/inspiration in one form or another. Cappuccino took Cocoa fully to heart and basically ported Cocoas API. Again, if you're coming from developing apps in Apple using Cocoa then you're probably going to feel right at home. SproutCore on the other hand took inspiration from Cocoa where it felt right. As for pure architecture, they both follow MVC, they both make use of Cocoa-style bindings, they both have a data store mechanism, and they both have their own respective style of rendering and composing UI widgets/views.
The rendering of views is, to me, a particular area of importance. Both frameworks have some level abstraction in order to remove you from directly dealing with CSS and HTML even though at the end of the day they have to render to what the web browser ultimately understands.
On the Cappuccino side, they completely abstract away CSS and HTML from you. Instead, you use the framework's various rendering primitives to "draw" your views. Because of this level of abstraction, Cappuccino can make use of the best rendering approach available instead of coupling you, to some degree, with CSS and HTML.
As for SproutCore, you are rendering closer to the "metal" so to speak. When doing a pure rendering of a view, you make use of a rendering context object that provides a certain degree of abstraction, but, ultimately, you are directly injecting HTML and adding class names to apply CSS. Even after your view has been rendered and you want to manipulate certain parts of the view based on an event, you can directly access to the DOM elements and manipulate their properties. Depending on where you are coming from this may seem good or bad. Good for those who are used to working with CSS and HTML and like the more direct control over how the views are rendered and styled. Bad if you want to generically render a view in order to make use of the best render approach based on what the browser allows (HTML/CSS, SVG, HTML5 canvas, etc). But, note, there are future plans to make SproutCore have a more abstract rendering approach but still allow you to directly work with HTML and CSS if you so choose. So you'll eventually get the best of both worlds.
Now, as for the stock UI widgets/views the two frameworks come with -- they both have a lot right out of the box in order to get you going. Buttons, labels, lists, segmented views, radio buttons, scrollers, etc -- they're all there. Therefore, it's safe to say you're fine in both camps.
Going all the way back, let's now discuss the ease of use. To me, ease of use is based on you own personal experience working with JavaScript, HTML, Obj-C, Cocoa, other MVC frameworks, documentation, and community support. If you've never worked with Cocoa, or never built a decktop- or iPad-like app, then it's fair to say you're going to have a bit of a learning curve no matter what framework you choose. That being said, what you don't know and want to learn can be acquired through each framework's respective community and docs. Both have active communities in one for or another, so you won't be left out in the cold if you get stuck somewhere. As for docs, Cappuccino, admittedly, has the upper hand. The docs for SproutCore are lacking, but the code base is at least fully commented. The SproutCore community is fully aware of the docs needing to be updated, and it is currently something that is being dealt with, so keep checking.
Finally, you mentioned the long-term forecast for the two frameworks. It's public knowledge that Motorola bought the Cappuccino framework, so you certainly have a big company backing its growth and longevity, or at least it seems like that way for now. As for Apple and SproutCore, I personally can't speak for them, but Apple does not own the framework. There are many companies and various individuals that all use and contribute back to the framework in some way. That might give some people and companies pause or discomfort for those who are looking at SproutCore due to the more organic nature of the framework's development, but I don't see that as a problem. My feeling is that both frameworks will be around for a long time, especially now that more are looking at developing next generation desktop and iPad apps using open source frameworks. And, hey, competition between the frameworks is good -- keeps everyone on their respective toes :-).
Hope this information helps you out with your decision!
Cheers,
Mike
I'd like to touch on the comments made about objective-j Michael.
You're not going to lose anything if you drop down to JavaScript instead of objective-j. In all actuality the distinction is kind of difficult to make, especially in cases where we have toll-free bridged classes (more on that in a bit).
Objective-j is really just a thin wrapper over js. It provides classical inheritance something that has traditionally been implemented as a language feature, which sproutcore implements as a framework feature, it also provides code importing, accessor generation, static scoping, and support for messaging nil.
Objective-j instance variables are accessible via the traditional dot syntax if you want... I like to think of it like this: once you start writing a method, you're mostly writing JavaScript. That is, loops, variables, functions, closures, etc are all just javascript. You're not losing anything by dropping down, that's exactly how the language is designed.
We take it a step further by "toll-free bridging" some of our classes CPDate, CPArray, CPException, CPString and perhaps more that I can't recall. Toll free bridging just means a CPArray IS a native js array, and a native js array is a CPArray, so you can use methods and functions of both world interchangeably.
So for example would could do:
var foo = [];
[foo addObject:"bar"];
foo.push("2nd push");
var value = foo[0];
var value2 = [foo objectAtIndex:0];
alert(value === value2); //true
As you can see I'm using objective-j syntax and js syntax together... You can imagine the power if this.
The final thing I want to put out ther, just to make sure there is no confusion: objective-j gets parsed in the browser. It doesn't need to be compiled before hand (although we provide compilation tools for when you're ready to deploy your app).
I think some people are needlessly put off by objective-j as if it's some monstrous beast that will take time to learn, and while objective-j adds a lot of great features to js, to actually learn them won't really take you the better part of a day if you're already familiar with object oriented programming, and obviously if you're coming from cocoa you'll be able to jump right in.
I wrote a blog article exactly about "cappuccino vs. sproutcore". It is not a technical comparison but compares other interesting data.
http://elii.info/2010/11/cappuccino-vs-sproutcore/
From the Cappuccino website:
"On the other end of the existing frameworks are technologies like SproutCore. While SproutCore set out with similar goals to Cappuccino, it takes a distincly different approach. It still relies on HTML, CSS, JavaScript, Prototype, and an entirely new and unique set of APIs. It also requires special development software and a cumbersome compilation step. We think this is the wrong approach.
With Cappuccino, you don't need to know HTML. You'll never write a line of CSS. You don't ever have interact with DOM. We only ask developers to learn one technology, Objective-J, and one set of APIs. Plus, these technologies are implementations of well known and well understood existing ones. Developers can leverage decades of collective experience to really accelerate the pace of building rich web applications."
So it seems that Cappuccino does not have/need any build tools, and completely abstracts the browser away from the developer. Whereas in Sproutcore you get build tools (a development server, for example) and the developer should be somewhat aware of what DOM is.
Michael Cohens answer pretty much covered everything since it was extremely detailed.
I have been struggling with a decision for the past 3 weeks. I have read everything there is out on the web about both frameworks and I have written a lot of source samples with both and still cannot make a decision. The following issues have me jumping from one framework to the other and keep making my decision tougher.
Sproutcore has a better data store api than the one cappuccino has.
Sproutcore makes use of bindings better than cappuccino currently does. Cappuccino does also have kvc/kvo support but bindings are not totally there yet. For example in sproutcore you can implement incremental loading with bindings and ArrayController very easily where on the other hand in cappuccino its not as straightforward. Of course cappuccino offers the CPTableView DataStore api which is pretty clean and can achieve similar results just not with bindings. Its what cocoa did before core data. Bindings are constantly being worked on in cappuccino though.
Cappuccino has a better view api according to my personal taste. Although I am used to developing html and the DOM I much prefer the idea of abstracting the DOM completely away and getting rid of css.
One issue that is really important to me is the lack of a good TableView in sproutcore. Currently SC.TableView is in alpha and it is not performant at all. I dont know of a timeline for the tableview in sproutcore. I tried asking on the irc sproutcore channel but got no satisfying answer. Cappuccino on the other hand has a great and very optimized table view.
I have found more real world applications written on cappuccino than on sproutcore. There is also a pretty nice full blown application that is provided by cappuccino as a source sample and is very helpful. Check out http://githubissues.heroku.com/.
Despite the fact that I have no experience in objective-c and I much prefer the pure js syntax I will probably go with cappuccino on my current project and hope sproutcore comes out with a better table view in the future.