30

I recently started to build a large social network, and and I thought my structure was good but it turned out I built this logic up badly.

I mixed my views with AngularJS (bad idea), skipped blade extension, but since I'm using a lot of block and sidebar includes it became a pain in the butt.

Currently I am just handling form validations with angular, but actually all of my site pages will require ajax, data pulling, etc.

I was searching around the net and I saw that angular views are stored in the public folder, but since all my pages will use angular is it a good idea to store all my views in the public, and just use Laravel as a back end?

I know this is a silly question but I'm confused a bit.

Any help hint appreciated.

Dominic Tancredi
  • 41,134
  • 7
  • 34
  • 50
  • 1
    I think , as you use ng-view to render partials , and definitely will use factory yo pull datas ,that point of time $http are into consideration , and definitely that time you will use some validation to pull datas from laravel . I think as Angular Itself a MV* framework , do u need laravel to define another route!check http://stackoverflow.com/questions/15623967/should-i-mix-angularjs-with-a-php-framework – Niladri Das Aug 24 '13 at 15:50

3 Answers3

20

There are two ways to combine these frameworks:

  1. Only client-side rendering

    This is the easier way and used by most web applications. In this case you would use Laravel as an API endpoint which will return JSON. Angular can query this data through its $http or $resource service and compile the templates, which you store in the public folder. Angular templates are just HTML with directives and some {{var}} statements. This way Angular does all the routing too.

  2. Server-side and client-side rendering

    This is the harder way where Laravel would do the routing and compile some templates on the server-side. You would use Angular only for some interactions on the site in a way you would use jQuery for example. The benefit of this approach is performance as users will get the full HTML the first time they visit your site. The disadvantage is that you may have to write some logic twice and can’t use some of Angular’s features.

Max Hoffmann
  • 2,957
  • 1
  • 17
  • 13
  • 7
    I recommend for resolving the "writing logic twice" you can explore the "Repository pattern", which means two controllers (one for API, the other for server-side templating) and they can both use a Repository to act as intermediary to the database layer. I'm using #2 as the architecture for my own site. There's an internal "single-page application" (SPA) which uses client-side rendering. The fallback is server-side rendering, for the static pages, and some user management areas. – Dominic Tancredi Oct 06 '13 at 18:01
  • @Maximilian Hoffmann which of these options is best when SEO is very much considered? – Emeka Mbah Jun 08 '15 at 10:10
  • 1
    @Digitlimit No one knows how exactly Google’s search algorithm works and will change in the future. What Google is publicly sharing though is that performance has become a factor for a website’s score. As sending server-side rendered HTML is faster for first-time visits I’d recommend the second way to avoid a penalty for bad performance. With React server-side rendering is much easier than with Angular btw. – Max Hoffmann Jun 09 '15 at 11:11
13

To actually benefit from most of angular's features you should write a Single Page Application. This means you will communicate with the server through web APIs and you won't have any Laravel server-side templates.

So yes, you should write two decoupled applications. One client-side, using Angular and one server-side that exposes a web API, preferably RESTful.

This way you could switch from JS/HTML/CSS on the client side to Flash or Silverlight or something else and from Laravel/PHP/MySQL to .NET or NodeJS or Meteor/MongoDB.

Sergiu Paraschiv
  • 9,929
  • 5
  • 36
  • 47
6

Sergiu is correct, but in some cases Laravel still offers benefits that cannot be achieved with client-side templates. This is related to SEO and WCAG (accessibility).

AngularJS renders content by way of DOM manipulation so search engines cannot determine what content is shown after those manipulations are complete. This is also the case for screen readers. For this reason some content must be delivered by way of server-side view constructs. That is why Wordpress and Laravel have long and healthy futures.

On the back-end or in cases where SEO and WCAG are not important, data binding client side templates such as those used with AngularJS and Ember will be used increasingly as more developers learn how to use them.

In terms of whether to use AngularJS or Laravel for view constructs it would be best to learn how to use both and apply where most appropriate.

Peter Drinnan
  • 4,344
  • 1
  • 36
  • 29
  • 4
    I'm more inclined to think server-side JavaScript (like NodeJS) is the future, where you write a single codebase for your whole app but run it in two contexts: the browser for regular users and the server for crawlers. But yes, this is a real problem right now. – Sergiu Paraschiv Dec 20 '13 at 09:24
  • Three years later. We now have React (and others) with isomorphic rendering as a good solution. – Sergiu Paraschiv Jun 30 '16 at 09:58