I have been developing a application for 8 months now that has been utilizing Smarty for PHP templates.
I have had no problems at all with Smarty, and I have started to add more JavaScript interactions for the users on the site.
I was thinking of using backbone.js to template the JavaScript as well.
But another thought came to me, would it be bad idea to return a smarty template and load it in the div rather then return a json and use backbone.js to format the results?
Would this slow the application in anyway? What are the benefits (if any) and disadvantages to doing this?
Any thoughts would be great,
Thanks
With a normal multi-page "web site", users navigate from page to page consuming the site's features. Backbone however works best with a single-page "web application" model. With this approach, the only html page loaded is the first one; after that, every "page transition" is actually handled by Backbone's Router, which fakes page transitions dynamically via DOM manipulation. Each new page's elements are in turn built out of Backbone Views; PHP-generated html is never involved.
And that's why Backbone may not be the best fit for you. Unless you want to change your PHP code to be purely a server-side API-style structure (which wouldn't really need Smarty), much of Backbone's value is going to be lost.
Related
I'm choosing frameworks for my next project and got stuck on a tricky problem: How to share templates between server-side PHP and client-side Javascript?
On server, my application is going to be written in PHP, using Symfony, Twig, and MtHAML. I have few templates as an early GUI prototype and I really like HAML as it cuts my templates in half.
On client, I would like to use Vue.js or React or something like that (and say bye to jQuery spaghetti monsters). I haven't decided what to use here yet. I like ES6 class syntax. The client side is going to be a set of relatively simple SPAs — old-school standalone pages with some JS to make them more interactive. Therefore, there will be no routing nor manipulating browser history on client, but still, I want to update already loaded page here and there.
So, I will need to use templates at two places: server-side in PHP and client-side in Javascript. The question is, how to share one template on both sides?
I'm thinking about compiling the HAML templates with Dust.js/php (Mustache is too dumb) into Javascript or some similar aproach. Another way could be to render Vue templates from HAML (Gitlab does that) and somehow pre/post-process them into PHP templates. But I'm sure there were many people dealing with this problem too. Unfortunately, most resources on the Web are outdated or very messy. Is there some ready-to-use sollution?
I was solving similar problem before and the best solution for me became to use Symfony to build a decent API and then some js framework for frontend. Juggling with templates between two environments was a real pain. Maybe you'll choose different approach, just a suggestion from me...
Coming from non-JS html interpretation it's kind of hard for me to grasp the concept of loading server-side data to REACT.JS "view".
Let's say I've have a site built on Laravel (using routes). Each route request (e.g. "/", "contact") has it's own view. That view is loaded with data coming from a controller and displayed in the view. If I change the route I'll be redirected to another view and I'll get different data from a different controller.
Now the question. Let's say I have a simple site. Top part is my login information and maybe some notifications icon the content of the page changes with going to different sections of the web.
So If I keep using Laravel routes. Every page will be "re-rendered" + I'll have to manually select which components belong to that part of the site. I'll have to retrieve the information that stays the same from the whole web (e.g. login details + notification) again - this kills the react.js principle doesn't it?
Also, what is the best way to propagate server-site data to React.JS? Should I just "echo" out JSON object to the view and then "use" it in REACT?
Could I be pointed to some meaningful approach of how to use React.js along with PHP.
You mostly answered your question :-) With Laravel, the UI is rendered on the server. React is mostly interesting for client-side UI. That said, not everything can be done on the server, and some user interactions can only be managed by the browser. That is why jQuery became so successful in addition to PHP.
If your app deliver some complex client-side code, it could be usefull to build this code as React components, even if you keep your current server-side router: to make the code easier to maintain, but also to write - once familiar with React way of implementing things.
If you would like to transform your app to fully use React and a client-side router, that enable browsing the app without re-rendering at each page, this is called SPA (single page apps). The react ecosystem is pretty cool for building SPA. Usually, though, the server is just a static server delivering JS files, and the app connects to a REST API of some kind.
In some cases, routes can also be served from the server, for specific purposes:
Faster display of first page
Social Graph tags can be added to the specific page (to enable usable Facebook
or Twitter shares, for example)
Should you need to enable this server-side routing, which makes your app universal or isomorphic, you must use components that can be understood by both the browser and the server, this is why React app are usually served by Node.js, so everything is in Javascript.
Example tutorial about building a universal app with React https://medium.com/front-end-developers/handcrafting-an-isomorphic-redux-application-with-love-40ada4468af4#.h8p6lc23w (your intuition is right in this case, a JSON object with app current data is sent at first render)
Also check the awesome react page (https://github.com/enaqx/awesome-react) if you're interested in the React ecosystem.
Recap:
PHP + React: Easily add complex components to some pages, better to keep it that way if you just have a lot of static content, SEO, and just a few complex components on a single page that React can help you with.
React + API: Common SPA app, better for rich and complex UI, pretty easy to develop if starting from scratch and familiar with javascript, but complexity arise with performance management and SEO on large apps
Universal React: the best of both worlds, setup kinda complex (cf tutorial)
I am currently designing a website for a business. This website will have dynamic areas - such as an "admin" area in the future. But for now, there are going to be 14-16 static pages. Testimonials, products and services, typical corporate pages.
I really like the idea of loading html dynamically with backbone and doT.js. But for this purpose, am I better-served with a multiple-page approach? I've read that single-page designs can harm SEO but wasn't sure if that was still accurate. That is of major consideration for a basically fully static site where content is king.
Is SO a single-page site?
I am using apache2 with PHP/symfony2 for my current multi-page implementation for all of the static pages (and caching them).
It sounds like your site would be better off as static as possible. There's a lot of upside:
It should load quickly, because there's no processing to do, fewer files to load, and once it's sent to the browser you don't have to wait for the JavaScript to run before the page shows.
It will be more widely supported. Everything supports HTML; if your page loads require JavaScript, you might be cutting people off and never realise it.
Search engines will have a much easier time indexing static sites.
It's easier to develop and maintain a simple static site.
It's a lot harder to break. If your page loads require JavaScript and you accidentally deploy a broken script, you run the risk of completely blank pages. In a static site, chances are the text will still show.
Things like Backbone and JS templating are great when you're dealing with dynamic data. Backbone comes in to its own when you have objects that you're showing on a page, and want to build a complex interface to interact with them. But that doesn't sound like your page here. Similarly, JS templating is great if you're sending data to the page, maybe from an AJAX request, and want to render it client-side. But it doesn't sound like that's the case for this project.
In general, try to do the simplest thing that will work. Building the site as a static page will be a good starting point, and if you want to add JavaScript to it later you can build on that foundation.
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.
There are two ways to combine these frameworks:
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.
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.
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 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.
I just wondered if there is any existing framework or someone has experiences with using entirely static HTML templates that get filled with data provided via JSON from the server.
The HTML pages with JavaScript support should fulfill the role of the View whereas Controller and Model are handled by the PHP on the server side.
Views would the query via JSON-RPC or similar data from the Model and then render the results by manipulating the DOM.
I pretty much like this idea, it came into my mind weeks ago but I never found something on the web experiences with that or even already existing framework.
But maybe I am just a noob at googling?
Maybe one of you can help me out here.
Thanks in advance
Have a nice day!
Benjamin
This is very much possible and often found with Rich Client Applications. The first call to the application delivers the initial UI with any behavior defined in JavaScript files. Any further interaction is done via Ajax.
For the serverside, have a look at
Zend_Rest_Server
Zend_Json_Server
though this could just as well be a regular MVC application too. A Json or XML Response can still be considered a View. It's up to you to code your controllers to return appropriate data.
That's pretty much how Google do a lot of their stuff - do a view source on Gmail to see how much data they return in the HTML.
It's called Ajax. (That's not meant to sound too sarcastic - Ajax doesn't necessarily work like this, but ajax-based apps will do a lot of the rendering logic via JavaScript rather than via server-side code.)
You need a framework that doesn't limit you to any specific way of handling the view component of your MVC application and I think Zend Framework would be your best choice. It also has a great integration with DOJO and that makes it a lot easier to achieve what you need.