Al_B on 9/3/2011 at 08:11

---

I'm not an expert when it comes to the bleeding edge of web technologies. I tend to wait a little while until they're at least supported by most browsers. However, some thoughts on your questions:

Do you mean XHTML? If you're talking about the main content of your web pages then there's really no reason not to use HTML (4.01 or 5) - your web server will probably just serve them up as HTML anyway.

Where you might want to use XML is if you're processing data in your application, either by javascript (although you'd probably find json easier for simple data) or by your server programs (PHP / ASP.NET / Python or whatever you're using - if any)
It's a hot area at the moment and support is growing. One problem that I see is that as it's only internet explorer 9 that supports it - and that's only available on Vista and above there are significant number of people that won't be able to use parts of your website without work-arounds.

Ajax is just a way of using javascript to fetch information asynchronously - i.e. independently of the main page loading. The advantage is that you can fetch and display or process data without having to load a new web page. The disadvantage is that anyone with javascript turned off will not see the content.
There are a couple of frameworks that you might want to take a look at. (http://jquery.com/) jQuery makes cross-browser javascript support much easier and more concise and will also make AJAX interactions much easier too.

You haven't mentioned much in the way of server coding so not sure if you're planning on serving static pages. Do you have a particular website in mind?

SubJeff on 9/3/2011 at 22:38

---

Thanks for the feedback guys.

When I say XML or HTML I do mean XML, not XHTML. I thought it was possible to code pages just using XML now. If not then I'll stick to XHTML. It's a shame O'Reilly don't have an XHTML5 book, I found the HTML4 + CSS2 one really useful and it was how I learnt to code back in the day (along with their JavaScript book.

As to server side coding - I'd use PHP and mySQL. I don't have a particular site in mind but I'm looking at creating some stuff in the future. It'll mostly be related to the Android stuff I'm planning, but it's always nice to be using what is best especially if it opens doors to further development if need be.

I've read that HTML5 will be dropping the applet tag. Is there some new generic way to execute Java applets now?

SubJeff on 15/3/2011 at 00:51

---

So I should stick to HTML4 and slowly migrate to HTML5? That'll certainly make life easier I guess.

With regards to other tech - should I be using CSS2 or CSS3?

And what is the real advantage of jQuery over JavaScript? I don't really get why I should use it instead of just writing my own JavaScript.

FWIW I'm still gay for PHP when it comes to site wide stuff. I'm used to PHP5 and since I only use a limited section of it there's no reason to change this is there? I'm a fan of server side scripts because you can't turn them off (like JavaScript)?


Side note: I'm learning Java at the moment and it seems, so far, to be pretty much identical to JavaScript. The only difference I can see at the moment is it's strongly typed. All the programming constructs (statements, operators, loops, etc) are the same and methods and objects are called methods and objects (thank God). I haven't got onto functions yet but at this rate I'll be surprised if I read much that is news to me, and of course I'm happy about all this. Getting my head around Android apps is going to be much harder.

addink on 15/3/2011 at 08:48

---

EDIT: What Al_B said ^^

The advantage of jQuery is that it is browser independent, it consolidates most browser specific calls. Its true strength comes when writing larger javascript applications.

Also there's nothing wrong with PHP when used for standard website applications. Only when scaling up to seriously large loads or when requiring non-request based communication (persistent connections and such) does PHP fail to deliver. (Btw Java picks up where PHP drops off. And yes, jsp (java server pages) can do the same thing as PHP can, but if you're comfortable with PHP, why bother.)

On the topic of java v. javascript: Though the syntax is similar they are very different things indeed.
Java requires every aspect of an object to be defined, allows for class inheritance and provides access modifiers for class members, this allows for a much more robust way of developing and -with that- easier debugging and maintenance.
Javascript treats each and every object the same, though it does feature something resembling classes, in the end each object is simply a hashmap, easily adapted by adding or overwriting yet another untyped key-value pair. Though this might seem easier and quicker to develop when starting out, in the end it leads to a much harder to debug system in which typos simply become valid new members.

deathshadow on 29/3/2011 at 15:42

---

This is going to be a little long... But since I've retired from doing it into lecturing about it...

1) Ignore HTML 5 -- it's still in draft, and quite frankly is UNDOING the past decade worth of progress STRICT gave us. The new allegedly semantic tags seeming to exist solely for the purpose of placating the people who still sleaze out HTML 3.2 and just slap a tranny doctype on it. Realistically I would NOT try to deploy HTML 5 until sometime five to seven years from now when IE6/7/8 are a long-gone memory... and no throwing a javascript SHIV at the old browsers IS NOT the answer on that.

It's draft -- subject to change, nowhere near complete... so for now, unless you are doing it to learn what we might be able to deploy SOMEDAY, stay away from 5.

The most recent (if you can consider 12 years recent) version of HTML I recommend for development purposes is either HTML 4.01 STRICT or XHTML 1.0 STRICT. I prefer XHTML for the better structural rules -- which is the ONLY legitimate reason to use XHTML given that the whole "XML Application" nonsense of XHTML is basically stillborn and involves things better handled either server-side or in javascript.

2) In terms of CSS, version 3 is also still in draft, and with very VERY rare exceptions would I try to deploy ANY of it on a production website. That the ONLY browser to support the TRUE CSS3 properties is Opera and IE9, with gecko (firefox and pals) and webkit (Safari, chrome and friends) requiring the "for testing only, not for production websites" -moz and -webkit- prefixes that too is not ready for primetime. It's fun to learn, but I would NOT rely upon it for building a production website.

