8 ms·

I’m too lazy to be a HTML developer

99 points by Garbage 15y ago

vessenes 15y ago
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 15y ago
  Why is using a solid platform not a good plan?
  - dangrossman 15y ago
    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 15y ago
      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.
    - cnunciato 15y ago
      See, statements like this really get under my skin, because they're wrong in so many overlapping and crisscrossing ways, it's hard to know where to begin in responding to them. First, "Flex/AIR", as you say, doesn't make sense -- there is no such thing as "Flex/AIR". Flex is one thing (a bunch of open-source code), AIR is another (a bunch of runtimes). You can't just throw a slash between them and call them the same thing, because they aren't, and indeed Adobe's roadmaps for both are completely separate and in this case divergent. To those who aren't familiar with the Adobe stack, it sounds like you know what you're talking about, but to those who do, you just sound like yet another uninformed FUD-spreader. As an ActionScript framework, Flex is only "dead-end" insofar as the Flash player itself is dead-end, which at near-total penetration on the desktop puts it about as far from extinction as anything could be. Flex per se, as a Flash-targeted framework, is only dead-end if someone builds something better to replace it, which also doesn't appear to be happening anytime soon, as those of us who do choose to use Flex generally happen to like working with and contributing to it. And last I checked, open sourcing a project was anything but sentencing it to death by definition. Despite abandoning Flash for mobile browsers, Adobe is actually redoubling its efforts around Flash for the desktop and the various AIR runtimes, which are, of course, extensions of the Flash player. And not for nothing, but polygeek is already a Flash developer -- he's not "putting his effort" into learning these skills; he already knows them. He's merely complaining about the prospect of having to learn another way of doing something he already knows how to do and enjoys. For my part, I'm equally experienced in both the Flash stack and in Web scripting, and I dig both; I love my Flex and love my jQuery, love JavaScript and the prospects (if only partially realized) of HTML5, and I've been around long enough to know that both have their applications and there are plenty of places where they don't even remotely overlap -- despite how often comments like this seem to suggest their interchangeability. So yes -- if you're writing Web apps that'll have to run in mobile browsers, then obviously, you shouldn't use Flash. But Flash and AIR are not going anywhere, and Flex is there for your use if you like. That's a little closer to the truth than "Flex/AIR are dead-end platforms." FWIW, I'm not responding at this length just because I think you're wrong and feel some need to correct you. As a consultant, fairly recently, I has a good-size project go less than spectacularly because some underinformed product manager decided to impose a "no stinking Flash!" policy on an application intended to run solely on desktops simply because she'd gotten the sense somewhere, God knows where, that HTML5 was trendy, and Flash was passe (and despite my having built several successful Flash projects for them previously). The problem, as I was forced to point out repeatedly as we went through the project, was that many of the functional and design requirements they'd set for it were tailor-made for Flash and Flex and trivial for them, but because they'd excluded it as a technology choice, the equivalent functionality without Flash would require considerably more time, be less uniformly compatible, and in some cases just couldn't even be done. By enforcing no Flash, they ended up with an inferior product, and all because of an arbitrary and unnecessary technical constraint. (And on the next project, they opened the door to Flash again.)
andre3k1 15y ago
off topic: Which is correct grammar -- "an HTML" or "a HTML" ? This question has always bugged me.
- ebiester 15y ago
  "an" -- the sound of the H is the key. It sounds like ay-ch.
  - Dobbs 15y ago
    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 15y ago
      Where are you from Dobbs? In Britain, 'H' should be pronounced ay-ch, but the vast majority of people get it wrong.
      - Dobbs 15y ago
        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 https://en.wikipedia.org/wiki/H#Name_in_English
- trafnar 15y ago
  It is based on the first sound of the word. If it is a consonant sound use "a" if it is a vowel sound use "an". That is what a professional copywriter told me.
- dangrossman 15y ago
  http://owl.english.purdue.edu/owl/resource/591/1/ http://owl.english.purdue.edu/owl/resource/591/1/
- 15y ago
smiler 15y ago
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.
baddox 15y ago
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.
kevinalexbrown 15y ago
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.
drivebyacct2 15y ago
Flash and Flex seem safe for 4 years? Are we putting money on this, eh?
- vessenes 15y ago
  He is, by choosing not to learn some new skills.
- timsco 15y ago
  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.
ebiester 15y ago
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 15y ago
  When adobe eventally pause to ponder the Doom hanging over the flash ecosystem, they will realize that it was Flex that killed it.
  - mappu 15y ago
    Curious, what makes you say that?
    - 9999 15y ago
      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.
  - cnunciato 15y ago
    Um, yeah -- then again, maybe not.
