What is a "vanilla web interface"? - terminology

Someone told me to look into "vanilla web interface". I have Googled it, but didn't find any relevant result, at least that was I thought. What is it?

The term "vanilla" usually refers to something that's plain and unadorned (from vanilla ice-cream) or perhaps simple (as in basic), so they're asking you to look into a "simple web interface" without any unnecessary complications.

Considering the Vanilla software entry on wikipedia, which states (quoting) :
Vanilla software is computer software
that is not customized from its
delivered form - i.e. it is used
without any customizations applied to
it. Vanilla software can become a
widespread de facto industry standard,
widely used by businesses and
individuals.
I'm guessing "Vanilla Web interface" corresponds to the default interface of a web application, not customized or anything.

They mean web 1.0 interface, usually just text and tables, sometimes CSS.

Related

Guides for UI designers working in Google Web Toolkit

Can anyone point me to a useful guide for UI designers working in google web toolkit?
As per my comment to bhargava's answer, your designers should be learning UiBinder. The whole chapter about building user interfaces seems appropriate too (to get a better perspective), but UiBinder is what they will be mostly dealing with. Without using UiBinder in your project, you are stuck with Java and that's not something your designers are likely to know (and are probably not keen to :)).
I'd recommend building a simple example (but not too simple - maybe you should "strip" the official mail example) that uses UiBinder and show the designers exactly what you expect them to provide and what should be left as stubs. It all depends on the designers in question - whether all they know is HTML and CSS or maybe they have experience with Java, etc. Tailor the example to your needs - you probably won't "get it right" the first time, but with feedback from the designers (what's hard to understand, what they think should be the responsibility of the programmer, etc.), you should arrive at a good learning tool for future employees and a reference for current ones :)
Well if you're looking on how to use widgets and panels in gwt then i would recommend Roughian Examples
This website provides us the basic usage of the GWT widgets and panels and provides us with enough information just to get things started.

Why shouldn't professional web developers use Microsoft FrontPage?

I have a workmate with access to a very good IDE. He wants to use Microsoft FrontPage to write his jsps.
I know exactly what I want to say to him, but what would you say? I need a concise reason why a professional web app developer would never consider FrontPage.
It's an unnecessary abstraction for professional web developers, who need very tight control over the HTML and CSS generated.
It would be like rally car drivers using an automatic transmission. They need to know exactly what their car is going to do, and web developers need to know exactly how their code is going to act.
#1 reason:
FrontPage was discontinued in late 2006.
Personally, it bugs me seeing the extra bloat (unnecessary HTML structure, non-semantic use of HTML tags, embedding CSS directly in HTML) that Frontpage generates. I also dislike use of proprietary, non-standard HTML and CSS. Frontpage's code bloat is bad enough to have inspired such programs as Frontpage Code Cleaner. Here's another Stack Overflow question that deals with removing Frontpage bloat: FrontPage tags - Pain in da HTML.
You might also check out Why I do not use Frontpage by Greg Moreno.
Frontpage leads to bad habits for some of the same reasons Sarah Vessels lists. I used to use it myself. I was one of those who liked to design in design mode and refine in HTML. The problem was that switching between "design" and "html" views would cause FrontPage to change my precious HTML. And at some point I got fed up with it destroying my markup (something the newer tools are better about not doing).
When I began hand coding every site I worked on from scratch I learned so much more about HTML and CSS in general and how to make lightweight, efficient pages. And at that point I also realized that the markup FrontPage would generate was really old-fashioned with lots of tables and inline CSS. As I learned to do it right I also learned how to make my sites cross-browser compatible on the first try. In the end this allows me to design and build a better site, faster.
Professional web developers should really avoid Frontpage and use Microsoft Expression Web instead. It's the replacement for Frontpage and is fairly good, actually.
Frontpage itself has been discontinued. Using it simply as an HTML editor with syntax highlighting is a bit silly given how heavyweight it is.
That being said, if he's producing good code and delivering on time, it doesn't really matter what he uses.
It's intentionally dumbed-down
Great web developers build sites that:
Look good in all browsers
Degrade gracefully when Javascript or CSS or a plugin is not available
Have semantic HTML that makes sense to screen readers
Use AJAX, content compression, and caching to minimize bandwidth use
Have lovely, pixel-perfect graphics
If any GUI can do all that reliably, great. But I haven't seen it yet. And by the time you build one, the competition will be hand-coding capabilities that the GUI doesn't know about yet.
For one, FP isn't really supported anymore. The FP extensions honestly suck, they break quite often on the server side. But just as HTML editor, when the latest FP version is used and the settings are right (correct browser version and no server-side FP extensions), it's quite OK.
However (if staying on MS products), I'd rather use Visual Web Developer 2008 (o1 2010 when it gets out), it's free and has more recent technological support.
This is going off topic, but when FrontPage first came out, it was groundbreaking in how easy it was to create websites at a time when the web designer title was nowhere near fruition, but of course, FP has (de)volved into producing bloat.
The original company that created it was named Vermeer, after the Dutch painter and the story of how FP was built and how Vermeer got bought out by Microsoft is an interesting read, giving you insight into startups and Microsoft buyout tactics back then.
The same person who founded the company produced the movie, "No End in Sight", a documentary about the escalation into Iraq. Interesting segue, from software company to documentary movies.
Anyways, I think the name is Charles Ferguson. You can probably find a used version of the book on the cheap in Amazon. Definitely a worthwhile trip in the way back machine.
Because it's supposed to be catered to the crowd that isn't familiar at all with web development, mostly novices. To an experienced web developer it's fairly restrictive and limited, as is any WYSIWYG editor.
I haven't used it lately, but it used to rewrite a file with it's own garbage, even if you didn't save the file.
The same reason a professional artist doesn't use a coloring book. You're being paid to bring your skill and expertise into creating a product — using only FrontPage is essentially shirking that duty. I'm not saying it's never OK to touch it, but you need to take responsibility for the code you ultimately produce.
I personally haven't used Frontpage all that much, but I feel that you should really learn to use HTML and CSS and not rely on an application to do it for you. You really learn how things work and you have more control over what goes on.
It's Microsoft's
...the same company that brought you IE 6. I bet your site will work with IE 6, but will it work with Safari and Firefox and Opera equally well?
And if it doesn't, what are you going to do about it? You didn't want to dig into the code, remember?
Frontpage produces terrible code that won't be maintainable by other developers not using frontpage, meaning almost all web developers with common sense - especially since Frontpage got discontinued.
As mentioned - FrontPage became Expression Web. I hated FrontPage, but I think Expression Web is fantastic. I'm a programmer with deliverables, I don't have time to mess arround writing HTML code myself.
I suppose it depends what market your friend is in. If he wants to make shiny, glossed up websites with custom features & CSS - use a HTML/CSS syntax editor.
If he just wants to make quick, nice looking, clean corporate sites and have a high turn-over of generic sites, Expression Web is great. (The HTML isn't very 'pure' thought - but honestly what client would care?)

Why HTML/JavaScript/CSS are not compiled languages and will they ever be?

Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?
I can see a few challenges:
What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.
How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.
How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.
But what about benefits:
Speed.
Size.
No more "loose" and "half-correct" html. It is either correct or won't compile.
Looks the same in every (supported) browser.
If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.
As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)
But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...
Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.
The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.
More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).
On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.
Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!
http://code.google.com/apis/v8/design.html
We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.
http://code.google.com/p/minify/
In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.
Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.
The V8 javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.
Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.
That said, if you're really keen on pushing machine code to the client, try out nativeclient (as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).
See here for a previous discussion on the matter
Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.
Ken
Speed.
You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.
No more "loose" and "half-correct" html. It is either correct or won't compile.
You already get that, using [X]HTML.
Looks the same in every (supported) browser.
You seem to be saying that there should only be one browser, or that all browsers would support it equally.
Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:
Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
Some people haven't yet developed something that is standard (i.e. they're behind of the standard)
I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.
Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
CSS
CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.

