I'm already familiar with Knockout, Angular, Sammy, jQuery, a little breeze, and a little ember. The tutorials and getting started for Durandal all seem to be saying... well first add jQuery and maybe knockout.
Does it handle something entirely different than all of these?
What need does it address such that it is likely to be used with knockout?
Is it just a hodgepodge of client side routing and ui components?
What does it do on its own conceptually?
Durandal is similar to Angular in that it provides a MV* framework for client-side SPA web applications.
Angular is mostly, if not all, custom code, whereas Durandal takes existing libraries, mainly Knockout and RequireJS (Sammy dependency has been obviated with the 2.0 release), and provides the plumbing to provide full SPA functionality, including view/view model composition and hash-tag (spa) navigation.
As for Knockout, Durandal relies heavily on Knockout to compose the views and view models. Your view and view model are automatically data-bound when the view is injected into the DOM. The advantage to this is that I can use Knockout to provide the V/VM data-binding, and let Durandal do the work of figuring out which v/vm to use, retrieving it from the server, and composing it into the current screen.
Restated, Durandal provides a way to map views/view models to hash-tag based routes, which give you the SPA navigation. By specifying a shell, or layout, view as the main view, a placeholder can be added which Durandal uses to implement what is basically a "screen presenter" pattern. Durandal listens to the URL changes, and can automatically activate, data-bind (using Knockout), and display the view that matches the current URL route.
If you're familiar with WPF, you may think of Durandal as providing Prism-like functionality as its main offering, along with other goodies designed to support building single-page-applications for the web.
Durandal has several benefits, but also builds on existing libraries. It has a dependency on
RequireJS
Knockout
jQuery
These are not "maybes." They are hard dependencies. Durandal cannot work without them.
At it's core, Durandal add's the very powerful compose binding to knockout. This binding will automatically locate the view (an HTML file) when passed a viewmodel, retrieve it from the server, bind it to the viewmodel, and insert them into the DOM. Similar behavior can be achieved using the knockout template binding, but managing the templates can become cumbersome. Composition also adds lifecycle events to the process, which can help ensure that viewmodels are setup and torn-down correctly. It also provides optional DOM caching.
Durandal also provides some framework structure. It provides a simple plugin API, which is used by its router to give SPA navigation via hash or push-state. It encourages the organization of viewmodels and views by overridable convention, as well as the use of Require AMD modules. It also provides a simple event module to allow application wide events to be created and consumed.
Durandal is a "full featured" SPA framework, whereas Knockout is just data-binding. It is similar in scope to Angular.
Magento 2 stand on Knockout and RequireJS.
Durandal can be added on top of it so more possibility come with use latest features (components, templates etc).
It is better because:
it is more stable and major than other framework, less errors occur
great documentation
simple api
more SEO friendly! (you can have all html seved and use it like component, mixed situation). Angular 2 stand on mixing logic with presentation.
html5 standard data and binding with better code redability (just try read html in react)
still maintained
creator of Durandal was for some time Angular Developer (3 month) so there is some similarity going on there in thinking.
Work in old browser ! (IE6 >)
There also cons but mainly because it don't give so much function in one pack and not newly, cutting edge technology, was adopted.
Pleas share more point about Durandal :)
More there: https://johnpapa.net/compare-durandal-to-angular-not-knockout-to-angular/
Related
I am intending to build a fairly comprehensive (read: complex) search form using razor pages in a dotnet core webapp. One of the features of this page will (I intend) be live/dynamic updates (search results refresh as search parameters are typed/chosen) and that the displayed browser URL is updated to reflect the search parameters as they are changed.
In order to prepare for this I've been looking for documentation on how to build this page and it seems to me that while Razor pages are easy (fun?) to build for basic page designs, having dynamic (read: partially refreshed) components requires the use of more basic (read: not framework supported) JavaScript.
While I have found articles like this which document how to do the 'live update' I'm not sure if this is really the best approach.
I don't know if frameworks like VueJS (which would be the alternative option, due to in-house skill set) make dynamic/live updating of the browser URL any easier (by virtue of their framework features).
Does VueJS, though it is more front-end heavy, provide a stronger platform for developing a live/dynamic refreshed page than Razor pages or am I simply missing some fundamental (perhaps too easy?) feature of Razor pages which provides for quick/easy development of dynamic, partial page updates?
Angular 2+ offers Modules (NgModule)s that "configure the injector and the compiler and help organize related things together." They are another layer of code organization, to facilitate modularity of parts of large scale applications.
I am NOT talking about Node modules. Angular has those too. NgModule is unrelated to that.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule. Searching for this information was not fruitful on search engines. Is there anything? Or does Vue.js in some way make them not necessary?
They are another layer of code organization, to facilitate modularity of parts of large scale applications.
No, ngModule is the only way the Angular ahead-of-time compiler can discover, walk and tree shake providers that are not required for the project. This includes things like components, directives, services, etc that you would define in modules.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule.
You shouldn't because this is an Angular specific feature. Vue has no dependency injection or lazy loading as a core feature.
Or does Vue.js in some way make them not necessary?
You might be confusing Angular NgModules with JavaScript modules. The two are not the same, because Angular uses NgModules to make it's dependency injection system work. Without the DI there really is no need for NgModule. Angular would then work the same way Vue and React work, and use the JavaScript import to resolve dependencies.
Angular is an opinionated (I don't mean that as a negative) and monolithic framework. It uses ngModules for organization. They are a benefit by default. Vue is a progressive framework that allows you to include as much or as little as you want.
Vue Plugins allow for mass registration of components if you need it, but you can just as easily narrow your dependency tree using explicit import/export statements.
Vue Bootstrap has a Vue Plugin mechanism that allows you to include all of the features outright including the custom elements it provides but also allows you to import each component individually if that is what you want.
Angular Powered Bootstrap provides an ngModule in much the same way but also allows you to include components piecemeal if you want.
The key thing here is that Vue tries to be as non-opinionated as possible and lets you configure how you want dependencies included whereas Angular wants you to do everything its way. Neither way is outright better than the other. You benefit from knowing how do to things by default with the opinionated way vs having way too many choices with the non-opinionated way.
Consider this question, how do you perform network requests with each of these frameworks? The answer is obvious for Angular: HttpClient. However, you can use whatever request library you want in Vue, be it fetch, axios, jQuery.get() or anything else as long as you appropriately deal with Vue's reactivity model. You can likely do the same thing in Angular, but you're going outside of Angular's suggested approach.
You likely don't see a lot of documentation about comparable things to ngModule because Vue doesn't really push for organization in that manner. Again, not a judgement, it's just a difference in how the frameworks are intended.
I've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!
I've been recently experimenting with one of the widely recommended MVC client-side frameworks (Backbone, in this case). I find it quite nice, but I have an issue with it: suppose I'm building a list of contents, which I want to present on browsers using client-side rendering, but also want to make available for search engines, which do not run javascript. That means, I'll also have to render stuff on the server-side. Now, let's say I'm using Handlebars.js, whose template language is inherited from mustache. All is well. But on the server, I'm using ERB (or HAML, whatever). That means, I'll have to support more than one version of the same template. Which is just unmaintainable, for cases where your templates going beyond the list-element 4 lines of code. How are the big platforms working around this issue?
I'm looking into porting an existing enterprise app to iPad. One of the key requirements is that there is a basic functioning app that needs to be highly customizable/extensible. Also, the people working on the customizations and extensions are not part of the product team and do not have access to the base product's code (only interfaces, docs and the binaries). To achieve this, the current application uses a component based architecture where well defined components are used to compose the UI. For a given customer any of these components can be either extended and used instead of the out of the box ones or simply swapped with a new component that adheres to the interface.
Are there libraries in cocoa-touch that support a component model architecture ? (composing the app through a registry/configuration that can easily edited by others than the team developers)
Sebi
Perhaps you can create a root view controller and inject polymorphic children with: https://github.com/jasperblues/Typhoon