3) The only thing you can learn from jquery is how not to program javascript. It's also not jquery OR javascript, since jquery IS NOTHING MORE than a fat bloated convoluted steaming pile of manure javascript library. Here's a tip, giant library files of "gee ain't it neat" animated garbage and cryptic shortcuts are a REALLY BAD IDEA in an INTERPRETED programming language that's bandwidth restricted. 99% of the garbage done in jquery falls into three categories -- stupid animations that get in the way of actually using the page, stuff that CSS can do WITHOUT any scripting assistance, or things that shouldn't be done on a website in the first place.

... and in all three cases you can usually write a smaller/more efficient/faster javascript without it.

It's misusing technogies like specifications not even out of draft, daft scripting libraries like jquery or mootools, idiotic CSS frameworks like Grid960... or worse, combinations of all of the above like YUI that are why so many people are vomiting up 2 megabyte web pages built from hundreds of separate files, then sit there wondering why they have a 70%+ bounce rate. (Bounces are visitors who don't visit anything but the home page, or worse don't even wait for it to finish loading).

Really the technologies best used when starting out and even for larger sites hasn't changed in a decade, and aren't practical to change for professional production websites for another five to ten years! A decent LAMP server, HTML 4 and/or XHTML 1.0, STRICT not transitional, CSS 2, and some of 2.1 (which while still in draft, at least has semi-consistent cross-browser behaviors).

Going off on a tangent here, some advice for learning MODERN coding practices:

The BIGGEST thing I suggest learning is separation of presentation from content -- which is a return to the ORIGINAL PURPOSE of HTML; Saying what the content is NOT how it appears. On a properly written modern page appearance is CSS' job.

This means you have no business using all those tags and attributes STRICT deprecated -- CENTER, FONT, ALIGN -- that crap has NO PLACE IN YOUR MARKUP! Likewise, you shouldn't use classnames like "left", "right", "centered", "largeFont" etc -- as those TOO are presentational saying what things look like, NOT what they actually are. WHY is it left, what about it makes it have a larger font. Presentational classnames defeat the point of using CSS as all you'll have done is go from align="left" to style="left" -- COMPLETELY MISSING THE POINT.

Also keep in mind that semantic tags -- paragraphs around paragraphs, headings around headings, menus as unordered lists -- can mean less classes, and learn the difference between block-level and inline-level tags. SO many websites end up using tens of k for every k of actual content because people slap meaningless classes and extra DIV around EVERYTHING for no good reason. We have heading tags, what the devil do we need <div id="header"> for? We have UL's, what the devil do we need a <div id="nav"> around it for when we could just slap the ID on the menu... (and nav is a bit vague, how about calling it mainMenu so you can tell it apart from every other 'nav' on the page?)

Also, remember how headings are SUPPOSED to be used -- this is something people screw up all the time. The H1 is the heading under which ALL CONTENT ON THE PAGE should be treated as a subsection, which is why most good developers will tell you to only use ONE h1. Lower order (higher numbered) headings are by definition subsections of the heading before it -- which is why skipping numbers is considered bad practice. Don't just jump to H4

... and above all else, do NOT choose your tags just because of their default size and appearance. Choose them for what they MEAN... and do NOT just slap tags around things because they have a meaning as using the WRONG meaning on an element is as bad as having none at all. You see this all the time when people start putting multiple heading tags followed by paragraphs inside LI -- The heading tag is saying start of a new section, so saying it's a list-item is redundant/pointless. Good rule of thumb, if it has multiple block level containers, a LI is a waste of code.

DO NOT let the "never use tables" nimrods pump you full of their bull -- tables exist for a reason; tabular data. Tables are NOT deprecated and there is NOTHING WRONG with using tables for obviously tabular data -- and there's a hell of a lot wrong with using definition lists, unordered lists, and endless float tricks to replicate tabular formatting. The problem with tables is using them JUST for layouts when it's NOT tabular data. If you have obvious columns in obvious rows where the columns are a type of data and each row is like a record, go ahead and use a table. Spreadsheet, order form with columns of count, item, cost, shipping... that's tabular data.