What is the semantic web, and why would I want to use it?

Just like it reads.
The simplest and shortest explanation that I have found is: "The Semantic Web is to Machines what the World Wide Web is to Humans".
And as to why you would want that: for the same reasons why you let your Machine compute Pi to the quadrillionth digit instead of doing that yourself. So you can focus on interesting problems and leave the menial work to the Machine.
Well, it might not be fitting in with the "official" definition, but I always try and explain it to people as "It's like syndicating knowledge instead of content."
Why would you want to use it? Well... if you are making applications that could benefit from machine parseable and queryable "knowledge," then... you might want to use it :).
IMHO it's rather ill-defined and not implemented in a broadly useful way at present. It's a good idea and I have no doubt things will tend towards this sort of approach in the future, but it's not there yet.
From wikipedia:
The Semantic Web is an evolving
extension of the World Wide Web in
which the semantics of information and
services on the web is defined, making
it possible for the web to understand
and satisfy the requests of people and
machines to use the web content. It
derives from World Wide Web Consortium
director Sir Tim Berners-Lee's vision
of the Web as a universal medium for
data, information, and knowledge
exchange.

What is a good non-WYSIWYG editor for HTML?

I don't like WYIWYG editors, I want to be responsible for the selection and placement of each tag and attribute! Is there a good editor out there that allows you complete control over the HTML but offers useful features such as:
syntax highlighting (of course)
suggestions of tags, attributes etc. e.g. as dropdown lists
validation and accessibility checking
previewing the HTML
Currently I use TextPad with syntax highlighting, but feel I could do better.
I'm a big fan of Aptana for generic HTML/CSS/Javascript editing. Based on Eclipse, but nicer usability. Automatic formatting, code suggestion (with native support for jQuery & ExtJs) and embedded browser tabs for checking your work.
It's also cross-platform, supports Windows Mac & Linux.
I like Notepad++; it doesn't have embedded preview, but it's lightweight, has a good UI, syntax-highlights reliably...
Microsoft Visual Studio 2008 might suit your needs (and there's a free download "express" version).
Others have mentioned Visual Studio and HTML Kit. You might also consider DreamWeaver or Microsoft Expression Web. Technically, both of these (and even Visual Studio) have WYSIWYG modes, but they also offer split source/WYSIWYG and total source-only modes. All have validation, standards checking and the whole nine. All allow complete control over code with no fuss nor muss, if that's what you want. Expression and DreamWeaver support syntax highlighting for more than just HTML/ASP; both also support PHP natively.
Here's a link to Visual Web Developer Express (the free Visual Studio Brian mentioned).
I really like Coda on the Mac http://www.panic.com/coda/.
HTMLKit is reasonably decent and free.
I really like Microsoft Expression Web 2.0 or Microsoft SharePoint Designer 2007, depending on my needs.
Specifically, Microsoft Expression Web 2.0 supports development of the basics (HTML, CSS, etc.) while including Intellisense for ASP.NET and PHP.
Microsoft SharePoint Designer 2007 includes support for SharePoint Services and MOSS.
I've heard people say that they like Dreamweaver, but it's a little on the bloated side for my taste. Both the tools I mentioned above allow for WYSIWYG editing, but they support all the features you listed as well. They also allow for doctype support and validation for accessibility, etc.
I recommend Programmer's Notepad for lightweight code editing, but then I'm biased :)
To be fair, these are all also good for the same:
Notepad++,
SciTE,
Notepad2.
None of these (including PN) do the big extras you're asking for with previews and the like, however. For those features you need something more full featured like the already recommended and excellent Expression Web or perhaps even Visual Web Developer.
I should point out also that there are loads of editor discussions on SO already:
https://stackoverflow.com/search?q=html+editor
I still use an old version (4.0) of Homesite and it does just about all I want and need. It was originally written by Nick Bradbury and was not too heavy, had just the right set of features, and was very popular.
Nick sold Homesite to Allaire and then it was eaten by bigger and bigger fish. But it is still maintained and now being sold alongside Dreamweaver as a text-based HTML alternative by Macromedia (and now Adobe).
They charge $99 USD for it.
I would have upgraded, but they only have upgrade pricing for version 4.5 and after. Sorry for the following emotional comment, but I say Software vendors should not ignore early adopters of their programs. People who were first in line deserve special and lifetime treatment. They will become your best customers and best spokesmen for your software, if you let them.
I realize you're on Windows (from the tools you describe) but, for the next Mac guy to read this question:
TextMate seriously does-not-suck for editing all sorts of things, especially collections of things (like projects of C, ruby, java, html, perl, bash, etc.) If it had SubEthaEdit's ability to do cooperative editing, it'd be the only editor I ever use.
TextMate
Depending on what code you will be using (ASP v. php v. ruby, etc), I would suggest Dreamweaver. It is WYSIWYG, but many of the best editors you would find are, including VS 2008. Of course, that doesn't mean you have to use it! I used Dreamweaver quite often at my last job and it was great for editing code and quickly previewing.
Edit: I should mention that Dreamweaver would be best for html, css, javascript, coldfusion, and php. Those are the technologies I have used it with.
I really like Kate, and since it's a KPart, other KDE programs use it as the editor, so it's goodness everywhere!
(why is everybody else assuming you use windows?)
You might want to look into Bluefish - it's what I use for php at home. It has nice support for syntax highlighting for many languages and quite a bit of other goodies HTML-wise.
I use Eclipse here at work, for J2EE stuff. It comes with some great tools and syntax highlighting for html/css/etc.