is it possible to use chaplin with meteor?
Any idea, advice, pointers or guidance is very welcome.
I am not familiar with Chaplin. But after having a look at its home page and 5 min intro reading. I understood that it is only client side, and its well-defined application architecture for backbone. so yes you can use that with Meteor, like backbone can be used with Meteor. (Have a look at Meteor packages, http://docs.meteor.com/#meteorlist backbone is already supported).
There will be few things, which may conflict with meteor features. i.e. Backbone support REST remote sync with server, and meteor provide their own collection management with server sync, but you can use either of it based on your requirement. so In short, yes it should be possible to use chaplin with meteor.
Related
AEM itself is self reliant WCMS and can be used to generate very rich digital experiences over multiple channels.
Often there is talk of using Angular as front end and moving AEM to backseat. What is point of doing so?
Using angular will add additional complexity and developer has to deal with it, increasing efforts for building system.
It will undermine core AEM features e.g. HTL & clientlibs
Multi channel experience can still be achieved without angular.
In short: there is no point in doing so when you deliver static pages, as seen in standard AEM use cases. It get's even worse: when you want to use AEM for dynamic pages, you might run into performance issues, so an external data source / index to query the "dynamic" data is almost mandatory.
I would recommend a clean separation of view and view-model using Sightly and Sling models which allow for a fast refactoring of views in case there is a good reason to migrate the frontend to a different technology / templating language.
And I am leaving out the fact that Angular will be basically replaced by Angular 2 and there are strong competitors like React, Ember etc...
AEM's core strengths are:
WYSIWYG
Multiple Adobe suite integration (analytics, target etc)
Authoring experience for MSM
Security integration from UI to db layer
There are many more strenghts along with many weaknesses. Using Angular or other similar platforms require AEM to be used as Content as a Service (CaaS) which isn't its primary strenght yet.
Organizations that invest in AEM are mostly after the core strenghts provided by it and won't normally benefit from using AEM as a CaaS platform. Unless Adobe provides plugin model for their integration suite that can work with mainstream front wnd technologies like Angular (2) and React, it would be a very uphill task for any team to get the most out of AEM suite without missing out on all the benefits provided (at a cost) by the whole of Adobe marketing suite.
In short, from TcO perspective, these platforms are not easily compatible with AEM due to the unique nature of product which means the integration is normally a challenge and sometimes counter productive when integration benefits of the core platform are compromised.
I believe it totally depends on the use case. I have done projects with AEM using jQuery and others using Angular. If developer knows what he/she is doing, adding angular is not much of a hassle. 2 way data binding, a clean way of doing Ajax and ease of Single Page Application, that pretty much sums it up. Works really well..
Angular and other front-end frameworks provide the additional benefit of SPA which if integrated the right way with AEM can work wonders!
Yes, I agree that integration is an uphill task but the page load times can reduce significantly and using features like routing we can reduce the server calls for transition across the site pages.
Why AEM-Angular integration can be a good thing?
AEM can be used as a CaaS platform in few cases where the content will primarily be loaded using SPA. In other cases, components can be a mix of HTL and Angular where HTL can provide additional security using proper context.
You can pass AEM authored content to Angular directives/components as attributes and perform the desired functionality.
Angular can be used to build reusable components and directives on the front-end which can simply be reused across AEM components.
The Angular dependencies can be made a part of the AEM client library and this ensures that Angular functionality works as expected.
Build tools like Maven and Ant are powerful enough to support the integration. Simple tasks have to be written in pom.xml.
AEM 6.4 Beta has support for front-end frameworks and I have observed how fast the content load can be!
Other AEM integrations (Adobe Target, Adobe Campaign, Adobe Analytics) can be still leveraged in similar ways as before.
Did I forget JQuery? Angular and other front-end frameworks will provide cleaner and more efficient ways of doing the same things in JQuery.
The decision to use both will totally depend on the use case and this is not recommended for all solutions though.
I have worked on AEM for more than a year. In my project, the stack was AEM, jQuery, and some 3rd party library to handle JS relevant issues(like IE support and util functions).
If you want to integrate Angular then I see the below things from your query
Good :
You don't need the headache of java related issues.
No need for more backend developers(though I am a backend developer).
If you do want to change some files in stage or prod environment, no need to go with java change directly package installation will work.
You can leverage angular strategies to build your project efficiently.
No need to worry about your project optimization. Angular will take care of JS library optimization and loading into client-side browser.
No need worry for page speed issues from google audit for your websites. That will be taken care of by Angular.
You will be able to achieve the hybrid model of clientlib and can avoid lot's of Js issues along with clientlib comes in to picture.
Testing of components will be easier.
AEM also follows Component similar to angular, so things can be merged based on good architecture.
Not Good:
sightly syntax might be underutilized.
Still, there will be cases you have to dependent on java for achieving some features.
Security issues need to be fixed as everything will be done on the client-side.
more issues if you are using etc/map related URLs.
more complexity if you follow SEO optimization standards.
More dispatcher configurations.
Needs to habituate aem structure with angular structure.
AEM structure will be more complex when merged with angular
I am quite new to Angular. I have written this answer based on my experience. I will keep updating if any edits required.
Using AEM as an integration layer is a challenging decision. AEM is a content management system and works well for static content (content is cached at Dispatcher layer).
However, it use the Jetty server under the hood. Jetty uses thread pools for handling requests. It means that when the number of users increases, it use more and more resources. The situation is the same for time-consuming operations - think about API's unavailability or delays.
Instead of using AEM as an integration layer, you delegate this integration logic to more reactive systems such as Knot.x. Then AEM may serve only static pages (templates), Knot.x would fill all required data from external APIs.
See more here.
Both angular and laravel are great frameworks meant for slightly different purposes. Since they achieve to do similar things like -
They both focus on an MVC-inspired application structure, and each of them support a different directory structure by default
They both offer templating engines of their own, with conflicting syntax (which can be changed of course)
They both offer DOM iterators ( php foreach vs ng-repeat )
And many more similar conflicts
Since they are so similar in philosophy, isn't it redundant (and even conflicting sometimes) to develop a web app which uses both these frameworks?
Since each of them are so powerful in themselves, would it be a good idea to mix both? How common is the combined use of these in real world websites?
Am I better off using angular with basic PHP instead, if say, I was developing a medium scale web service (5000+ users)
What are some of the other backend+frontend framework combinations which are symbiotic and most frequently used?
Yes they can do similar things, but they don't have to.
Of course it doesn't make much sense to use the same feature of both of the frameworks. Meaning if you choose to use AngularJS for templating you don't need Laravel's views. But that's nothing you should worry about. If you don't use it, you don't use it. The fact that you don't use the entire functionality of a framework shouldn't have any bad impact on your application.
But note: Be consistent
Don't render one view with Laravel and use AngularJS for the other.
Recommendation
I personally have made good experiences with Laravel as a RESTful API and AngularJS taking care of the rest. So AngularJS is doing all the frontend stuff and communicates with Laravel only via JSON.
Is it possible to run AngularJS in a Durandal project? We are using Durandal now but want to move to AngularJS while still keep the site operational. Is it even a good idea to attempt this?
Any suggestion would be greatly appreciated.
You could run them side-by-side, but then you would just have two separate SPAs hosted on the same site. The doesn't seem like a good upgrade strategy to me. I think you would be better off to fully develop the new version and then replace the site altogether.
I would also advise that you wait for the release of AngularJS 2.0 (if possible). Rob Eisenberg has announced that he is currently working with the AngularJS team to provide core changes and plugins that will make Angular 2.0 more familiar to developers with Durandal experience, as well as to provide a migration path from Durandal to Angular 2.0.
The other answer isn't exactly correct. I have an example that proves it wrong.
Durandal is a module loader that can load any view / view model pair. If you choose to load an angular application and leave out the router portion it works just fine. It really isn't that difficult to get it set up.
Wrap your Angular.js application initialization code in an AMD module (view model) with a matching view and it just works.
Does it make sense having a solution that uses both Freemarker and AngularJS?
I tried to convince everyone on my team of switching to Angular, and a more experienced developer than me pointed out that he prefers server-side rendering, which is both arguable and valid. But then he told me that if I still want to use Angular just use it with Freemarker instead of replacing it.
I'm a junior programmer, as far as I can understand they are designed to the same purpose.
It depends on the needs.
For example, if you want to break your page into individual re-usable components that you can tie based on some logic on the server side, then using freemarker or velocity for building these components makes sense.
The freemarker or velocity templates might in-turn use angularJS components that would be rendered on the browser and evaluated on the client side.
The server side templating would give you the ability to design re-usable angular components.
Now, some may try to use the Object component in HTML5 for doing the same thing, but this is not recommended as using Object expects a fully formed HTML element with its own <html> opening and closing tag.
Not something that is intended for a small reusable component.
As an example consider having your page header and footer in its own html template file that you would like to tie in for all the pages in your application.
As I google for Freemarker i realize it is just a templating engine. AngularJS is not a templating engine. Templating engine is just part within this framework. So both of them cannot be compared.
AngularJS is a full fledged framework for creating Single Page Applications (SPA). So if you want just templating capabilities on client side, i suggest you better look for some other light weight libraries.
If you want to use AngularJS you need to decide
Whether you can structure your app as a SPA
Does the site needs to be SEO optimized. Which has limited support in Angular or as a matter of fact in any client side framework.
Ready to use the AngularJS templating engine because it is awesome with its support for oneway\two way active bindings. If you don't use it templating engine you are loosing a lot.
No it clearly does not make sense as they serve very different purposes. All I can think of is that you either misunderstood the more experienced developer or he really has not understood the business case (WHY something is worth using) of using either technology. In my experience as a j2ee developer, I find that many server side developers (experienced or not) may not be too educated on the many new advances recently made in client side development. With Angular you are not limited to SPA. You need an insight into the overall architecture of your current project to determine if its a good fit. There are ways around the SEO issues or you can purchase an SEO solution. But clearly not a best choice if SEO is essential.
Unless it is a team decision and there are clear problems Angular solves for you, I would not suggest getting stuck alone with a new technology that only you know. Keep it as a hobby and when you really understand the best practices and benefits you can then try being an evangelist.
I am considering using AngularJS instead of Handlebars with MeteorJS. I am more familiar with AngularJS, but it doesn't work well out-of-the-box with Meteor. Handlebars is default templating engine used in MeteorJS.
I would like to know the trade-off between the two, e.g., whether AngularJS provides more flexible front-end coding than Handlebars.
My question is: when pairing with Meteor, what AngularJS can do that Handlebars can not in terms of front-end programming?
(Note that people love AngularJS in part b/c of its two-way binding and data model, but Meteor-Handlebars do these very well too).
Update: Please do not vote to close this question if you think it is a duplicate of another question in SO that compares Angular and Handlebars. Meteor added significant power to Handlebars due to its "database on client" approach.
Angular and Meteor can be combined, and it's a pretty neat combo. Angular's templating system and its two-way bindings (DOM to JS model) can even be made to go the whole way and be kept in sync with a Meteor collection. Such a pairing of Angular and Meteor means you get instantaneous DOM to database syncing, which is very cool. Angular can't do that by itself, nor can Meteor (without writing more or less tedious event handlers) and even less Handlebars.
The angular-meteor Meteor package is pretty much ngMeteor's successor (it builds on ngMeteor code) and integrates Meteor collections with Angular models, the two templating systems, Meteor Session variables etc.
TL;DR: Meteor works best with packages (think jQuery, bootstrap, d3, underscore, stylus, less) since they enhance a framework. Those same packages would enhance Angular too (well, kind of). Angular is an end-to-end framework, so trying to integrate it on top of another end-to-end framework like Meteor is a recipe for headaches.
Handlebars has very similar expressions and bindings that you're probably familiar with in Angular. But while the templating engine is similar, it's the rest of the frameworks that differ greatly.
Angular leans heavily on its internal directives (ng-repeat, ng-form, ng-bind, etc.) to easily tie in javascript (i.e. power) to your markup. There's a lot of magic behind the scenes.
Meteor leans heavily on the pub/sub model and connecting to your true data stores. Their secret sauce comes from easily adding but abstracting packages (handlebars is one of their default packages, but some others are bootstrap, accounts-ui, d3, etc.).
Meteor follows very different ideologies and has different opinions on framework design than Angular does. In my opinion, Meteor's are superior though the project is still in its relative infancy. You'll find that Meteor is really, really good at prototyping quickly, especially if you need to tie in user support and want to use Twitter/Facebook/Google.
You'd be better off choosing one or the other, but if you're not strong on the server side, you could write a pretty slick Meteor app to just act as your API server.
If you want to use angularjs with meteor you can just install a package that does that. Then you can use both meteor and angular.
Meteor is realy nice for getting your data from server to client, angular is very nice in getting that data displayed (and stable).
mrt add angular-stack
or
mrt add ngMeteor
Generally speaking, AngularJS has passed the version 1.0 milestone and is considered ready for production use while meteor is still alpha software. Consequently, Angular is more polished, has directives, modules and rich third-party libraries like AngularUI.
But if you feel like experimenting with a bleeding-edge framework, don't think you'll have to do super-fancy templating-stuff but need a database built in, go with Meteor!
I think you might find this answer helpful.
Also I think it might be a duplicated question.