I'm relatively noob to the world of web developpement, and after learning the basics of HTML5/CSS3/JavaScript/jQuery I've started to learn AngularJS.
The problem is that as I am learning AngularJS, I don't understand what will be the point in learning a server-side language like PHP, it seems like AngularJS can do all the job (UI, views, routing, ...)
I think that the only reason would be to store data (but even that, I can use JSON files, no?)
and if it is, how much PHP do I need to learn? (or which parts of the language)
Thank you and sorry for my english.
Angular is a tool for a specific sort of job. It is not the tool for every job, and neither is PHP.
If you are writing an application that can live client-side, then you can certainly generate all of the dynamic components you need with Angular. There are many web applications out there that are entirely client-side. There are even more that function client-side and talk to a simple API server for their back-end.
If you are creating a web page that is not interactive, then there is little reason for something like Angular. There are benefits to having the DOM filled with content ahead of time. SEO is usually the biggest reason, but you might also consider clients that have disabled JavaScript (if you care about those).
Are you building something that is interactive? Consider a heavier client-side framework like Angular. Are you building a web page that is content-driven? Consider rendering your pages server-side. In the end, you will likely end up with a mix of both anyway.
A large consideration is security. Everything client side is exposed to the world. If the back end is just data storage without validation or protection except as written inside the client, a malicious user could push whatever data they wanted into your site. In addition if you are exposing code that is the core of a business inside the client, every user can see that as well.
Related
So I have a simple jQuery Mobile site interfacing with a MySQL database via PHP. Users orders are queried initially, then updated using the mobile web interface. I am not using any PHP framework, just 7 or 8 PHP files I've written for retrieving, updating, creating, and deleting order records.
As I begin to develop the Android and iOS applications, I realized it would be beneficial to have a PHP backend framework that can handle requests to create/read/update/delete my orders and users records from any of the 3 sources without caring which one it is. I want to create a layer of abstraction between the server side database handling and each of the 3 mobile interfaces. I envision being able to make a POST call from the client side, passing a TYPE argument and a JSON array of the data to a generic page like /myserver/mRequest.php, which would determine what to do based on TYPE and handle the processing, returning a STATUS variable and a JSON array of data back to the client.
Is there a good (preferably free) PHP framework that will help layout the backend? I've looked at Zend and a few others, but they seem pretty heavy and intended for desktop sites. I want to minimize the number of calls to the server as well as the amount of data thats sent back and forth (we all know how slow Verizon 3G is).
I'm hoping theres some lightweight framework out there that can be a skeleton for me to organize CRUD functions, check for null values, handle MySQL errors, etc...
If not, a guide to developing a PHP mobile backend would be the next best thing.
Note: I apologize it there is a thread already asking this, but I couldn't find one that I thought fit.
Almost any of the major free frameworks would do the trick, Symfony for example handles regular page templating for your jQM pages and handles ajax nicely too.
However, if you only require the framework for the AJAX handling and something broader, you might be advised to develop your simple scripts, with less effort and less of a learning curve (of course, the learning may be part and parcel of your plan).
Another option is a Data Abstraction layer between your scripts and your PHP, this would give you greater flexibility in terms of your data changes, but not burden you with a hefty framework in between. Propel and Doctrine are worth a look and are often used as part of web frameworks.
I personally really like CodeIgniter, which is a very clean and powerfull lightweight PHP framework with easy database-access.
Just have a look at it.
Greetings,
Steffen
I am working onr a backbone.js app, where one of my views is a complex feed with different types of subviews.
I will have to generate a static version of that view to be usd for email purposes. I am looking for the most practical solution that will allow me to reuse as much as I can from the existing code without duplication
I came up with two options:
Generate the view statically using php. This will men that I will have to duplicate a lot of the logic because of the different languages.
Set up a simple nodejs http server which will reuse most of the app logic to create a view on the server side. This sounds nice, but I am still unaware how practical such a solution will be in the long run. For ecample, I am completely unaware whether I would be able to use Jquery on the server side to create the layout from an existing html file.
Which one of he two options should I go for and why? Or perhaps there is a third one?
I debated a long time about this exact issue when I started working on my first backbone.js app, because like you I thought it would be a waste to duplicate so much view code. I'm working in rails, and my goal was to use the same format (haml) for partials on the server (haml/ruby) and templates on the client (haml/coffeescript), but that proved to be impossible and anyway not very advisable.
Anyway though, after having worked on the app for several months, I've come to the conclusion that the duplication is not a major issue. It certainly is not worth it trying to avoid duplication if the end result is only a couple of pages. Also, in my case at least, the static page I'm sending from the server did not end up having exactly the same structure as the templates that backbone.js renders, so it's not 100% duplication anyway.
Not sure if that helps, but in any case I'd suggest first duplicating the page and see how much extra work is actually involved. More complex solutions like #2 with the nodejs server strike me as overkill unless you'll really be serving a lot of pages this way.
For what it's worth, here are a few discussions of the topic on SO:
Rails Client side / Server side rendering using single template (handlebars or Mustache) with Sammy.js
Template language that works on both server and client
So I have decided to take a project I have been working on, and project management system, and convert it from a standard multi-paged application to a single-page application. In the process I have looked at a number of javascript MV*ish frameworks (ember, knockout, backbone, etc...) and have decided to go with backbone.js as it seems the most flexible solution and that I already use underscore.js for both its utilities and template system.
The one biggest concern I have with doing this is the potential code duplication I am going to have for model and business/domain logic in both my PHP models and in my backbone models.
This is just a technical cost I have pay when going with an architecture like this or are there some things I can do to lessen this concern?
You may want to take a look at a previous question I answered involving Node.js:
Reusing backbone views/routes on the server when using Backbone.js pushstate for seo/bookmarking
What I'm currently doing right now is using Davis.js + Mustache + Java Spring MVC backened (based on my original question: Single page Web App in Java framework or examples?).
If the browser does not support Pushstate then I have the server do the entire rendering of the page using a Java version of Mustache (ie standard Web 1.0). If the browser does support Pushstate then the browser will make an AJAX request for a JSON version of the model. The model is then rendered client side use icanhz (ie javascript mustache).
This works fairly well if a large part of your logic is getting a model an then rendering it based on specific URL. That is your business logic is "based on some URL I'm going to render this". This is how most of the sites on the web work (including this one which is still rather web 1.0). Obviously this would not work for say something like real time chat or HTML5 game.
A python version of this design is mentioned here: http://duganchen.ca/single-page-web-app-architecture-done-right/
I'm sure someone has done a PHP version.
If you are using different languages in server and in client I think there is not possibility to avoid this partial logic duplication you are concern on.
If you definitely want to use same code in server and client you have to move all of it to the only common language: JavaScript.
There are multiple JS frameworks those integrate very transparently the development between server and client: derby, meteor, ...
My question might not be understandable enough, so let me explain the situation :
I'm working on a big ajax webApp built, server side, with PHP using CodeIgniter. This framework saperates clearly models, controllers and views. The view files are rendered in HTML and then sent to the client that does some js treatments on it (like attaching events).
This way of working seems strange to me, as it separates the view between the server side and the client side.
I was thinking about moving all the View treatments to the client part that will build dynamically its html in js. The server side will then send only raw data.
I worked this way on smaller projects, and I was really happy with the result (easily understandable, portable and reusable).
Is it a right way to implement an MVC app ? Any advices around that reflexion ?
I've done pretty much what you are describing on a fairly large data services app as an internal application. In my case I was using ExtJS for the client-side rendering/views, and was communicating to a C# WCF endpoint exposed on the web server. Essentially requests were made/submitted and responses were serialized to/from JSON. It ran very smooth, once some kinks were worked out. The original author had written a custom serializer to do direct results from their data layer directly... this leads to a lot of extra data going down the pipe. As long as you are judicious with your payload data it can be very effective.
Some caveats though...
You should probably avoid this if you expect users without javascript enabled to be able to access the site (anything involving money transactions from external users).
You will want to document your methodology as clearly as possible.
Finding developers for maintenance tasks after you have implemented your application will be very difficult. (many server-side devs are shy of, scared of, or just plain inneffective with JS skills.
For the most part it's a toss up, I find that most people at least have JS enabled, but may have other things blocked off. AJAX/XmlHttpRequest supports is nearly universal at this point.
As to templating for client-side display, there are a few options there (but that's a separate discussion).
Building JavaScript views works fine within the MVC pattern, since your view is not mixed in with your business logic or model.
However, there are a couple drawbacks to using full javascript views. Mainly it eliminates the ability for graceful degradation if the client has javascript turned off. Also, some browsers (IE) don't have a very fast javascript engine, which will make your page load more slowly. It is true that some of the view is separated between the client and the server, but it kind of makes sense when you think about it.
In most cases the HTML that you send to clients is the same for everyone (unless you are doing browser detection on the server side). However the JavaScript routines are different. If you are using a library like JQuery, this will be hidden from you, but the code that is running on each client may differ greatly. One example of this would be the XMLHttpRequest that is used by firefox/webkit etc browser and the active x control that is used by IE. Since the html portion of the content is the same for everyone it makes sense to build on the server, and since the JavaScript portion of the view may differ, it make sense that it is built on the client side.
HTH
I started using the same approach: JavaScript for the user interface layer and PHP for the database access layer. I'm using AJAX to pass all the data back and forth between the 2 layers. So far, AJAX has occasionally frozen on me, but it has been speedy enough most of the time. So I guess it'll work well enough.
(The result is that my code has gone from 90% PHP with 10% JavaScript...to 65% JavaScript with 35% PHP.)
I've also separated the code for my page views from the code for my triggered event action functions. So I like to think that I have an MVC arrangement now (even though I'm not using an off-the-shelf MVC framework like Backbone.js).
I'm not using HTML templates, though. I don't think it feels natural to have 100% separation between HTML and programming. I think simple programming loops, conditional statements, and JavaScript triggers all go nicely with HTML.
If you will think it in the way that there is the main view that creates the html/js engine and couple of ajax views with the data streams - it will be quite OK in MVC terms imo.
Is there anything more dynamic going on on the site itself? Does it do more AJAXy things, dynamically refresh parts of the site etc.? If so, it may be reasonable to have a Javascript-only site.
Since this is not how the web traditionally works though, sending HTML from the server is still the baseline. If your pages are basically static, if you want to serve older clients, an audience that may have disabled Javascript, an audience that may have accessibility problems with Javascript-only pages, alternative clients that cannot understand Javascript or search engines, you should serve HTML pages from the server. There's nothing wrong with it, it's straight forward, simple and foolproof. There are many things to consider when reinventing the wheel in Javascript on the client side. Unless you have a good use for the potential this offers (see for example the highly dynamic Facebook or Twitter pages), it may be more trouble than it's worth to your users.
It sounds like you are one step away from going from the MVC pattern to the MVVM pattern.
MVVM is ideal for complex user interfaces (which is exactly what you would be creating with all the AJAX and JavaScript and whatnot) because in this case your HTML view will be able to act as the controller via JavaScript. There is a library (warning: I've never used it but it looks promising) for this called Knockout JS.
I've noticed that a PHP frameworks; Zend, Cake, and Symfony; seem to either generate JavaScript or allow it to be embedded as a string into the PHP itself. Is this a good idea? From people who've used these frameworks/libraries, what has been your experience working with the Ajax and JavaScript helpers? Has it been easy to maintain? Does it cut down on development time?
No it is a bad idea,
Generated javascript usually means that the site won't even function without it (like many asp.net sites). If you want to do more complex things or want to enhance accesibility there is no other way around than clearly seperating HTML from CSS and Javascript.
Seperating Javascript also makes your code more maintainable as you do not need to have your client side frontend developers mess with your PHP code and the other way around.
The best way to use Javascript is to first let php generate your html, then at the bottom of that page include your javascript files and use functionality like onDomReady. This also doesn't force you to use a particular library just because your framework is using that as base for its generated Javascript.
This is quite a subjective question, but personally, I wouldn't want a back-end framework to do this for me. It's better to keep a clean seperation between business logic, presentation, and client-side UI behaviours for a number of reasons:
More maintainable applications.
Easier to test individual components.
Easier collaboration. Different skill-sets can work on different areas.
Should help ensure your application does not rely on JavaScript in the end users environment.
Personally, I like to write my Javascript by hand, unobtrusively so that i just have to add an extra event to document.domReady with for example the correct parameters. That little trigger function then gets the ball rolling.
Best practice of the day:
Keep frontend-code and backend code
untangled as much as you can
I would say it depends, like anything. There is certainly some value in having "smart" server side widgets. For example, a widget that "knows" how to update itself through AJAX, or a form which can handle client side, and server side validation. The latter is an example of which it would be costly and time consuming and error prone to rewrite boring validation code in the client. It doesn't require rocket-science javascript, so as long as your framework can handle it unobtrusively, I would actually advise this route.
Additionally, framework code that will handle GUI stuff also (a la ext or something similar), is also not a bad a idea.
However, anything more complicated than that, please use Javascript itself.
I personally love writing my own Javascript so I don't really want it written for me, but I don't see it as being particularly 'dangerous' or 'harmful' to have frameworks that do it for you, as long as it is properly done. My biggest problem with them is that most of them will work as long as you want the standard behavior of a feature, but as soon as you want something a little different to meet your project's needs better it takes so much work to customize it you would have been better served to do it yourself. At least that was my experience with CakePHP's javascript automation.
My experience with the Javascript and Ajax helpers in CakePHP has been very positive.
They have allowed server-side developers to prototype and build features that otherwise would require someone with real client-side experience to do, all without having worry about the quality of the javascript code they "write" and leaving the real front-end engineers free to focus on the advanced client-side features.
It's not a good idea for the PHP to generate Javascript. The only javascript I would recommend exporting is simple JSON assignments like the following:
<script type="text/javascript"><!--
var MyNamespace.info = <?php echo json_encode($info_array) ?>
// --></script>
This is the easiest way to sanitize PHP information and let it be accessible to javascript on the client. However, anything else should be written in actual JAVASCRIPT FILES that are referenced with tags at the head of the document. The only other appearance of Javascript from server-side files, that I would say is alright, is stuff placed into "onclick" and other such attributes.
The rationale for this is that the Javascript should be written and maintained by front-end people who know Javascript, and the site should be able to work (at least partially) without javascript. There is no reason to generate spaghetti Javascript inline.
Check out my PHP framework, PHP On Pie (http://phponpie.com) for an example of how to implement this properly. It keeps the JS and PHP separate, except when exporting JSON as shown above. However it also provides conventions for easy interoperation between the client and server via AJAX.
I believe you should keep languages apart. Even though they can complement each other. That way you can pick the implementation of said language and create a mix that fits you perfect.
I think there is definitely a place for generated javascript. (1)
The number one reason for generated javascript is ease of maintenance. Any dependencies are explicitly encoded and configured from the framework (PHP, ruby, scala, python) itself. For instance if you move your assets or change the upload directory, just update the configuration and watch things Just Work.
Need client side input validation to take some load off your server? (2) Let the framework generate correct validation code derived directly from your data model for you. With generated, javascripted population your framework can serve pre-rendered, static HTML forms from the cache. This could be a huge win if your forms contain lots of selects and options.
1) Assuming that the client has decided that it's OK for the site to depend (more or less) on javascript, with all the caveats that entails. Graceful degradation may or may not be possible or desirable.
2) You need server side side validation too, but you knew that, right?