8 ms·

Something is wrong with this picture.

192 points by Nemmie 15y ago

losethos 15y ago
http://www.noob.us/humor/the-office-dwight-faces-nerd-torture-of-the-highest-form/ http://www.noob.us/humor/the-office-dwight-faces-nerd-tortur... Shrinks just like to annoy me. God says... C:\LoseThos\www.losethos.com\text\WEALTH.TXT ve circumstances, therefore, which vary the wages of labour, two only affect the profits of stock; the agreeableness or disagreeableness of the business, and the risk or security with which it is attended. In point of agreeableness or disagreeableness, there is little or no difference in the far greater part of the different employments of stock, but a great deal in those of labour; and the ordinary profit of stock, though it rises with the risk, does not always seem to rise in proportion to it. It ---------- I've been tried and executed many times. I'm not a noob. You've been educated on LoseThos many times and saw it's gradual creation. Nothing is real.
politician 15y ago
"I heard people speak of Web Authors and Web Developers and making various distinctions about them. I heard some folks of arguing that this audience of ours prefers markup over scripts, and when faced with concrete examples of the opposite, retort that those are just some script library folk, not the majority." Get these people some personas, stat!
- jasonrr 15y ago
  I find that personas are nearly useless for this kind of design discussion. Personas are an attempt to homogenize some group of people into a single pseudo-person that has specific attributes. When the lines between personas are hard to draw or there are so many lines that you wind up with lots of personas, you can find yourself spending lots of time managing personas without a ton of direction or solving anyone's problems. For a heterogenous audience like "web makers" of various types, an activity centered approach can be really helpful. Don Norman explains this idea better than I ever could: http://jnd.org/dn.mss/human-centered_design_considered_harmful.html http://jnd.org/dn.mss/human-centered_design_considered_harmf... http://www.jnd.org/dn.mss/hcd_harmful_a_clarification.html http://www.jnd.org/dn.mss/hcd_harmful_a_clarification.html
  - politician 15y ago
    Thanks, those links were well worth the read.
