-3

In my own experience, I like programmatic coding. To name a few benefits at here:

  1. Better performance: no need to parse.
  2. No switch between html and javascript: no html, everything in code(use css to control layout.)
  3. Easy to dynamically change the content.
  4. Easy to be read and be maintained.

But, it seams a lot of users at here using declarative coding. my question is : what's the benefit to use declarative coding? Which one is dojo gurus' favorite?

Sean Zhao
  • 1,506
  • 12
  • 12
  • Separation of interests. Also, I don't think your question is suitable for SO. – francisco.preller Oct 02 '13 at 05:16
  • And, I think the word is "imperative programming" and not "programmatic coding". – Stewie Oct 02 '13 at 06:10
  • @francisco.preller : I am asking dojo projects. I doubt that you understood my question. Obviously you have not enough experience to use dojo. I appreciate Dimitri , his answer help me a lot. – Sean Zhao Oct 02 '13 at 10:09

1 Answers1

4

Like fransisco said, you can seperate your code easier. I mean, if you instantiate all your widgets in your JavaScript code, your JavaScript will become pretty large and your HTML will usually be small (only contains "container" nodes which you use to place widgets in).

Better performance: I have to agree with you that it indeed lowers the performance since you have to parse your entire page, but you can optimize that by disabling parseOnLoad and by only parsing the DOM nodes you actually need. At the company I work for we did that by placing all Dojo widget markup inside a <div> with a certain classname. Then in our JavaScript code we do something like:

query(".containsDojo").forEach(node) {
    parser.parse(node);
});

No switch between HTML and JS: The switch between HTML and JS makes it easier to understand your code and to have a context. For example, if you need to modify widget A by widget B that's placed on a page called C.html. Then it's easy to look for your widget A since you know on what page it is and where it's located (top, bottom, ...). If you put everything in your JavaScript file, you will have a hard time managing your code since you don't know in what context the widget is initialized. You will have to look through your entire JavaScript code because the widget can be initialized at any point in your code.

Easy to dynamically change the content: If you need dynamic content I usually create some kind of widget myself and put the JavaScript logic there so my "main" JavaScript and HTML code still look clean. You can always use the dijit/registry module to change certain things in your content.

Easy to read and be maintained: I totally disagree with that, similar to what I said in my previous paragraph about the switch between HTML and JavaScript. I mean, what's the difference between a dijit/form/TextBox and a normal HTML input-field? Not much, they're both UI items. Yet, if I follow your thoughts I would put the TextBox somewhere in the JavaScript code and the normal HTML input field inside your HTML. The HTML not only provides you a context, but also centralizes all UI elements.

g00glen00b
  • 41,995
  • 13
  • 95
  • 133
  • I can't totally agree with your explanation. At my current project we are only using programmatic dojo to insert widgets. There are a few advantages by using it in this way: you can write wrappers around the dojo widgets. If a property will change you only have to edit it in 1 file. In theory you could switch from one toolkit/framework to another. The reason you mention "it's hard to manage such a large javascript file" seems not legit to me. That's an architectural problem. We are using a MVC(f) design pattern and split up every file. I have created some kind of dynamic loader to load the – GuyT Jul 01 '14 at 13:30
  • separate files so that the code will be very clean(and short). I gave you a '+' for the effort and explanation, though – GuyT Jul 01 '14 at 13:31
  • If you're using MVC then declarative widget markup will become even more important in my opinion though. Your controller should only handle user actions, it should not have to care about buttons or widgets, that's where the view is for. If you need some complex behaviour, you could indeed use programmatic widgets, but I would wrap them inside a seperate widget that I would use declarative. This is similar to how other JS MVC frameworks work, like AngularjS and directives or Ember.js and components. – g00glen00b Jul 01 '14 at 18:13
  • However, using an MVC pattern implicitely means you're going to "vendor-lock" your HTML, so it would be impossible to use another framework or toolkit. I mean, the view contains more than simple HTML elements, but some more complex things as well. A view has to be "interpreted" by the framework to be combined with the model so it represents the final user interface, take a look at AngularJS and its ng-markup, Ember.js with Handlebars or even Java frameworks like Spring MVC which uses JSTL. – g00glen00b Jul 01 '14 at 18:16
  • But I think we're both right in our own ways, which is probably the reason why this question got closed for being primarily opinion-based. ^^ – g00glen00b Jul 01 '14 at 18:17
  • Yes, that's why I said in 'theory' ;) It will be a nearly impossible task to do this in practice. In our architecture we are using the views as real views(only UI), but we program them in JS. @ your last comment, you are totally right :) – GuyT Jul 02 '14 at 06:16