if one wants to make a website that acts like a desktop software, isnt it better to just use one page and use ajax to retrieve all other php-files and update the content of current page with eg. jquery?
i mean, just ONE page, you get the idea of my question i think...
is this to recommend? what is the pros and cons?
i mean, its really smooth!
That's how Meebo, Gmail, etc. do it, so there are clearly legitimate use cases. Do note that they have versions that work without JavaScript, to avoid losing audience...
It can work well to an extent, butONE page is 1 (or several) steps to far, it depends on the application.The main drawbacks are page history (forward/back) and bookmarking, both can be sidetracked.
It depends on your application. If accessibility or SEO are considerations at all, you should rely on AJAX only for enhancing the user experience in capable browsers.
First of all you should not create web apps that act just like desktop software (use Flash or Silverlight if you really need to) but design you application in a way that is suitable for the web.
However when creating web applications using AJAX is a good practice as it makes better user experience. It can also simplify the development as you can clearly separate the user interface from the functionality. You can use something like this http://yensdesign.com/2008/11/creating-ajax-websites-based-on-anchor-navigation/ to overcome forward/backward and bookmarking issues. The one big CON is that users without JS (many mobile browsers, but not only) won't be able to use your application.
#fayer, sure, you can create such a "single-page application". IMHO there's nothing wrong in using standard web technologies to create browser-based apps that look and feel like native desktop apps. The browser merely becomes a runtime in this case, you may additionally also consider using browser-based runtimes like Adobe AIR or Titanium.
Starting from scratch or only with a low-level library like jQuery it is not trivial (if not impossible) to develop, deploy and maintain larger desktop-like web applications, but with a proper framework it can be straightforward and fun: have a look at qooxdoo, http://qooxdoo.org , a mature open source JS framework which addresses all those RIA requirements. To get the idea of a large-scale qooxdoo app, check out the free webmailer http://gmx.com (think of "Outlook in a browser").
Related
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.
I want to try creating a canvas were multiple users can type and edit for brainstorming etc. I am thinking of php as backend. What are the technique used for it? For example, lets say its
pure text. How do we update the text like in the google wave(b4) and in google doc?
Is it just using websocket(or js pooling) and updating the text file? or are there any
better logical way to solve this issue?
Well, its not as easy as it is said in Brad's answer but he is partially right. You will definitely need WebSockets today to make it happen. But logically, it is not that simple to create a collaborative environment. There are issues like broadcasting changes of every user to every other user viewing the same document. Then you will have to make sure that every user gets to see exactly the same thing no matter who changes what and when. This gets difficult when multiple users are working on the same document collaboratively. There can be conflicts while merging changes of one another.
As far as PHP is concerned, language is not really a problem. Its how you handle the above stated problem.
Google released its research and engineering details on Google Wave (I guess after abandoning the project). This link might be some help to you: http://www.waveprotocol.org/whitepapers/
Websockets are the way to go for this. However, they are difficult to implement in PHP, and not supported by many browsers as of yet. You can do long-polling of AJAX requests pretty easily with PHP, but it can be quite a waste of resources.
This might not be what you are looking for, but I'd suggest changing your server-side technology. You can use Node.js with Socket.IO to easily use Websockets (or seemlessly emulate them for browsers that don't support them). This will provide the fastest method for pushing data to your users.
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.
For the last couple of days, I have been on a jQuery frenzy literally designing everything using this wonderful library. I am planning to design a web-based social game (for deployment on social networks like Facebook) from scratch and would like some pointers on understanding how to divide the tasks i.e. to what extent should jQuery be used. Following are my thoughts. Please let me know if I am heading in the right direction.
I am envisioning the game to be a simple multiplayer game where users can compete with each other and gain points (and the game is more like role-based or static rather than a dynamic mario style game). For this most of the points-logic and book keeping should be done on the server side using PHP and MySQL. For client side rendering, I am planning to use jQuery (and have no plans of taking the Flash route). So all the interactions will be handled on the client side using jQuery and the state will be saved on the server.
Now, this is a very naive process but I was wondering if there are any resources that explain the above in more detailed steps i.e. from the perspective of designing an actual game from a multiplayer perspective keeping scalability in mind. I don't need a very complex game... even a simple Q&A game will suffice to boost my understanding of how to actually use these languages to create a good enough game. Any suggestions? Also, is it recommended to use a gaming engine when doing the game in jQuery?
Seems possible. It depends on the type of game, I'm making a 2D RPG. Although the client is for Android, I've built the editor using jQuery. There are existing game jQuery libraries you may want to look at.
Try to use the jQuery UI toolkit as much as possible. They'll make your life much easier. Specially things like Dialog.
How are you going to communicate with your server? If you need something with good speed and low latency, use websockets. (Though less browsers support it.)
Otherwise, you'll want to design your server side code in a REST style. That way you can on the browser you can use $.ajax with it's simplicity.
I don't know much about PHP because I don't use it. But if your game is not realtime you can certainly make something scalable with it. I think Zynga uses PHP for their games.
All in all, I can definetly vouch for jQuery when it comes to this. Specially if it's logic driven you can easily make a social game with it.
Also, this is optional. Make your html pages use the jQuery UI theme classes wherever possible so that the pages look good with the jQuery widgets.
Check out the screenshots at the end of my blogpost here: http://developingthedream.blogspot.com/2010/10/player-map-making-in-browser.html
jQuery shines when it comes to DOM manipulation and operations. As far as using it to power a scalable online multiplayer game...I don't know that it was built with that in mind. You might want to look at processingJS.
I'm starting to architect a quite complex web application. The implementation is probably going to be done in PHP, though if there are impressive reasons to choose a different environment I might be convinced.
I've looked at tools like Symfony and CakePHP. The problem is that it feels like they're relatively low level for a modern Web 2.0 application. They handle the basic things like MVC and scaffolding, but not the more advanced UI elements that I'm looking for. Here are some of my requirements:
Single page architecture. With minor exceptions, there should be no page refresh. All actions are done via ajax, the way it's done in gmail, and to a lesser extent in Facebook.
Ajax layout and widget handling. Not only the application doesn't refresh the page, but the developer can specify the layout and load various widgets into different parts of the page. This is somewhat like iGoogle, but should be better integrated.
Support both on the client side and server side for AJAX widgets. It should be trivial to display the result of a select statement in an AJAX table/array like http://developer.yahoo.com/yui/datatable/. This should also apply to other widgets including
Trees
Menus
Forms
Speaking of forms, there should be easy integration with client side validation
Signup/Authentication/Authorization. Including all the housekeeping things like forgot my password, CAPTCHAs, etc.
There's more, but I think I've given enough details so that you get an idea for what I'm looking for. Basically, I'd like to engineer a modern Web 2.0 app and skip writing, testing, debugging things that most web applications need to do. And yes, I know I can take YUI or jQuery and slap it on top of one of the regular platforms, but then I'd have to write all the glue. Now if there are modules that do this, that would be interesting.
So if you say, take Symfony + modules xyz + jQuery and there's your answer, I'd be happy to hear that.
Finally, in terms of priority, I'm looking for something that's scalable, reliable, well engineered more than something that's easy to learn and deploy.
Since you are looking for all things AJAX, why not try GWT? Its not PHP I agree, but it makes writing AJAX applications easy for developers.
I agree with #Iznogood. What your looking for is not actually a framework but a talent.You can make any framework as "igoogle-ish" as possible if you know what your doing.
I suggest look for a framework with a huge and active community like, CI, Cake and Jquery. Search/ask the community for the specific things you need. Plug it in and Presto!
But I'm afraid you'll have to write some of it.
If you don't mind using Java, there is ZK:
http://www.zkoss.org/
I'd prefer using this over GWT.
In php, you might want to consider Cjax http://cjax.sourceforge.net/.
It is MVC oriented, and has a very generic API, with full support for customization, including the development of plugins (There is a full Plugin API available, including documentation, Plugins can be built in PHP and JavaScript in combination -- see uploadify and validate plugins).
It can access all JavaScript functions, Objects and proprieties, and elements properties and functions from PHP server side, with one line of code.
In Cjax,
you can execute ajax actions, inside controllers (ajax requests) - without a line of JavaScript. this allows you to fully function without refreshing the page. It also allows you to access all Js objects from PHP. A good sample that reflects this is the "recursive ajax request" see that demo. The API can be used on page load, when the page first loads, and within every single ajax request.
Do take a look at the documentation and to the 20+ demos included, and no where you will see a single line of JavaScript. It allows you to manipulate elements, containers, request ajax, submit ajax forms, creates overlays, upload files through ajax, all from the server side. Take a glace at the API Table.
It has support for both, server side ajax, and client side, (see plugins JavaScript Documentation)
It plays nice with jQuery - the validation plugin in jquery is full executable in PHP without a line of JavaScript (see http://cjax.sourceforge.net/examples/plugin_validate.php without any custom line of Jquery inside the framework, it's all plugin's work). Ajax Responses from Jquery also get processed by this framework automatically, so using Jquery's Ajax function API wise, is the same as if you were using the Framework's Plugin's JavaScript Ajax Functions.
And you would just have to take your time learning more about it, because it has quite a few more tools that I am sure you'd find useful.
Currently there are two official releases, the generic release and
there is an official release for CodeIgnater of this framework (and it is the leading ajax option for codeignater) , and works great in conjunction other PHP Frameworks and without them.
Signup/Authentication/Authorization. Including all the housekeeping
things like forgot my password, CAPTCHAs, etc.
This is something that you can build within an ajax controller, the framework itself its meant to be a generic "AJAX" framework, so if you are looking for none ajax features, you will need to build them or integrate other PHP Framework with Cjax (such as Codeignater).
I do not know if this matches all of your criteria, or if you ever will find one. However, I like the Zend Framework myself.
As for the UI and AJAX portions - the server side technology matters little, and it's more about browser-side technology and interaction mechanisms, as well as DOM manipulation.
jQuery is my favorite for that. As for the PHP back-end, I tend to develop it with my own codebase that's grown with me over the years.
But all this takes a lot of practice, knowledge, education, research, reading, and posting questions on StackOverflow.com ;)
I would recommend symfony PHP framework since it has very good support for every feature you mentioned, and it can be easily integrated with Zend Framework - as of version 2.0 coming this year it would be integrated in the package. You can easily set symfony to handle AJAX requests so that it would be perfect transparent layer handling server side.
For me, if you look at THAT heavy AJAX, I would recommend searching for some good JavaScript framework - such as Ext.JS - that would handle all client side functionalities.
For the front-end part of your app, you might want to have a look at SproutCore ( http://www.sproutcore.com/ ).
Building a Web application with SproutCore feels more like configuring components than writing code.
There is no glue code.
On the backend all you have to do is accept and emit JSON.
Depends what sort of level you're looking at. If by 'framework' you mean something like Zend or Symphony, then to be honest all the big ones are about as good as each other. They all have strong points and weak points, but none will really meet your criteria.
But your question implies you're looking for something more than that kind of framework. Maybe you're looking for a full-blown CMS platform like Drupal, Joomla or Wordpress?
In that case, again, you need to consider your needs verses the capabilities and pitfalls of each system.
Drupal, for example, has masses of modules, is very powerful, and easy to write your own modules, but isn't object-oriented and doesn't really do MVC, so if that's your bag then you may find it hard to get on with. Wordpress is much easier to get going quickly but is less flexible once you start getting deeper into it.
But again, they all have strengths and weaknesses. If one was clearly the best, it would be an easy choice. But at the end of day perhaps it's better to have several good quality options to choose from.
Have a look at Ext JS, it is pretty good. If it is a commercial project you are doing it isn't free but not too expensive either. It also has a GWT version if you prefer that.
This is only for the front end but it is not too complicated to use any backend that can emit json.
CakePHP is pretty good