If you just happen to have three unrelated columns as your page layout, don't use a table. That's when it's "tables for layout" and that's when it's "bad".

Also, do yourself a huge favor and familiarize yourself with ALL the tags before you start writing content. One of my favorite (and oldest) references is a great place to start.

(http://htmlhelp.com/reference/html40/)

I suggest the organizational list, and pay attention to the greyed out ones -- those are "deprecated" in modern markup and you have not business using them.

... and if you get stuck and have some heavy duty questions, go check out Sitepoint. I don't agree with a lot of their jquery for ninja's nonsense, but the forums have some insightful well informed people... and some total idiots too; what forum doesn't?

Some other things you should familiarize yourself with:
(http://www.w3.org/TR/CSS21/)
(http://www.w3.org/WAI/intro/wcag.php)

Oh, and some advice on tools... If you need ANYTHING more complex than a flat text editor, you've already screwed the pooch. To hell with nonsense like dreamweaver (only thing you can learn from Adobe is how not to build a website), frontpage, the artist formerly known as frontpage, anything with a WYSIWYG or even a preview pane is total rubbish and I've rarely if ever seen a well coded site built in them. Simple flat text editor should be ALL you need for getting the code done. I like Crimson Editor, but there's nothing wrong with editplus, notepad++, win32pad, gEdit (linsux), Text Wrangler (OSuX), hell if you're a masochist you could even use vim (aka command line geekery for those who like to spend more time configuring the editor than actually USING it to write code).

You want to see what it looks like, USE THE ACTUAL BROWSERS!!! In the age of Microsoft Virtual PC, VMWare, and my favorite Oracle VirtualBox there is NO EXCUSE for not being able to run a copy of XP with every version of IE from 5.01 through to 8 available, with 9 native under 7... likewise it's not THAT hard to run a copy of OSX under VirtualBox (iAtkos good as always) so you can check for the differences between windows Safari/Chrome/FF and Mac Safari/Chrome/FF... You'll find FF and Safari both being the worst behaved in that regard.

Ignore online "tools" like browsershots -- takes too long, you can't interact with it to test scripting, sizes or CSS behaviors, and quite often what they show bears no resemblance to what a native copy of the browser will do. It's not THAT hard to test multiple browsers locally (especially with virtualBox in "seamless" mode) -- I mean, is alt-tab F5 REALLY that hard to do?

Likewise I find it helps to run a server locally on your system for testing rather than uploading or trying to maintain code on a live site via FTP. Local copy, Live copy... equal but separate that way you can screw with the local copy and then update to the live copy. One of the best and easiest ways to do that is to just install XAMPP on your windows machine.

(http://www.apachefriends.org/en/xampp.html)

Another approach is to run Linux as the host and just install apache/php/mysql, running XP or 7 in VirtualBox or VMWare for testing. For me this isn't a choice as it hates my video hardware -- if I wanted a machine to run like it had a S3 Virge with no video accelleration JUST because I dare to try and run four displays, I'd have a S3 Virge and not a Ge560Ti sitting next to a GTX260 driving four displays.

For uploading, use filezilla -- SERIOUSLY. Do not trust the FTP built into some crappy IDE/RAD, do NOT waste your money on "smartFTP" or any other client. Filezilla is free, compatible, efficient -- What more do you need?

Oh, and I'd point out that all the fancy crap I say don't use costs $$$, boku $$$ unless you pirate -- but all the tools I'm saying to use (except perhaps a copy of XP -- what, can't find a dead laptop with a XP home sticker on the bottom?) are FREE.

Free flat text editors:
(http://www.crimsoneditor.com/)
(http://notepad-plus-plus.org/)
(http://www.editplus.com/)

Free FTP client:
(http://filezilla-project.org/)

Standalone copies of legacy IE versions that can run side-by-side on WinXP
(http://tredosoft.com/Multiple_IE)

You don't even need to waste $$$ on a graphics program.
(http://www.kanzelsberger.com/pixel/)
(http://www.gimp.org/)

Though if you are going to do this stuff seriously you should spend a few $$ on a paint program. **** Photoshop though, it wouldn't know image optimization if it stripped naked, painted itself purple and hopped up on a table to sing "oh look at what a well encoded .jpeg I am". My advice -- try Corel Paint Shop Pro...

(http://www.corel.com/servlet/Satellite/us/en/Product/1184951547051)

It's a tenth the price, I'd ballpark it as 95% as capable, it's compatible with photoshop plugins, and has a save-time image optimizer that blows anything ANY of its competitors have tried clear out of the water and into orbit. During save you can not only choose format, you can change color depth, encodings, set palette transparency, file format revision -- the list goes on and on.

Probably more than you wanted to know, but I figured every bit of info helps... You'll find I'm a bit opinionated on the subject.