funkah 15y ago
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.
andrewfelix 15y ago
> '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()
Iv 15y ago
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
- funkah 15y ago
  I believe that is the first time I have ever seen anyone say XHTML would make something easier. (Just one example: http://mathiasbynens.be/notes/minimal-html http://mathiasbynens.be/notes/minimal-html )
- algorithms 15y ago
  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 15y ago
    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/ 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 15y ago
      "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.
  - Karellen 15y ago
phillco 15y ago
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.
- jarek 15y ago
  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.
- Jach 15y ago
  > How many times do you have to re-learn file IO? 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 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.
blago 15y ago
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 15y ago
  Are you not using Interface Builder for iOS? You should.
  - blago 15y ago
    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.
BerislavLopac 15y ago
Every once in a while, another developer has that revelation: http://berislav.lopac.net/post/4726275775/of-course-web-development-is-broken http://berislav.lopac.net/post/4726275775/of-course-web-deve...
artursapek 15y ago
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.
- jetako 15y ago
  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.
- tretiy3 15y ago
  I hate plugins also. Actually someone will save megs of traffic and seconds of computation doing ones own lightboxes and sliders. Any kind of them.
- cbs 15y ago
  >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 15y ago
    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)
pavpanchekha 15y ago
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.
- Radim 15y ago
  Didn't you just concede and repeat what the post said? Or I fail to see the argument.
  - laughinghan 15y ago
    No. The post is saying "HTML is too complex". The comment is saying "No, it's actually no more complex than anything else you already understand, it's just that you don't understand it yet".
    - Gravityloss 15y ago
      In my reading, the post is saying that the "HTML/CSS required is needlessly complex if you look at how simple things you want as an end result". A very different claim. You might understand the code but you might not understand how it was reached from the requirements. There's a bit too much obscure and mystical stuff. Well designed systems require you to know the basics and you can behave logically from there on so that you can deduce by yourself how things can be made to work. Relative positioning and divs or styles inside other divs/styles, text linebreaks and all that has no real dependable logic in CSS, at least didn't a few years ago when I last tried doing it by hand. It required a huge amount of trial and error. http://www.timjpriebe.com/wp-content/uploads/2009/12/css-mug.png http://www.timjpriebe.com/wp-content/uploads/2009/12/css-mug...
david927 15y ago
"HTML developer" is an oxymoron
buro9 15y ago
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.
jahewson 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      That's inheritance.
      - Dinoguy1000 15y ago
        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.
  - jahewson 15y ago
    The order in which declarations are written does indeed matter, but that's not the same as evaluation. If I assign some color attribute to black, then red, then black, the color in the DOM will never actually be red, so itsnstill meaningless to talk about a breakpoint.
diamondhead 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      > 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).
namank 15y ago
Don't sugarcoat your failures to 'lazy'. You do yourself no favours.
FigBug 15y ago
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.
darksaga 15y ago
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.
jvandenbroeck 15y ago
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 15y ago
  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.
djbender 15y ago
Did it bother anyone else that he didn't use 'an' in the title?
simpsond 15y ago
Stack adeptness = time + number of solved edge cases on said stack. Difficulty with a stack has an inverse relationship to adeptness.
anjc 15y ago
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.

99 points by Garbage 15y ago

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 15y ago
Why is using a solid platform not a good plan?
- dangrossman 15y ago
  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 15y ago
    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.
  - cnunciato 15y ago
    See, statements like this really get under my skin, because they're wrong in so many overlapping and crisscrossing ways, it's hard to know where to begin in responding to them. First, "Flex/AIR", as you say, doesn't make sense -- there is no such thing as "Flex/AIR". Flex is one thing (a bunch of open-source code), AIR is another (a bunch of runtimes). You can't just throw a slash between them and call them the same thing, because they aren't, and indeed Adobe's roadmaps for both are completely separate and in this case divergent. To those who aren't familiar with the Adobe stack, it sounds like you know what you're talking about, but to those who do, you just sound like yet another uninformed FUD-spreader. As an ActionScript framework, Flex is only "dead-end" insofar as the Flash player itself is dead-end, which at near-total penetration on the desktop puts it about as far from extinction as anything could be. Flex per se, as a Flash-targeted framework, is only dead-end if someone builds something better to replace it, which also doesn't appear to be happening anytime soon, as those of us who do choose to use Flex generally happen to like working with and contributing to it. And last I checked, open sourcing a project was anything but sentencing it to death by definition. Despite abandoning Flash for mobile browsers, Adobe is actually redoubling its efforts around Flash for the desktop and the various AIR runtimes, which are, of course, extensions of the Flash player. And not for nothing, but polygeek is already a Flash developer -- he's not "putting his effort" into learning these skills; he already knows them. He's merely complaining about the prospect of having to learn another way of doing something he already knows how to do and enjoys. For my part, I'm equally experienced in both the Flash stack and in Web scripting, and I dig both; I love my Flex and love my jQuery, love JavaScript and the prospects (if only partially realized) of HTML5, and I've been around long enough to know that both have their applications and there are plenty of places where they don't even remotely overlap -- despite how often comments like this seem to suggest their interchangeability. So yes -- if you're writing Web apps that'll have to run in mobile browsers, then obviously, you shouldn't use Flash. But Flash and AIR are not going anywhere, and Flex is there for your use if you like. That's a little closer to the truth than "Flex/AIR are dead-end platforms." FWIW, I'm not responding at this length just because I think you're wrong and feel some need to correct you. As a consultant, fairly recently, I has a good-size project go less than spectacularly because some underinformed product manager decided to impose a "no stinking Flash!" policy on an application intended to run solely on desktops simply because she'd gotten the sense somewhere, God knows where, that HTML5 was trendy, and Flash was passe (and despite my having built several successful Flash projects for them previously). The problem, as I was forced to point out repeatedly as we went through the project, was that many of the functional and design requirements they'd set for it were tailor-made for Flash and Flex and trivial for them, but because they'd excluded it as a technology choice, the equivalent functionality without Flash would require considerably more time, be less uniformly compatible, and in some cases just couldn't even be done. By enforcing no Flash, they ended up with an inferior product, and all because of an arbitrary and unnecessary technical constraint. (And on the next project, they opened the door to Flash again.)

