This question is a bit of a shot in the dark and Im not even sure it makes sense at all.
Still : Im quite used to the good ol' LAMP server design but tend to feel I could use some good push technology instead of the very inefficient repeated AJAX calls to pull new data, if any. Is there any way to achieve this without Java servlets (ie using Apache/PHP) ? Is HTML5 giving any hope for a step in that direction ?
I looked into Comet technology but it looks like it's just long-polling AJAX, which is just faking a push technology (I don't really know but it doesnt sound like an efficient way to do push... just a way that works).
I'd suggest reading this: http://today.java.net/article/2010/04/26/html5-server-push-technologies-part-2 as an introduction to HTML5 web sockets and http://www.indicthreads.com/1525/building-real-time-web-applications-using-html-5-web-sockets/. Further Google searches will yield a lot more info. This looks like the way to do push in the most capable browsers as it has advantages over the altenative pre-HTML5 technologies.
As for PHP being the server end point, here's some reading: http://code.google.com/p/phpwebsocket/ and http://www.murraypicton.com/2010/07/websockets-and-php/ and it sure look possible.
The disadvantage of using HTML5 websockets is that it's only supported in some browsers so if you want wide cross-browser support, you will also have to implement an alternate method.
Related
I've pretty much set my mind on using CreateJS to create an HTML5 game, but I also came across H5CGB, a boilerplate created specifically for creating HTML5 canvas games. It looks very thorough and I believe the developer when he says it would save me heaps of time writing code I would have had to write anyway.
However, looking at tutorials for both CreateJS and H5CGB, they seem to conflict quite a bit, at least in terms of how these specific tutorials implement their respective tools:
http://hub.tutsplus.com/tutorials/learn-createjs-by-building-an-html5-pong-game--active-11845
http://icecreamyou.github.io/HTML5-Canvas-Game-Boilerplate/docs/#!/guide/walkthrough
I'm basically just trying to understand how to integrate these two systems. For example, both come with their own preloader utility, so I'm not sure which to use and if they would cause issues or if it's just a redundancy resulting in unnecessarily longer loading times.
Has anyone had any experience working with these two tools together?
I believe you should probably just stick to using createJS because the two frameworks do have a lot of overlapping functionality. It wouldn't make sense to use both.
I think you should also check out other game specific frameworks like Crafty.js and possibly watch Google I/O Canvas to get a good idea on the total range of your options!
Crafty
http://craftyjs.com/
Google I/O
http://blog.sethladd.com/2011/05/source-code-slides-and-video-for-html5.html
Hope this helps and good luck learning canvas!
Shalom
I created H5CGB. (Just found this question today via the newly-released Github traffic stats.)
The biggest two reasons to use H5CGB are:
You do not have to learn any new APIs to start developing. H5CGB provides a bunch of scaffolding you can use to skip the boring stuff, but you won't get into trouble if you want to implement any part of your app yourself, and you probably can get going immediately just by editing main.js without even reading the documentation.
The code base is intended to be boilerplate, so you can use all the utilities and scaffolding H5CGB provides as a starting point and edit it if you want things to work differently.
This is in contrast to most other canvas libraries, which tend to be monolithic black boxes of no-touchiness with sparsely documented APIs.
I'm thinking of writing a realtime web app that would need to be able to push messages to the browser. When I first read about Comet, people seemed to consider it a brittle and immature approach due to weak browser support. Today, it seems to be an established and practical technique. But as far as I know, browers don't support the basic methods (long polling, iframes and script tags) any better now than they did in '06 when the idea first became popular.
Of course, it's difficult to manage all of those connections on the server side, but Comet frameworks solve that problem (and it was doable even back in '06 with something like Twisted). So what's the deal: are there any deal-breaking problems with Comet support in browsers, or were the people back then just wrong?
Also: I recently read a ~2010 blog post summarizing the state of Comet technology, covering each method in detail. It made it sound like none of the methods were really viable. The post was very persuasive, which is why I'm still edgy about Comet. The only thing I can remember about the blog is that it had a dark background (brown or black). Has anyone else seen that post? I'd really like to read it again.
I would argue that comet is very viable right now, every browser supports long polling so you have a common fallback that will still work, and there are methods in each browser that will be more performant than long polling.
You just don't see it very often because its quite a big undertaking to support the different methods in each browser, google and facebook have the resources to do it, but your average joe web dev. would be wasting a lot of time for very little gain. There are only so many applications where you really need the real time communication comet provides.
I think now with frameworks like APE and cometD that give you the backend and the client side utilities you are seeing more people able to take on the complicated tasks. It can't be immature anyway, comet is just a technique that uses existing capabilities in a very novel way.
I don't think that the browsers have changed much with respect to comet everything remains as it was a few years ago. With all of its hackiness intact. WebSockets will be the eventual answer so browser makers are in no hurry to fix commet, but that "standard" is still in flux.
I'm looking to implement drag & drop in MSIE (must be, a bonus for other browsers, but just "nice to have").
I'm looking at a sort of drawing package - let's say flowcharts for example. The user can drag flowchart elements from a palette and position them in the browser. When complete, I will need to know the type and position of each element, probably some other data too.
Can this be done? If so, what's the most powerful technology to do so? HTML 5? Ajax? JS? Something else?
Short version: I would recommend JQuery UI (A javascript framework), this will make your life easier. As for other components, you are free to stack it up from server-side to client-side components depending on your needs and most of the times depending on your preferences.
[update] The long version: Personally, if I would start a useful website with a back-end, I would use Java as my PL of choice since I'm familiar with it, SQL for my persistence, and make it a Web 2.0 site, like what you want to achieve which is a rich internet application (drag and drop, dynamic content, etc). I would normally make use of Java (JSP, Servlets) but use Grails framework (Groovy, GSP, Groovlets), SQL DB (like MySQL, SqlLite, etc), Ajax, HTML, CSS, Javascript (JQuery as my JS framework). Eclipse would be my IDE to program and integrate all of these components.
Some people would prefer to use Python, others PHP, some .NET, Ruby on Rails, etc. Like what I said, it is very subjective. If you already have a field of expertise, then I suggest you stick with it, but if you are starting from scratch, it's basically a choice of the easiest learning curve for you because different Programming Languages can and will satisfy your needs.
For the front-end you have Flash, Applets / JavaFX, Javascript, etc. The problems with Flash, Applets or other embedded media are 1) heavy on resources 2) compatibility, but the clear advantage is that they are more robust because you can do so much more with these technologies in arguably a smaller amount of time. But if you want to use one of these, you have to seriously think about your target audience e.g. for Flash, iPad and iPhones cannot display them at all (except if you installed the unofficial "frash" which supports a bit of flash content).
I believe what you want to do is highly feasible even if you just use Javascript, and again, I will strongly recommend that you use a framework that can readily satisfy your needs (like drag and drop) so that 1) you'd worry less about cross-browser compatibilities, 2) you won't have to reimplement them and 3) fix many unexpected bugs along the way. But this is the general idea if you are developing a software, if the framework or library already exists, use it (just be extra careful with licensing though but this is another topic) :)
disclaimer: rum + coke = awesome
use javascript, that's all you should need to have drag n drop for elements. for example : http://flowchart.com/demo/
This question has a discussion of progressive enhancement. My question is about the alternative type of web application. If you have a web app in which the UI is constructed almost entirely in Javascript, won't gracefully degrade, has a desktop feel, etc., what is that kind of web application called?
Do you mean this type or the opposite of this type:
"Rich Internet Application" where you could have an application that runs on for example AIR.
to me, what you describe seems to be a JavaScript based fat client ... i see nothing wrong in that ...
the thing is, that everyone forgets is that HTML means hypertext markup language ... it is a format for describing documents and was never designed to capture the functionality that some HTML-based apps offer nowadays ...
the answer "RIA" seems the best to me ... of course that includes flash and silverlight ... but your choice of HTML+JS is completely arbitrary in this case, because you manipulate the HTML DocumentObjectModel with JavaScript as a flash developer would manipulate the flash DisplayObjectModel with ActionScript ...
there are simply web apps, that are document and form based ... they have a CRUD infrastructure for some type of data, that is accessed in a RESTful, or at least RESTish way ... this type of apps can employ progressive enhancement, using HTML to capture its semantics and plain HTTP for all client<->server communication... i'd tend to simply call this kind of web app a web site ... having a bit of funky AJAX won't change that really ... i mean, from a simple guest book, to a forum, to stackoverflow, the basic idea never changes ... and a guest book does not make a web application, does it?
there are web apps, where the state is fully maintained by a much richer client, because these apps do a lot of granular data manipulation, as opposed to the document based CRUD web apps, and to me, this is the type of web application actually deserving the name, but i'd call them RIAs, to emphasize the difference ... in some cases this solution is faster, more lightweight, scalable, usable, easier and faster to develop/maintain/extend, and simply more natural ... this choice is often based on the type of data they deal with, as well as the functionality exposed for manipulating that data ... for example, if you were to implement a game like tetris, progressive enhancement wouldn't be the way to go ... instead, in order to create such apps, willful misuse of HTML is required ... so what? :-D
so, yeah, RIA is the right word, i'd say ... and opposed to others, i think first of all, it is a great, easy and powerful way of deploying functionality ... i mean i get the whole "inaccessible" and "incrawlable" thing ... but the latter is often pointless, and the first one is a problem you can't address properly, unless for example screen readers read whatever is in the DOM, instead of spitting out the original page ... but that's the problem you face with "real", i.e. desktop like, apps ...
greetz
back2dos
Monolithic?
Well, really the opposite of "progressive enhancement" is "graceful degradation", even though they basically achieve the same thing.
Progressive enhancement means you start off with plain old HTML for older browsers, then enhance it in stages, with cross-browser CSS, additional CSS (e.g. CSS3 styles), Javascript and AJAX.
Graceful degradation means you rush headlong into creating a Rich Internet Experience, then tack on alternatives for people without Javascript/CSS.
Anyway to answer your question, I'd probably call it "ungraceful degradation". Alternatives:
Badly designed
Uncrawlable (from search engine perspective)
Inaccessible (credit: Chuck)
Inaccessible.
It just doesn't degrade well.
I'm not sure I'd categorise applications as progessively enhanced, because that inferrs that there is some sort of baseline. How far back should an app degrade before it's considered as 'progressively enhanced'?
At a push, I'd say the app is dependant on certain features of the browser - maybe it is 'edge dependant' or 'modern browser only'?
UI is constructed almost entirely in Javascript, won't gracefully degrade
Arrogant. Presumptive. Illegal (depending on specifics of application and jurisdiction).
I'm a .NET guy desktop developer, and I love that. I don't really love web development because we lost precious time to debug CSS, javascript, and compatibility stuff instead of creating value.
But I think it's because I had not taken time to learn about good web development practices, so now because I want to become the best developer that I can, I'd like to learn about my weakness.
Can you give me some advices/links/patterns/frameworks to become a good web developer ? (I am a .NET guy so I accept everything that will permit me to develop better websites in .NET).
Thanks !
Precision
I have done a lot of ASP.NET webform in the past, but this is not enough to create great web site without loosing time on compatibility/css/javascript issue.
You could take a shortcut and use ASP.NET, which provides a number of controls to make web development easier - and you'll be familiar using them.
Unfortunately, they aren't really that great (imo) and do not teach you good practices with the web.
I suggest you look into ASP MVC, which is now in beta. This will teach you how to write websites whilst allowing you to use libraries you are familiar with .NET
With general web development, look into websites like W3schools which will teach you the basics.
Remember to seperate presentation from markup with CSS and make sure you are using javascript to add value to a page, but make sure your page is still usable without it.
You will always lose time with CSS compatability issues, all I can say is with practice you learn what pitfalls to avoid so it gets a little easier.
As for javascript development, it has improved considerably in the past few years with frameworks which in theory are cross-browser. Maybe try looking into JQuery which syncs well with ASP MVC and has intellisense in visual studio
Advices:
Best advice I can give to you: Just don`t get angry when you done something correct but it wont show as you wanted. Patience! :)
Links:
www.w3schools.com
Nettuts.com
Webappers.com
Digital Point - webmasters forum
Patterns:
My advice is to get more into MVC pattern and any enterprise pattern.
Frameworks:
Just see this link :) Framework Guide
For Javascript: JQuery,Prototype,Mootools,EXTJs
For CSS: 960 grid system is pretty good
Make sure you learn about the client/browser side as well.
Current best practice with all the different browsers around is to use a javascript library to make your web-application cross platform and cross-browser. An AJAX library like jQuery or Prototype to perform the interactive actions you wouldn't be able to do with standard HTML and CSS in the pre-AJAX era.