zitterbewegung 15y ago
I guess the real question is can you or how would you try to reform the culture that has surrounded the process? Or is the alternative branching out and creating your own like WHATWG?
sskates 15y ago
HTML markup is a good example of premature design optimization. It may have been a good in theory to separate content from presentation, but if you look at the web today, the way pages are generated is a huge mess. Even this site, which uses tables for layout when "you're not supposed to used tables for layout", is a good example of why HTML is so bad for creating web pages. There's no reason I should have to jump through all the hoops I do to display two div blocks side by side in a horizontal box. All other XML based layouts I've used (Android and Flex) are a piece of cake compared to messing with HTML, CSS, and JavaScript.
- zdw 15y ago
  HTML had the opportunity to get better with XHTML and strict enforcement of schemas and XML syntax (which I'm willing to bet Android and Flex require). The problem was that doing so broke most of the web, or was not internalized by page creators. So we're stuck with the current situation (bad markup, crufty designs, etc.). Imagine if the first HTML editors forced a schema check before save. I think we'd be in a much better place now if they did...
  - bermanoid 15y ago
    But the problems sskates mentions would not be helped by better schema compliance; they start and end with the fact that CSS is a miserably poor layout engine that is not powerful enough to effectively separate content from presentation. HTML itself has its warts, sure, but the fact that we end up constantly resorting to HTML and/or Javascript edits to do things that should be happening in CSS alone is, to me, a much worse problem.
  - nene 15y ago
    I would argue the contrary, that the very reason why HTML took off so fast was that any fool was able to craft a site, and it would work even if it had a few bugs in it. Failure tolerance is a great feature. Especially if you consider it in the context of document authoring - for which HTML was originally designed for - it's better to read a document that has one unclosed <b> tag in it, than to be completely unable to read it because there's a syntax error in markup.
deleted 15y ago
[deleted]
jheriko 15y ago
I like to think the whole problem with web development is that it is popular. Almost all of the exclusive web design/script people I have met are essentially terrible at what they do - I think this happened because the web is so popular and so new that the good engineers and designers are so few and far between that their direction is diluted by the masses. Hopefully it will right itself over time. Ultimately the tools will mature to the point where what the data representation is beneath them will mean nothing to these kinds of consumers. (e.g. how you save your photos as .jpg, .tga or whatever and usually care less about the details).
- Fluxx 15y ago
  Most sites use an HTML page to launch a JS-driven app because HTML as a presentation medium is not as responsive and lack the UX elegance that one can achieve with Javascript. It's simply a technology stack that works better at solving the job. The main problem is that everyone is reinventing the wheel to deliver that kind of experience with custom JS code that augments the DOM in different ways. If browsers and the W3C worked out a way to deliver a similar UX over something standardized that browsers, crawlers and other consumers of the web could rely on, that would get used.
maximusprime 15y ago
In this age of rich webapps, the markup is just there to launch javascript. There's nothing particularly wrong with that IMHO.
- lukev 15y ago
  There's everything wrong with that. There are huge benefits to handling the internet as a linked graph of documents and resources. Try writing a site that loads all its content via Javascript and see how well you rank in Google. I have nothing against the existence of web applications, as long as it's recognized that they have a fundamentally different nature and purpose than a web page. The W3C doesn't always make decisions that are right for everybody, but they've done a pretty decent job of preserving the ideal of a document/resource-centric web. And it's important that it stays that way.
jamesrom 15y ago
A markup language, by definition, cannot define behaviour. You can do design, layout and animations with markup, but you simply cannot do any kind of processing or behaviour (when I say behaviour, I mean things like authentication, processing, manipulating data, etc). So if your webapp needs to be behaviour-rich (which I don't know how you can call it a webapp if it isn't) then you're going to need a scripting language to define those behaviours. HTML + CSS + JavaScript are complex tools, it would be great if we could unify them into a single language. I think that jQuery's success is in part due to this unification, but I certainly don't think jQuery is the answer.
- repsilat 15y ago
  Lispers have said a few times that HTML/Javascript would be well replaced by S-expresssions and (a) Lisp. There are more than a few reasons why it won't catch on, of course, but even to an old-school imperative programmer like me it sounds a damn sight better than what we have now.
buff-a 15y ago
Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. It is not possible to present an arbitrary block of data in a normalized, optimal form, and have CSS render it any way you want. For that you need script (or XSLT!), but even then, unless you go canvas, you have to deal with a markup language for presentation that is actively trying to not be presentation but be data instead. Its trying and failing. Life would be so much easier (and involve much less cognitive dissonance) if the DOM stuck to being presentation. As it is, developing web apps is this giant joke, where you encrypt what you really want to happen in the form of pseudo-data (html) and magic rule-based transformation (css), and then the browser goes to a ton of effort to attempt to recreate what you really wanted. The effort the browser has to go through as soon as you introduce a div, or change its class, just to determine which, if any, of the CSS rules now apply to that node and any of its children, is just offensive. Worse: its something you, the programmer, must be able to model in your head to determine what the fuck is going on. Good luck with that! The result we get is "try it and see" "programming". HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it.
- fooandbarify 15y ago
  While I certainly agree that there is tons of room for improvement with HTML/CSS/JS, I get confused when people start discussing it in such hyperbolic terms. It's not that bad. Most data on the internet fits really nicely into the document metaphor.
  - knieveltech 15y ago
    Normally I immediately bridle when someone offers criticism without including proposals for improvement[1] but in this case it really is that bad. It really, really is. And while I would be willing to agree provisionally that most data (by volume of unique URLS) on the web does fit the document metaphor, if page views is your metric I'm not at all convinced. For example, is it logical to even attempt to reason about a Facebook wall containing recent updates from $n individuals in terms of authorship? Is this even relevant information given the entire contents of the page will have changed in 12 hours? The document metaphor made perfect sense 15 years ago but it breaks down quickly in the face anything dynamic, as is evidenced by the need for any credible web developer to have a minimum of 7 largely unrelated technologies[2] committed to memory to do their job effectively. Markup 15 layers deep? 2000+ lines of code to tell the browser how to render a website? Vendor-specific dynamic rendering engines to sidestep the limitations of native web languages? Surely this is not what success looks like? [1] Unfortunately I have no idea how to fix this mess. [2] HTML, CSS, JavaScript, a JS Framework (typically jQuery), at least one back-end language, SQL or similar and API stuff (SOAP, JSON, etc).
ricardobeat 15y ago
For me this just demonstrates W3C's distancing from reality... There where pretty good data-driven and thought-out decisions on HTML5 from the beginning, but things were pretty grim for this year. Parts of the spec are being just pushed around (microdata…), meanwhile there is no public place for developers to be heard (and no, mailing lists and bug trackers are not ideal. this is 2011). Despite that, the web as a platform is getting better and better. Yes, it's hard to build stuff with HTML/CSS/JS, but it gets easier by the month, and the current state of the technology is really amazing (except for a few legacy browsers still bogging things down).
danssig 15y ago
Many of us are developers on here, so I propose the following: rather than be lead around by the nose on this, why don't we change it? We could define our own XML (or JSON? optional?) based data markup format and a separate presentation markup (XML/JSON based though!) format for displaying it on a graphical interface. Then we could create a browser plug-in that used it, or fork a browser to understand how to render it (or both). We could set up our web servers to detect if the client has the plug-in/browser and serve this new standard if so, or redirect to "legacy" web pages if not (with a little "best experienced with" badge). If the day comes that we aren't getting anymore "legacy" requests we can just drop them (or even better, just program the servers to be able to auto-generate something passable if a legacy client did happen by). If done right, this really could get traction, since most web designers would prefer a nice format to fighting their way through as one has to today, and clients shouldn't be able to tell any difference. The web is ours. If the "standards bodies" are making crap standards we don't have to stand for it.
yason 15y ago
The thing is, web was supposed to be about documents but it always wanted to be about programs. A basic markup language together with styling goes with the former but in the latter it becomes something you need to work around.

192 points by Nemmie 15y ago

http://www.noob.us/humor/the-office-dwight-faces-nerd-torture-of-the-highest-form/ http://www.noob.us/humor/the-office-dwight-faces-nerd-tortur... Shrinks just like to annoy me. God says... C:\LoseThos\www.losethos.com\text\WEALTH.TXT ve circumstances, therefore, which vary the wages of labour, two only affect the profits of stock; the agreeableness or disagreeableness of the business, and the risk or security with which it is attended. In point of agreeableness or disagreeableness, there is little or no difference in the far greater part of the different employments of stock, but a great deal in those of labour; and the ordinary profit of stock, though it rises with the risk, does not always seem to rise in proportion to it. It ---------- I've been tried and executed many times. I'm not a noob. You've been educated on LoseThos many times and saw it's gradual creation. Nothing is real.

politician 15y ago

"I heard people speak of Web Authors and Web Developers and making various distinctions about them. I heard some folks of arguing that this audience of ours prefers markup over scripts, and when faced with concrete examples of the opposite, retort that those are just some script library folk, not the majority." Get these people some personas, stat!

jasonrr 15y ago
I find that personas are nearly useless for this kind of design discussion. Personas are an attempt to homogenize some group of people into a single pseudo-person that has specific attributes. When the lines between personas are hard to draw or there are so many lines that you wind up with lots of personas, you can find yourself spending lots of time managing personas without a ton of direction or solving anyone's problems. For a heterogenous audience like "web makers" of various types, an activity centered approach can be really helpful. Don Norman explains this idea better than I ever could: http://jnd.org/dn.mss/human-centered_design_considered_harmful.html http://jnd.org/dn.mss/human-centered_design_considered_harmf... http://www.jnd.org/dn.mss/hcd_harmful_a_clarification.html http://www.jnd.org/dn.mss/hcd_harmful_a_clarification.html
- politician 15y ago
  Thanks, those links were well worth the read.

zitterbewegung 15y ago

I guess the real question is can you or how would you try to reform the culture that has surrounded the process? Or is the alternative branching out and creating your own like WHATWG?

sskates 15y ago

HTML markup is a good example of premature design optimization. It may have been a good in theory to separate content from presentation, but if you look at the web today, the way pages are generated is a huge mess. Even this site, which uses tables for layout when "you're not supposed to used tables for layout", is a good example of why HTML is so bad for creating web pages. There's no reason I should have to jump through all the hoops I do to display two div blocks side by side in a horizontal box. All other XML based layouts I've used (Android and Flex) are a piece of cake compared to messing with HTML, CSS, and JavaScript.

zdw 15y ago
HTML had the opportunity to get better with XHTML and strict enforcement of schemas and XML syntax (which I'm willing to bet Android and Flex require). The problem was that doing so broke most of the web, or was not internalized by page creators. So we're stuck with the current situation (bad markup, crufty designs, etc.). Imagine if the first HTML editors forced a schema check before save. I think we'd be in a much better place now if they did...
- bermanoid 15y ago
  But the problems sskates mentions would not be helped by better schema compliance; they start and end with the fact that CSS is a miserably poor layout engine that is not powerful enough to effectively separate content from presentation. HTML itself has its warts, sure, but the fact that we end up constantly resorting to HTML and/or Javascript edits to do things that should be happening in CSS alone is, to me, a much worse problem.
- nene 15y ago
  I would argue the contrary, that the very reason why HTML took off so fast was that any fool was able to craft a site, and it would work even if it had a few bugs in it. Failure tolerance is a great feature. Especially if you consider it in the context of document authoring - for which HTML was originally designed for - it's better to read a document that has one unclosed <b> tag in it, than to be completely unable to read it because there's a syntax error in markup.

deleted 15y ago

[deleted]

jheriko 15y ago

I like to think the whole problem with web development is that it is popular. Almost all of the exclusive web design/script people I have met are essentially terrible at what they do - I think this happened because the web is so popular and so new that the good engineers and designers are so few and far between that their direction is diluted by the masses. Hopefully it will right itself over time. Ultimately the tools will mature to the point where what the data representation is beneath them will mean nothing to these kinds of consumers. (e.g. how you save your photos as .jpg, .tga or whatever and usually care less about the details).

Fluxx 15y ago
Most sites use an HTML page to launch a JS-driven app because HTML as a presentation medium is not as responsive and lack the UX elegance that one can achieve with Javascript. It's simply a technology stack that works better at solving the job. The main problem is that everyone is reinventing the wheel to deliver that kind of experience with custom JS code that augments the DOM in different ways. If browsers and the W3C worked out a way to deliver a similar UX over something standardized that browsers, crawlers and other consumers of the web could rely on, that would get used.

maximusprime 15y ago

In this age of rich webapps, the markup is just there to launch javascript. There's nothing particularly wrong with that IMHO.

lukev 15y ago
There's everything wrong with that. There are huge benefits to handling the internet as a linked graph of documents and resources. Try writing a site that loads all its content via Javascript and see how well you rank in Google. I have nothing against the existence of web applications, as long as it's recognized that they have a fundamentally different nature and purpose than a web page. The W3C doesn't always make decisions that are right for everybody, but they've done a pretty decent job of preserving the ideal of a document/resource-centric web. And it's important that it stays that way.

jamesrom 15y ago

A markup language, by definition, cannot define behaviour. You can do design, layout and animations with markup, but you simply cannot do any kind of processing or behaviour (when I say behaviour, I mean things like authentication, processing, manipulating data, etc). So if your webapp needs to be behaviour-rich (which I don't know how you can call it a webapp if it isn't) then you're going to need a scripting language to define those behaviours. HTML + CSS + JavaScript are complex tools, it would be great if we could unify them into a single language. I think that jQuery's success is in part due to this unification, but I certainly don't think jQuery is the answer.

repsilat 15y ago
Lispers have said a few times that HTML/Javascript would be well replaced by S-expresssions and (a) Lisp. There are more than a few reasons why it won't catch on, of course, but even to an old-school imperative programmer like me it sounds a damn sight better than what we have now.

buff-a 15y ago

Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. It is not possible to present an arbitrary block of data in a normalized, optimal form, and have CSS render it any way you want. For that you need script (or XSLT!), but even then, unless you go canvas, you have to deal with a markup language for presentation that is actively trying to not be presentation but be data instead. Its trying and failing. Life would be so much easier (and involve much less cognitive dissonance) if the DOM stuck to being presentation. As it is, developing web apps is this giant joke, where you encrypt what you really want to happen in the form of pseudo-data (html) and magic rule-based transformation (css), and then the browser goes to a ton of effort to attempt to recreate what you really wanted. The effort the browser has to go through as soon as you introduce a div, or change its class, just to determine which, if any, of the CSS rules now apply to that node and any of its children, is just offensive. Worse: its something you, the programmer, must be able to model in your head to determine what the fuck is going on. Good luck with that! The result we get is "try it and see" "programming". HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it.

fooandbarify 15y ago
While I certainly agree that there is tons of room for improvement with HTML/CSS/JS, I get confused when people start discussing it in such hyperbolic terms. It's not that bad. Most data on the internet fits really nicely into the document metaphor.
- knieveltech 15y ago
  Normally I immediately bridle when someone offers criticism without including proposals for improvement[1] but in this case it really is that bad. It really, really is. And while I would be willing to agree provisionally that most data (by volume of unique URLS) on the web does fit the document metaphor, if page views is your metric I'm not at all convinced. For example, is it logical to even attempt to reason about a Facebook wall containing recent updates from $n individuals in terms of authorship? Is this even relevant information given the entire contents of the page will have changed in 12 hours? The document metaphor made perfect sense 15 years ago but it breaks down quickly in the face anything dynamic, as is evidenced by the need for any credible web developer to have a minimum of 7 largely unrelated technologies[2] committed to memory to do their job effectively. Markup 15 layers deep? 2000+ lines of code to tell the browser how to render a website? Vendor-specific dynamic rendering engines to sidestep the limitations of native web languages? Surely this is not what success looks like? [1] Unfortunately I have no idea how to fix this mess. [2] HTML, CSS, JavaScript, a JS Framework (typically jQuery), at least one back-end language, SQL or similar and API stuff (SOAP, JSON, etc).

ricardobeat 15y ago

For me this just demonstrates W3C's distancing from reality... There where pretty good data-driven and thought-out decisions on HTML5 from the beginning, but things were pretty grim for this year. Parts of the spec are being just pushed around (microdata…), meanwhile there is no public place for developers to be heard (and no, mailing lists and bug trackers are not ideal. this is 2011). Despite that, the web as a platform is getting better and better. Yes, it's hard to build stuff with HTML/CSS/JS, but it gets easier by the month, and the current state of the technology is really amazing (except for a few legacy browsers still bogging things down).

danssig 15y ago

Many of us are developers on here, so I propose the following: rather than be lead around by the nose on this, why don't we change it? We could define our own XML (or JSON? optional?) based data markup format and a separate presentation markup (XML/JSON based though!) format for displaying it on a graphical interface. Then we could create a browser plug-in that used it, or fork a browser to understand how to render it (or both). We could set up our web servers to detect if the client has the plug-in/browser and serve this new standard if so, or redirect to "legacy" web pages if not (with a little "best experienced with" badge). If the day comes that we aren't getting anymore "legacy" requests we can just drop them (or even better, just program the servers to be able to auto-generate something passable if a legacy client did happen by). If done right, this really could get traction, since most web designers would prefer a nice format to fighting their way through as one has to today, and clients shouldn't be able to tell any difference. The web is ours. If the "standards bodies" are making crap standards we don't have to stand for it.

yason 15y ago

The thing is, web was supposed to be about documents but it always wanted to be about programs. A basic markup language together with styling goes with the former but in the latter it becomes something you need to work around.