andre3k1 15y ago

off topic: Which is correct grammar -- "an HTML" or "a HTML" ? This question has always bugged me.

ebiester 15y ago
"an" -- the sound of the H is the key. It sounds like ay-ch.
- Dobbs 15y ago
  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 15y ago
    Where are you from Dobbs? In Britain, 'H' should be pronounced ay-ch, but the vast majority of people get it wrong.
    - Dobbs 15y ago
      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 https://en.wikipedia.org/wiki/H#Name_in_English
trafnar 15y ago
It is based on the first sound of the word. If it is a consonant sound use "a" if it is a vowel sound use "an". That is what a professional copywriter told me.
dangrossman 15y ago
http://owl.english.purdue.edu/owl/resource/591/1/ http://owl.english.purdue.edu/owl/resource/591/1/
15y ago

smiler 15y ago

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.

baddox 15y ago

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.

kevinalexbrown 15y ago

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.

drivebyacct2 15y ago

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

vessenes 15y ago
He is, by choosing not to learn some new skills.
timsco 15y ago
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.

ebiester 15y ago

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 15y ago
When adobe eventally pause to ponder the Doom hanging over the flash ecosystem, they will realize that it was Flex that killed it.
- mappu 15y ago
  Curious, what makes you say that?
  - 9999 15y ago
    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.
- cnunciato 15y ago
  Um, yeah -- then again, maybe not.

funkah 15y ago

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.

andrewfelix 15y ago

> '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()

Iv 15y ago

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

funkah 15y ago
I believe that is the first time I have ever seen anyone say XHTML would make something easier. (Just one example: http://mathiasbynens.be/notes/minimal-html http://mathiasbynens.be/notes/minimal-html )
algorithms 15y ago
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 15y ago
  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/ 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 15y ago
    "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.
- Karellen 15y ago

phillco 15y ago

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.

jarek 15y ago
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.
Jach 15y ago
> How many times do you have to re-learn file IO? 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 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.

blago 15y ago

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 15y ago
Are you not using Interface Builder for iOS? You should.
- blago 15y ago
  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.

BerislavLopac 15y ago

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

artursapek 15y ago

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.

jetako 15y ago
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.
tretiy3 15y ago
I hate plugins also. Actually someone will save megs of traffic and seconds of computation doing ones own lightboxes and sliders. Any kind of them.
cbs 15y ago
>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 15y ago
  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)

pavpanchekha 15y ago

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.

Radim 15y ago
Didn't you just concede and repeat what the post said? Or I fail to see the argument.
- laughinghan 15y ago
  No. The post is saying "HTML is too complex". The comment is saying "No, it's actually no more complex than anything else you already understand, it's just that you don't understand it yet".
  - Gravityloss 15y ago
    In my reading, the post is saying that the "HTML/CSS required is needlessly complex if you look at how simple things you want as an end result". A very different claim. You might understand the code but you might not understand how it was reached from the requirements. There's a bit too much obscure and mystical stuff. Well designed systems require you to know the basics and you can behave logically from there on so that you can deduce by yourself how things can be made to work. Relative positioning and divs or styles inside other divs/styles, text linebreaks and all that has no real dependable logic in CSS, at least didn't a few years ago when I last tried doing it by hand. It required a huge amount of trial and error. http://www.timjpriebe.com/wp-content/uploads/2009/12/css-mug.png http://www.timjpriebe.com/wp-content/uploads/2009/12/css-mug...

david927 15y ago

"HTML developer" is an oxymoron

buro9 15y ago

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.

jahewson 15y ago

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 15y ago
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 15y ago
  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 15y ago
    That's inheritance.
    - Dinoguy1000 15y ago
      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.
- jahewson 15y ago
  The order in which declarations are written does indeed matter, but that's not the same as evaluation. If I assign some color attribute to black, then red, then black, the color in the DOM will never actually be red, so itsnstill meaningless to talk about a breakpoint.

diamondhead 15y ago

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 15y ago
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 15y ago
  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 15y ago
    > 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).

namank 15y ago

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

FigBug 15y ago

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.

darksaga 15y ago

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.

jvandenbroeck 15y ago

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 15y ago
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.

djbender 15y ago

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

simpsond 15y ago

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

anjc 15y ago

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.