

I’m too lazy to be a HTML developer - Garbage
http://polygeek.com/4912_life-of-polygeek_im-too-lazy-to-be-a-html-developer

======
pavpanchekha
Stop conflating your non-understanding of something with inherent difficulty.
You might find the code

    
    
      (defmacro unless (cond &body res)
        `(if (not ,cond) ,@rest))
    

rather opaque; but it's actually pretty darn simple. You might find

    
    
      body {
        width: 800px;
        position: relative;
        left: 50%;
        margin-left: -400px;
      }
    

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.

~~~
DougBTX
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.

~~~
jarek
Negative margin as used in pavpanchekha's example centers the box also in
browsers that do not support margin:auto. It's not complex if you know why
it's done that way.

~~~
DougBTX
The latest browser which doesn't support margin:auto is IE5.5, and even there
the text-align:center hack is a better option. There are cases where you might
want to use negative margins, but for horizontally centering block level
elements, it is at best outdated.

~~~
jarek
Unless you use a strict doctype. [http://stever.ca/web-design/centering-a-div-
in-ie8-using-mar...](http://stever.ca/web-design/centering-a-div-in-ie8-using-
marginauto/) I don't think text-align: center on the parent box is
significantly different in principle: confusing until you know why it's being
done that why and roughly how it works.

Personally I like negative margin better than text-align: center since the
style is only applied to the box being centered rather than the parent box and
the box itself, but surely this is a matter of preference or the design of the
particular page in question.

~~~
DougBTX
Yea, that IE8 bug is unfortunate.

Here's an example of text-align: center and margin: auto side-by-side:
<http://jsfiddle.net/wH5Pd/>

Try making the window narrower so that the html pane in the bottom right gets
horizontal scroll bars. (In the real world, there might be a two column
layout, such that the textual content fits in the narrow window, but the full
width of the content doesn't.)

Even when the window is narrow, all of the content in the top div can be
accessed by scrolling horizontally. In bottom div, the left hand side of the
content gets clipped because it is positioned to the left of the window, and
scroll bars don't extend into negative offsets. If you're positioning an
adornment which doesn't actually need to be visible, the negative margin trick
might be OK. But for normal body content, margin: auto is the way to go.

------
phillco
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.

~~~
masklinn
> How many times do you have to re-learn file IO?

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?

~~~
rhizome
I don't know from Monadic I/O, but at least a couple of those might appear to
the untrained eye to be application I/O rather than actual file I/O, which I
would guess has been pretty uniformly oriented around the open(3) idiom by
now.

------
baddox
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.

------
Iv
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

~~~
algorithms
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 still write my HTML5 in correct XHTML Syntax.

~~~
damncabbage
I freaked out a little when I started seeing do-whatever-you-want creep back
in when I first read diveintohtml5.org (mirrored:
<http://diveintohtml5.info/>).

Sure, you save some (or a great deal many) characters, but at the cost of
making everything that needs to work with it more complex. (Browsers are a
large slice of this pie, but by no means is the only slice.)

I'm going to sit back and wait for the cycle to come back around to XHTML-like
correctness again.

~~~
simonw
"I'm going to sit back and wait for the cycle to come back around to XHTML-
like correctness again."

Those who cannot remember the past are condemned to repeat it.

------
FigBug
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.

------
ebiester
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.

~~~
9999
When adobe eventally pause to ponder the Doom hanging over the flash
ecosystem, they will realize that it was Flex that killed it.

~~~
mappu
Curious, what makes you say that?

~~~
9999
It created too many divergent paths for developers to follow. One of the great
strengths of the flash runtime was how much easier it was to write something
that would run in any browser, all with one clear API and one set of ui
components that were easily extensible. Flex introduced far too many component
sets and encouraged the creation of overwrought java-like frameworks.
Eventually even js started looking better in comparison. The only reason they
even did that was because they got greedy. They had a decent enough IDE with
the flash authoring tool (although it needed additional support and features
for pure actionscript developers), but they decided to throw their weight
behind flex instead. Of course, flex was totally unusable for designers, and
mxml was a godawful pile of shit, so they created catalyst to allow
collaboration between designers and devs. Now you've got three different tools
all targeting the same runtime, and they all suck. So now if you're just
getting into programming for the flash runtime, you have to sort through all
kinds of garbage to find what you're looking for, pretty much the same (if not
worse) as scrounging around for js tutorials/documentation.

------
buro9
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.

------
blago
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.

~~~
kenferry
Are you not using Interface Builder for iOS? You should.

~~~
blago
It can only take you so far... You have to generate the UI for highly dynamic
parts. Intervene to resize and reposition things when actual content is
inserted. Set custom fonts manually (IB is broken). Surprisingly, text is
pretty much hell unless you are willing to settle for whatever UILabel thinks
the line-height and paragraph spacing should be. I'm not going to go into text
with mixed fonts, colors, variants, etc.

------
jahewson
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?

~~~
bad_user
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.

~~~
sahillavingia
There is more to it than just that. For example you can have a class and an id
for a div. The id attributes will overwrite the class ones. And some other fun
rules too!

~~~
jahewson
That's inheritance.

~~~
Dinoguy1000
No, that's specificity (an entirely different beast, and one that can be
considerably harder to work with). Inheritance would be styles for a P tag
applying to a child I tag.

------
smiler
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.

------
jvandenbroeck
HTML is so simple it's retarded, you just have tags and attributes.

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
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.

------
kevinalexbrown
Were you just reading the tutorial in one go, or were you working through it
at the same time?

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
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.

IMHO, This person is on another level of lazy.

------
vessenes
From the article: "Flex/Air seem pretty solid [work venues] for the next three
or four years at least."

Not a good plan; then again, not a good general attitude from a technologist.

~~~
magicalhobo
Why is using a solid platform not a good plan?

~~~
dangrossman
It may be technically solid but still a bad bet. Flex/Air are essentially
deadend platforms as Adobe jumps on the HTML5 bandwagon with its toolset. If
he puts his effort into developing his Flex/Air skills, he's targeting a
shrinking install base and future market for jobs. If he puts it into
HTML/JS/CSS instead, he's targeting a large and growing install base, for
mobile, browser and Win8 desktop apps.

~~~
magicalhobo
I think a platform that makes developers struggle with implementation details
and browser quirks is a dead end, no matter what Adobe does.

In my experience, there's a low signal to noise ratio when learning
HTML/JS/CSS. A lot of it is learning hacks, as opposed to getting a general
sense of how computers work. Flash/AIR are very good in this regard. If Flash
disappears tomorrow, I don't think his skills would go to waste.

------
artursapek
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.

~~~
cbs
>because like with any other code if you are the one who developed it you
understand it

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.

~~~
artursapek
Maybe, I mean I still use jQuery and any else that's relevant but a lightbox
is such an aesthetic, simple thing that I wouldn't consider it NIH to prefer
creating one that suits a website more (if the website's design is a big
focus)

------
BerislavLopac
Every once in a while, another developer has that revelation:
[http://berislav.lopac.net/post/4726275775/of-course-web-
deve...](http://berislav.lopac.net/post/4726275775/of-course-web-development-
is-broken)

------
andrewfelix
> _'can you set break points in your code and do object introspection?'_

Not sure about object introspection, but setting break points is pretty
straight forward using _console.trace()_

------
anjc
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.

------
andre3k1
off topic: Which is correct grammar -- "an HTML" or "a HTML" ?

This question has always bugged me.

~~~
ebiester
"an" -- the sound of the H is the key. It sounds like ay-ch.

~~~
Dobbs
Silly American, 'H' is pronounced hu-ay-ch not ay-ch.

In all seriousness how it is pronounced can and does change depending upon
where you come from.

~~~
alexchamberlain
Where are you from Dobbs? In Britain, 'H' should be pronounced ay-ch, but the
vast majority of people get it wrong.

~~~
Dobbs
I have no idea where I get it from I'm half American, half British.

Looking it up on Wikipedia says that the standard is ay-ch while the non-
standard is haitch (which is a better way of spelling what I meant).

<https://en.wikipedia.org/wiki/H#Name_in_English>

------
simpsond
Stack adeptness = time + number of solved edge cases on said stack. Difficulty
with a stack has an inverse relationship to adeptness.

------
namank
Don't sugarcoat your failures to 'lazy'. You do yourself no favours.

------
djbender
Did it bother anyone else that he didn't use 'an' in the title?

------
david927
"HTML developer" is an oxymoron

------
funkah
That's funny. I used to do backend stuff in C# but about 1.5 years ago
switched to front-end development. To me it's _so much_ nicer. I really enjoy
using JavaScript, even after C# got all that handy functional/dynamic stuff
added to it.

Anyway, maybe it's just a shitty tutorial, there are a lot of those out there.
Doesn't necessarily say anything about HTML.

Regarding the specific point about breakpoints -- yes, you can set them.
That's really not an issue at all. Come on, it's almost 2012.

------
drivebyacct2
Flash and Flex seem safe for 4 years? Are we putting money on this, eh?

~~~
timsco
Hahaha. I love this attitude. I have heard it for the better part of a decade
and I keep charging a premium for flash work because there are not enough
quality people that know it.

I know HTML and a bunch of server languages as well so I'm covered if
something would happen. I'm not going to say that flash is here forever but it
will take a lot longer to disappear than you probably think, especially with
the new 3d stuff.

------
diamondhead
it also means that "I'm too lazy to figure out that there is no such html
developer".

html is all about a few xml tags. everybody can do it. I know some music
bands, authors and politicians who code website learning basic html.

and I see some developers who ignores coding html because they think they're
too smart to code a simple website. no comment.

~~~
jasonlotito
Can we get over this? This "LOL He's calling himself an HTML _DEVELOPER_ of
all things!" mentality isn't helping anyone. You don't see spiders belittling
us for calling ourselves "web developers," do you? You especially can't do
this now that WHATWG and W3C have started to confuse and redefine what
HTML/HTML5 is and the technologies behind it.

So, let's breathe a little, and accept that if professionals can get called
shrinks, we can accept that people have different vernacular for what we do.
Hell, we _don't_ have a single unifying title either. So, unless your
proposing to call me by my professional title of "Interwebz Spin Doctor", take
a second to realize that "html developer" isn't that bad.

There is HTML, and he is developing it.

~~~
diamondhead
I really cant believe that we're discussing this, the most stupid, simple
language in the world!

I respect HTML coders and am aware of that they do fantastic job on frontend.

But nobody has to be talented HTML developer to build websites. It's stupid
easy to do it. I'm a guy who never learnt HTML and am considered as a coder
good at developing good websites.

Nevermind. I don't like this kind of pointless discussions. I don't like HN
anymore.

~~~
jasonlotito
> I really cant believe that we're discussing this

You can't? You're the one that brought it up and whine about it.

> Nevermind. I don't like this kind of pointless discussions. I don't like HN
> anymore.

You realize you bring this discussion here, right? If you don't want to see it
discussed here, don't bring it here.

If you see others bring it here, tell them to stop (as I did to you).

