The Web Stack
Published 14 years, 5 months pastFollowing on my “HTML5 vs. Flash” talk of a couple of weeks ago, I’m hoping to do a bit of blogging about HTML5, Flash, mobile apps, and more. But first I need to get some terminology straight.
As I did in my talk, I’m going to refer to the collection of front-end web-standards technologies — (X)HTML (of any flavor), CSS, and JavaScript — as “the web stack”. I’ve seen the term used here and there and it makes the most sense to me as a condensed verbal shorthand. It beats writing out the specific technologies every time or trying to use similarly clumsy constructions like “front-end tech”. If you like, think of “web stack” as a rough equivalent to “Ajax” — a term that was invented because continually saying “asynchronous JavaScript + CSS + DOM + XMLHttpRequest” was unworkable.
The web stack sort of includes downloadable fonts, but only in the same sense that images or any other external resource is part of the stack. SImilarly, it encompasses frameworks like jQuery in the sense that they’re built out of the components of the web stack.
When I use the term “web stack”, though, I’m not referring to back-end technologies. Those things are important, certainly, but not from the front-end point of view. A browser doesn’t care if your page was generated by PHP, Django, Rails, Perl, or what have you. It doesn’t even care if the server runs on Apache or something else.
Furthermore, it doesn’t refer to plugins. Yes, that means Flash, but it also means QuickTime, Real, ActiveX, and so forth. What I need to make clear is that I’m not doing this in an attempt to imply that plugins don’t belong on the web at all. They’re just not part of that core web stack any more than the web stack is part of them. That doesn’t stop them working together, obviously.
Okay, so that’s out of the way, and I hope my meaning is sufficiently clear to everyone. Please do leave a comment if it isn’t. Onward!