impossible to pull out of one's ass; it's not, you're just unused to negative margins. To you, TeX macros or M4 or continuations or macros or dynamic typing or static typing or dependant typing or manual memory management or garbage collection or all sorts of things might look complex. But surprisingly, there's a whole industry of people who don't.
You're not too lazy to be an HTML developer. You're too lazy to become an HTML developer. But that, after all, is just you being lazy.
You've also got to make a distinction between necessary and accidental complexity. That example would be better written as:
body {
width: 800px;
margin: auto;
}
(This also has the benefit that the left hand side of the body does not disappear off the side of the screen in small browser windows.)
There's a similar problem with the css in the article he links to - it is more complicated than it needs to be, which just confuses the subject. Anything is hard to learn if it is taught badly.
I'm inclined to agree. I read the whole post, and found myself sort of agreeing with it, since I have been bitten by random browser specific (and not just IE!) quirks, and I can sort of understand having difficulty getting to know JavaScript if you're not used to it. Then I got to this line:
> Take a look at the CSS in step 2 of the Lightbox example. Are you kidding me? There’s no way in hell any of that follows logically.
And the other shoe dropped. I took a look at the example step referenced, and it was all very straightforward to me. I realize that this was because I'm already familiar with CSS, but I can't imagine it would take a motivated learner more than a couple minutes to learn what was going on in the code listed.
Programming in general is about always learning new things. The industry is always evolving and if you get complacent, you'll get left behind. This shouldn't be news to anyone, but if your reaction to hearing it for the first time is "that's too hard, I don't want to do that", then maybe you should go work on your carpentry skills.
For me, web development seems like the exact opposite of desktop development.
In desktop development, you learn the underlying foundations first (the programming language, files, networking, graphics, GUIs, etc), then weave them together to build your application. It's slow, but worth it -- often the concepts are universal. How many times do you have to re-learn file IO?
In web development, it's really easy to build the finished application quickly but not understand any of the foundations. Look at how many "rapid development" frameworks there are out there; most of then are fast to install, and the result is usually awesome. And plugins! There are plugins for everything, and they work so well! But the foundations are intimidating -- especially because there are so many layers of abstraction piled on top of each other. Where would you start? The browser DOM? How JavaScript is interpreted? How your database implements transactions? The more web development I do, the more I realize how freakin' tall the stack is...and how little I really know about it. Kind of scary.
What are you defining as file IO? What do you mean by re-learn--do you mean forgetting and having to learn again, or learning some new fact that changes your total understanding of the thing? What has gotten me in the past is learning how some particular language does file IO[1], which might mean learning something new about file IO I didn't know before (but didn't matter for what I wanted to do at the time) that expanded my perception. Though I guess the concepts of "read", "write", "rewrite", and "append" are the same.
I really don't think you get any more universality in desktops than you do in the web world. You might get more in the web world if you restrict your universe to the web world, due to a limited selection of choices on the front-end. (And backend too if you go the traditional route of learning LAMP with PHP on a shared host provider.)
Related to the other comment on RAD systems, even NeXTSTEP in '89-'95 had the WYSIWYG concept applied to everything as one of its major selling points. http://www.youtube.com/watch?v=j02b8Fuz73A Around 23:00 Jobs starts to demo making a GUI application that talks to a backend DB and shows pictures, and you don't need to know SQL or joins or anything.
So I don't think the desktop world has been any better in regard to keeping abstractions at bay or offering universal modes of thought (hey fork()!). The first time I programmed something with tkinter I kept asking "Where's my user-defined main loop? Where's my event handler? Where's my render stage? WTF is this 'pack' method?" Because my prior UI experience on a desktop was with pygame, which defaults to having you control every pixel.
[1]Bash likes its pipes and IO redirection, C likes its file pointers, C++ likes its streams, Java likes those too but also likes Buffer Objects et al., PHP has a nice function to glob a whole file in as a string (but you can shoot yourself in the foot if you run out of memory), "Python is obvious", "Perl is magic". If I try and load "./file" what's the context of "." and how does my language let me get a known value for that that's relative to my program and that's platform independent? What about encrypted folders, different file systems, file encoding? Will the language/OS abstract that for me? Now I want to start doing things asynchronously. Now I want to start talking to web files, now I want to start sending cookies and stuff when I'm talking to web endpoints instead of files, maybe I want to do socket IO now, and this whole trip has taken me through several other realms which seem to me pretty far removed from simple file IO.
Perhaps I'm misreading your post, but RAD environments for desktop applications have been around for over a decade. I wasn't exactly an early adopter and I remember dragging and dropping a button onto a form using Delphi 4 under Windows 98. And then you could drag and drop to resize it and formatting it was so easy a 13-year-old could do it. I didn't have a clue about Win32 API or the graphics drivers or bitmap buffers or memory buses and it totally didn't matter.
This is the nature of things. We use our lower-level tools to build higher-level tools that make the technology (or processes like development) more accessible to more people. Could you imagine having to build everything from scratch every time a new job came along?
"Build us a banking system that can be used by our employees to safeguard our customers' deposits and analyze our loaning ability, while providing web-based access to accounts by customers."
"OK. First, we'll need several tons of sand, some raw copper ..."
I think it speaks volumes that the infrastructure design of the web (or perhaps the Internet) prevents todays web app developers from worrying about how their bits move from the server CPU to the users' screens.
P.S. I'm terribly disappointed in my fellow posters actually answering the rhetorical question.
I too find web development annoying for this reason - everything feels so arbitrary. Rather than learning a set of principles you're learning a huge bag of tricks.
The result is that when I forget something, I can't go back and figure it out from something simpler. It also makes it really hard to build abstractions that actually work.
Dunno. Bytes IO or text IO? evented IO? Lazy IO? Monadic IO? Which platform are you on? Will there be concurrent access? Is your file always a file or is it also a socket?
Yeah, you re-learn file IO quite a bit I'd say. And that's without talking about APIs going from straightforward (and broken) to completely baroque (and still broken).
Oh sure, sometimes
> it's really to [read a file] quickly and but not understand any of the foundations.
I had a course in grad school in which we wrote our own database system, including having to calculate the storage to disk... as in, calculate the sectors, and where you had to break fields to a new sector, and read/write the raw binary data to/from the hard disk.
I have not really had to re-learn file IO since then.
Clearly there are new things to be learned... (do usb sticks even have sectors?)... but having that low-level experience tends to be more than enough for a front-end web developer.
I may be wrong, but I'm assuming that the author is using "HTML code" to mean HTML, CSS, and JavaScript.
As for HTML and CSS, I agree that they're difficult to debug and that it takes a lot of experimentation to become comfortable with. Developer tools like Firebug and those included with Chrome can take a bit of the mystery out of HTML and CSS.
Since breakpoints don't exactly make sense to apply to markup and style sheet languages, I'll assume the author was complaining about the lack of breakpoints in JavaScript. In fact, you can use breakpoints in Firebug.
When the author talks about the apparent complexity of various languages and platforms, he should know that this is entirely subjective. I've been goofing around with HTML/CSS/JS since I was very young, so by this point most lightbox tutorials and similar articles look fairly simple to me. Step 2 in the tutorial he mentions looks quite simple to me. The only things that I suspect would be confusing to a newcomer would be the weird vendor prefixes.
Actually, this criticism is true when you use HTML for what it was not intended to do : Make pretty renderings. The core functionality of HTML is to provide hyperlinked data. It does that concisely and efficiently. CSS and DIVs are a mere kludge added on top of a language that is supposed to transmit mainly semantical data.
I really wish xhtml would have won in place of HTML/CSS. This kind of things would have been far more easy
> I really wish xhtml would have won in place of HTML/CSS.
This makes me doubt that you understand what you are talking about. XHTML and HTML have exactly the same semantics. CSS has little to do with them (you can use CSS to style you XML documents if you wish so). With CSS3 and modern browsers you can pretty much avoid anything to HTML just for styling purposes. Heck, take a look at http://camendesign.com/ It's not visually complicated, but there are no IDs and CLASSes in the source.
I argued with one of my friends about exactly this point. He said that web development is great, that the HTML is semantics, CSS is style, javascript is everything active, everything neatly in their own files.
What I said is - look at ANY of top100 Alexa websites and show me ONE where style, semantics and action is not mangled together in one big chaos, where HTML is just semantics and not DIVs put inside each other in a hierarchy that doesn't follow semantic logic, but visual logic (with divs classes "UP", "upper_menu" etc), where javascript sits neatly in its file instead being all over the place.
I don't remember the outcome of the debate, because we then proceeded to talk about TV shows.
Same here. I think the return to "do whatever you want and we try to interpret it correctly" was wrong. Code in XHTML is way more readable, maintainable and easier to learn (IMO).
I panicked about 2 years ago, thought the web was the only future. Quit my job and became a web programmer. Lasted 9 months, absolutely hated it. Dealing with multiple browsers, guess and check methodology drove me nuts. I lasted 9 months and quit before I was fired.
I'm back to doing firmware and control software now. Much happier. It's all about what you know and how it fits your style of working.
I felt too lazy to be a Flex programmer. After years in HTML-land, MXML programming felt like an absolute kludge and Adobe's flex tools were slower than molasses. I was miserable enough doing it that I rejected multiple flex jobs that came my way.
He bemoans the lack of debuggers and breakpoints, but there could be no such thing beyond the "Is this format valid?" stuff.
HTML is a hint as to the presentation, and every client that reads the hints will largely present it the same way. But some may not... older clients, newer clients, clients for accessibility (Jaws Reader).
Accept it, be at peace with your lack of absolute control and put only the markup you need to hint at the layout you need, and then use only the CSS you need to hint at the positions of things relative to each other, and sizes relative to each other.
Once you realise you don't know anything about the screens, resolution, connection speed... or even if there is a screen, it's a lot easier to use HTML quite elegantly.
Anything you don't know is hard. Four months ago I switched from web development to native iOS work and I couldn't stop complaining how much harder it is - "Who on their right mind thought that creating and managing UI elements in code is a good idea". Fast forward to present day I still find creating UIs in HTML to be faster but the gap is not that big anymore and I really don't care one way or the other.
CSS is a declarative language, not an imperative language, so there is no concept of a breakpoint in CSS, because there is no concept of one thing occurring before another. There is a chain of inheritance of course, but Firebug will show you that.
A web browser + Firebug/Web Inspector is effectively a giant REPL, what more could you want?
The order of evaluation matters. If the browser finds 2 declarations that are in conflict, then only the last one is taken into account. And that's not inheritance.
This is so true - for the past 5 years I've been working on web apps, but this year most of my time was spent working on a java server / client with the client being a web start applet.
It has been so pleasurable to not have to worry about HTML / JS - if I want a dialog box, I can have one very simply with no messing about.
The idea of an XML document is pretty goddamn easy. The basic tags of HTML are a breeze.
The way html, css and js interact with eachother are a fucking kludge. The only way it makes any sense is with the understanding that css and js are tacked-on technologies that have influenced the evolution of all of them for a while now.
If we were to recreate the language(s) of the web from scratch at square one now, knowing what we know now about what we want from it, but without our minds being influenced by the tech structures that we do have, it would be a completely different beast.
We're still stuffing applications into a document format, when I build for the web I feel the pain of design decisions meant to conform with the realities of what came before.
I'm really surprised to read this article. For all the frameworks out there, I would think the barriers to learning HTML couldn't be any lower right now.
I actually had a conversation with our team at my company about this very problem. The idea was there are SO many frameworks, it already has become a crutch for developers. It takes the thinking out of coding for you. Then what happens when you need to build something from scratch? You'll be totally lost.
I honestly find it easier to build UI elements from the ground up over using plug-ins, because like with any other code if you are the one who developed it you understand it.
I too have been turned off by lightbox and slider plugins for jQuery, and find it easier to just come up with that kind of thing myself rather than jump into someone else's codebase.
I'm sure you have better things to do than build a lightbox from scratch. Take 10 minutes to learn someone else's solution and you can move on to solving the actual problem for which you were tasked, which likely has little to do with lightboxes.
I think people are getting a little confused. He's not saying that web developers are geniuses for understand HTML, because they aren't, he's saying that using HTML/CSS to create the type of dynamic sites we are now used to, is stupid. And he's right.
Web development feels like black magic with the amount of hacking and kludging involved, after developing native apps. And not in a good way. And not because i lack understanding or anything.
As an aside, what increasingly bugs me is the number of programmers who seem to have bought the urban myth that "An green apple" is grammatically correct, and have proceeded to pepper their project documentation with awkward and incorrect statements.
A comment on the issue[1]:
There is a bizarre urban legend of sorts that you're "supposed to" use "an" if the head noun in the noun phrase it determines begins with a vowel sound, rather than the first word in the noun phrase, giving rise to claims that "an green apple" is somehow "technically" correct. Here is a blog post of someone who seems to have gotten this idea. And here is the discussion on Language Log about that blog post.
In any case, the rule is that you use "an" if the next word begins with a vowel sound. Vowel sound is crucial here because many words that begin with vowel letters do not begin with vowel sounds (e.g. user) and vice versa (e.g. hour).
This makes it a kind of sandhi rule for "intrusive N" in English for indefinite articles, avoiding hiatus between the article and the following word.
[+] [-] pavpanchekha|14 years ago|reply
You're not too lazy to be an HTML developer. You're too lazy to become an HTML developer. But that, after all, is just you being lazy.
[+] [-] DougBTX|14 years ago|reply
There's a similar problem with the css in the article he links to - it is more complicated than it needs to be, which just confuses the subject. Anything is hard to learn if it is taught badly.
[+] [-] AgentConundrum|14 years ago|reply
> Take a look at the CSS in step 2 of the Lightbox example. Are you kidding me? There’s no way in hell any of that follows logically.
And the other shoe dropped. I took a look at the example step referenced, and it was all very straightforward to me. I realize that this was because I'm already familiar with CSS, but I can't imagine it would take a motivated learner more than a couple minutes to learn what was going on in the code listed.
Programming in general is about always learning new things. The industry is always evolving and if you get complacent, you'll get left behind. This shouldn't be news to anyone, but if your reaction to hearing it for the first time is "that's too hard, I don't want to do that", then maybe you should go work on your carpentry skills.
[+] [-] Radim|14 years ago|reply
[+] [-] marchdown|14 years ago|reply
[+] [-] phillco|14 years ago|reply
In desktop development, you learn the underlying foundations first (the programming language, files, networking, graphics, GUIs, etc), then weave them together to build your application. It's slow, but worth it -- often the concepts are universal. How many times do you have to re-learn file IO?
In web development, it's really easy to build the finished application quickly but not understand any of the foundations. Look at how many "rapid development" frameworks there are out there; most of then are fast to install, and the result is usually awesome. And plugins! There are plugins for everything, and they work so well! But the foundations are intimidating -- especially because there are so many layers of abstraction piled on top of each other. Where would you start? The browser DOM? How JavaScript is interpreted? How your database implements transactions? The more web development I do, the more I realize how freakin' tall the stack is...and how little I really know about it. Kind of scary.
[+] [-] Jach|14 years ago|reply
What are you defining as file IO? What do you mean by re-learn--do you mean forgetting and having to learn again, or learning some new fact that changes your total understanding of the thing? What has gotten me in the past is learning how some particular language does file IO[1], which might mean learning something new about file IO I didn't know before (but didn't matter for what I wanted to do at the time) that expanded my perception. Though I guess the concepts of "read", "write", "rewrite", and "append" are the same.
I really don't think you get any more universality in desktops than you do in the web world. You might get more in the web world if you restrict your universe to the web world, due to a limited selection of choices on the front-end. (And backend too if you go the traditional route of learning LAMP with PHP on a shared host provider.)
Related to the other comment on RAD systems, even NeXTSTEP in '89-'95 had the WYSIWYG concept applied to everything as one of its major selling points. http://www.youtube.com/watch?v=j02b8Fuz73A Around 23:00 Jobs starts to demo making a GUI application that talks to a backend DB and shows pictures, and you don't need to know SQL or joins or anything.
So I don't think the desktop world has been any better in regard to keeping abstractions at bay or offering universal modes of thought (hey fork()!). The first time I programmed something with tkinter I kept asking "Where's my user-defined main loop? Where's my event handler? Where's my render stage? WTF is this 'pack' method?" Because my prior UI experience on a desktop was with pygame, which defaults to having you control every pixel.
[1]Bash likes its pipes and IO redirection, C likes its file pointers, C++ likes its streams, Java likes those too but also likes Buffer Objects et al., PHP has a nice function to glob a whole file in as a string (but you can shoot yourself in the foot if you run out of memory), "Python is obvious", "Perl is magic". If I try and load "./file" what's the context of "." and how does my language let me get a known value for that that's relative to my program and that's platform independent? What about encrypted folders, different file systems, file encoding? Will the language/OS abstract that for me? Now I want to start doing things asynchronously. Now I want to start talking to web files, now I want to start sending cookies and stuff when I'm talking to web endpoints instead of files, maybe I want to do socket IO now, and this whole trip has taken me through several other realms which seem to me pretty far removed from simple file IO.
[+] [-] jarek|14 years ago|reply
[+] [-] delinka|14 years ago|reply
"Build us a banking system that can be used by our employees to safeguard our customers' deposits and analyze our loaning ability, while providing web-based access to accounts by customers."
"OK. First, we'll need several tons of sand, some raw copper ..."
I think it speaks volumes that the infrastructure design of the web (or perhaps the Internet) prevents todays web app developers from worrying about how their bits move from the server CPU to the users' screens.
P.S. I'm terribly disappointed in my fellow posters actually answering the rhetorical question.
Edit: ordering is important to clarity
[+] [-] GlennS|14 years ago|reply
The result is that when I forget something, I can't go back and figure it out from something simpler. It also makes it really hard to build abstractions that actually work.
[+] [-] masklinn|14 years ago|reply
Dunno. Bytes IO or text IO? evented IO? Lazy IO? Monadic IO? Which platform are you on? Will there be concurrent access? Is your file always a file or is it also a socket?
Yeah, you re-learn file IO quite a bit I'd say. And that's without talking about APIs going from straightforward (and broken) to completely baroque (and still broken).
Oh sure, sometimes
> it's really to [read a file] quickly and but not understand any of the foundations.
isn't it?
[+] [-] synnik|14 years ago|reply
I have not really had to re-learn file IO since then.
Clearly there are new things to be learned... (do usb sticks even have sectors?)... but having that low-level experience tends to be more than enough for a front-end web developer.
[+] [-] baddox|14 years ago|reply
As for HTML and CSS, I agree that they're difficult to debug and that it takes a lot of experimentation to become comfortable with. Developer tools like Firebug and those included with Chrome can take a bit of the mystery out of HTML and CSS.
Since breakpoints don't exactly make sense to apply to markup and style sheet languages, I'll assume the author was complaining about the lack of breakpoints in JavaScript. In fact, you can use breakpoints in Firebug.
When the author talks about the apparent complexity of various languages and platforms, he should know that this is entirely subjective. I've been goofing around with HTML/CSS/JS since I was very young, so by this point most lightbox tutorials and similar articles look fairly simple to me. Step 2 in the tutorial he mentions looks quite simple to me. The only things that I suspect would be confusing to a newcomer would be the weird vendor prefixes.
[+] [-] Iv|14 years ago|reply
I really wish xhtml would have won in place of HTML/CSS. This kind of things would have been far more easy
[+] [-] rimantas|14 years ago|reply
[+] [-] runn1ng|14 years ago|reply
What I said is - look at ANY of top100 Alexa websites and show me ONE where style, semantics and action is not mangled together in one big chaos, where HTML is just semantics and not DIVs put inside each other in a hierarchy that doesn't follow semantic logic, but visual logic (with divs classes "UP", "upper_menu" etc), where javascript sits neatly in its file instead being all over the place.
I don't remember the outcome of the debate, because we then proceeded to talk about TV shows.
[+] [-] algorithms|14 years ago|reply
I still write my HTML5 in correct XHTML Syntax.
[+] [-] FigBug|14 years ago|reply
I'm back to doing firmware and control software now. Much happier. It's all about what you know and how it fits your style of working.
[+] [-] ebiester|14 years ago|reply
[+] [-] 9999|14 years ago|reply
[+] [-] buro9|14 years ago|reply
HTML is a hint as to the presentation, and every client that reads the hints will largely present it the same way. But some may not... older clients, newer clients, clients for accessibility (Jaws Reader).
Accept it, be at peace with your lack of absolute control and put only the markup you need to hint at the layout you need, and then use only the CSS you need to hint at the positions of things relative to each other, and sizes relative to each other.
Once you realise you don't know anything about the screens, resolution, connection speed... or even if there is a screen, it's a lot easier to use HTML quite elegantly.
[+] [-] blago|14 years ago|reply
[+] [-] kenferry|14 years ago|reply
[+] [-] jahewson|14 years ago|reply
A web browser + Firebug/Web Inspector is effectively a giant REPL, what more could you want?
[+] [-] bad_user|14 years ago|reply
[+] [-] smiler|14 years ago|reply
It has been so pleasurable to not have to worry about HTML / JS - if I want a dialog box, I can have one very simply with no messing about.
[+] [-] jvandenbroeck|14 years ago|reply
CSS is making it interesting & I can understand you find javascript not easy, but HTML, really?
No offence, my little sister also doesn't understand HTML, but then again, I don't see a blog post written by my little sister on HN.
[+] [-] cbs|14 years ago|reply
The way html, css and js interact with eachother are a fucking kludge. The only way it makes any sense is with the understanding that css and js are tacked-on technologies that have influenced the evolution of all of them for a while now.
If we were to recreate the language(s) of the web from scratch at square one now, knowing what we know now about what we want from it, but without our minds being influenced by the tech structures that we do have, it would be a completely different beast.
We're still stuffing applications into a document format, when I build for the web I feel the pain of design decisions meant to conform with the realities of what came before.
[+] [-] kevinalexbrown|14 years ago|reply
When I was ten I thought HTML was too complicated because I tried to read a tutorial in one go, then make a website. Turns out you can't do that.
[+] [-] darksaga|14 years ago|reply
I actually had a conversation with our team at my company about this very problem. The idea was there are SO many frameworks, it already has become a crutch for developers. It takes the thinking out of coding for you. Then what happens when you need to build something from scratch? You'll be totally lost.
IMHO, This person is on another level of lazy.
[+] [-] vessenes|14 years ago|reply
Not a good plan; then again, not a good general attitude from a technologist.
[+] [-] magicalhobo|14 years ago|reply
[+] [-] artursapek|14 years ago|reply
I too have been turned off by lightbox and slider plugins for jQuery, and find it easier to just come up with that kind of thing myself rather than jump into someone else's codebase.
[+] [-] jetako|14 years ago|reply
[+] [-] cbs|14 years ago|reply
You're suffering classic NIH syndrome. Take ownership of the library you use, jump in and get an understanding of whats going on there.
It will be quicker than re-inventing the wheel, and getting up to speed with an existing codebase is a skill that you'll need at some point.
[+] [-] tretiy3|14 years ago|reply
[+] [-] BerislavLopac|14 years ago|reply
[+] [-] andrewfelix|14 years ago|reply
Not sure about object introspection, but setting break points is pretty straight forward using console.trace()
[+] [-] anjc|14 years ago|reply
Web development feels like black magic with the amount of hacking and kludging involved, after developing native apps. And not in a good way. And not because i lack understanding or anything.
[+] [-] andre3k1|14 years ago|reply
This question has always bugged me.
[+] [-] justsee|14 years ago|reply
As an aside, what increasingly bugs me is the number of programmers who seem to have bought the urban myth that "An green apple" is grammatically correct, and have proceeded to pepper their project documentation with awkward and incorrect statements.
A comment on the issue[1]: There is a bizarre urban legend of sorts that you're "supposed to" use "an" if the head noun in the noun phrase it determines begins with a vowel sound, rather than the first word in the noun phrase, giving rise to claims that "an green apple" is somehow "technically" correct. Here is a blog post of someone who seems to have gotten this idea. And here is the discussion on Language Log about that blog post.
In any case, the rule is that you use "an" if the next word begins with a vowel sound. Vowel sound is crucial here because many words that begin with vowel letters do not begin with vowel sounds (e.g. user) and vice versa (e.g. hour).
This makes it a kind of sandhi rule for "intrusive N" in English for indefinite articles, avoiding hiatus between the article and the following word.
[1] http://english.stackexchange.com/questions/152/when-should-i...
[+] [-] ebiester|14 years ago|reply
[+] [-] trafnar|14 years ago|reply
That is what a professional copywriter told me.
[+] [-] Jgrubb|14 years ago|reply
[+] [-] dangrossman|14 years ago|reply
[+] [-] simpsond|14 years ago|reply