
Changing times for web developers - amazedsaint
http://www.amazedsaint.com/2012/11/changing-times-for-web-developers-6.html
======
johnyzee
This is against the grain, but it is obvious to me that the way forward for
web development is to rise above Javascript and simple DOM mangling, which is
what most of these popular tools assist with. Javascript does not scale
complexity and manipulating DOM elements directly is both error-prone and a
lousy programming paradigm.

We need something in between that offers a sane development model and deals
with the complexity and anachronism of the underlying platform. GWT cross-
compilation is an excellent example. It has enabled the painless development
of complex Javascript-based web UIs[1], with the tool support of any other
software development project. This is what I'm going to look to for the future
of web application development, not patchy solutions to the complete mess that
is barebones Javascript development.

For examples of what I have done with GWT: TeampostgreSQL
(<http://www.teampostgresql.com>), a rich PostgreSQL web interface, and my
HTML5 game engine (<http://www.webworks.dk/enginetest>).

EDIT: By the way, it is only a matter of time until we have complete canvas-
based UI libraries, frameworks and tools suites akin to Flex (probably from
Adobe, too). When that happens the web will really have arrived as a rich
client platform. I would be very surprised if there isn't a few projects in
this space nearing completion at this point, since the underlying technology
is basically ready.

~~~
lopatin
Ragarding your edit: A startup called famo.us(<http://famo.us>) is focusing on
exactly this (canvas based UIs) however I'm not completely sold that this is
the future. It's an awful lot of wheel reinventing.

They're doing it in the name of solving performance for HTML5 apps and for
creating apps with rich UIs which would be more similar to interfaces we see
today in games rather than traditional DOM based UIs. However, I don't think
there's a need for that, and ditching all HTML standards in order to
reimplement them in the canvas sounds like a step backward for me.

~~~
johnyzee
I need it specifically for games, building an interface on a canvas without
even layout managers or mouse click aware components feels like the stone age,
so I am in the market for a wheel actually. Though it does seem like a bit of
a waste as the other poster also said.

~~~
1123581321
I thought the menu pattern for canvas-based games is to use DOM elements and
display them above canvas.

~~~
lopatin
That works fine to an extent, but sometimes you want your menus integrated
with your game and have consistent graphics and animations and so on. I used
dom elements for snaketron, but in hindsight I think it felt tacky (it might
partly have been because I used Bootstrap). For most games, which are more
complicated, I can imagine it would be a pain to maintain dom menus.

------
PommeDeTerre
"Changing times"? What exactly is he talking about? Many of the things he
mentioned have been pretty standard, even among the least-knowledgeable web
developers, for years now.

jQuery has had pretty significant traction for 4 or so years now.

Crockford's work is extremely well-know, as well, and has been for some time
now.

Minifying JavaScript and CSS files isn't new, nor are REST and HTML5.

The times did change, but it looks like he's still just catching up with where
the rest of us were years ago.

~~~
jasonlotito
> jQuery has had pretty significant traction for 4 or so years now.

One could probably assume you already know it. Right? =)

> Minifying JavaScript and CSS files isn't new, nor are REST and HTML5.

Being new and being widely practiced are two different things. Also, REST is
something people still struggle with today, because they assumed they knew it
because it's deceptively easy. And HTML5? Really? It takes just 10 seconds to
scroll through the thread here and see how just because HTML5 is more than 6
months old doesn't mean everyone sees it as ready.

> but it looks like he's still just catching up with where the rest of us were
> years ago

The rest of who specifically? Not HN'ers, that's for sure. Not web developers.
Who, specifically?

~~~
PommeDeTerre
I'm going based on the hundreds of web developers I've interviewed over the
past few years. These include people with no formal training, through to
people with a decade or more of experience.

While I don't specifically ask for experience with jQuery in job postings,
there have only been a small handful of those candidates who have never used
it. But even they have often just focused on using YUI, MooTools, Dojo, or
some other similar framework instead. The "changing times" the article author
talks about happened years ago when it comes to these frameworks.

The same goes for HTML5, minifying, REST, and basically everything else he
listed. These concepts are common knowledge these days, and basically everyone
in the field that I've deal with has been aware of them, and in most cases has
actively used them.

I really don't know what to say to you, if you actually are a web developer
and you found many of those concepts to be new. A lot of what the article
author lists are pretty well-established and widely-used. "Changing times"
doesn't really apply at all well after the change has happened.

~~~
mgkimsal
The author explicitly called out .NET developers (" and I see a lot of web
developers still lagging behind especially in the .NET world.") So do I.

A trip to my local .net user group last month had presenter going over ASP.NET
MVC v4 and some of the reactions and comments were... hard to believe. I'm not
saying all .NET devs are behind the times, but there seems to be a
disproportionate amount of them, based on my own anecdotal info from
attendance at various conferences and user groups over the last couple years.

We get sucked in to the bubble of HN, and the majority of people we interact
with on various boards/forums/etc are indeed aware of these technologies, but
they do not (yet?) represent the majority of developers.

~~~
amazedsaint
Thank you for answering this for me. Even the trigger for this post was a
series of interviews I did for .NET web developers in the last few weeks.

~~~
mgkimsal
The number of devs I hear complaining about "but but but... I want my
webforms!" when confronted with "use a client-side JS tool with REST/AJAX/etc"
is staggering. How do they think the rest of the world works?

Adopting these 'new fangled' approaches will _increase_ their ability to move
between worlds - perhaps even leaving the .NET compound from time to time. And
perhaps more importantly, it will make it easier for people already skilled in
front-end JS to contribute more effectively on otherwise-.NET-only teams.

You will almost never find top-notch JS talent (freelance or full-time) who
also know how to interop with webforms and older ASP.NET tech. Widen the pool,
by changing your practices, and you'll be able to compete more effectively.

------
ceautery
A couple of reactions: You guys seem to hate each other a lot, and love
javascript frameworks. Me, I've tried to snipe at my fellows a lot less on
sites like this, which has improved my online experience, and I prefer to
learn standards over frameworks.

The kind of discussion going on here is reminiscent of old timey C vs. java
vs. perl, or maybe vi vs. emacs slashdot discussions from the late 90s:
pointless. Focus on the code, not the tool, it will make you a better
engineer.

For the comments about the web not being ready for HTML5 yet because it is too
young: nonsense. Every phone supports HTML5, and every Apple computer. Every
time someone goes to google, they are suggested an HTML5 browser. My non-tech
friends are mainly on Chrome and Firefox on their Windows machines, and only
my older relatives who want to mash a button to get pictures of their
grandkids are using IE... of course, your mileage may vary.

As for the comments about humility being the same as getting overlooked in a
competitive world, I disagree. Focus on the code, not on developing a cult of
personality. If your work stands out, and you can solve problems other people
can't, you need to beat your chest a lot less.

~~~
jfaucett
"For the comments about the web not being ready for HTML5 yet because it is
too young: nonsense"

Although your personal experience may backup this assumption, it simply isn't
true when you look at the stats : [http://gs.statcounter.com/#browser_version-
ww-monthly-201110...](http://gs.statcounter.com/#browser_version-ww-
monthly-201110-201210)

~~~
napoleond
What aspect of HTML5 isn't yet ready for mainstream? JS polyfills make almost
all of it possible for the ~4% of global IE7 users (according to the site
above... no idea how accurate it is). Just using modernizer, json2.js, and
underscore enables about 90% of the HTML5 feature set for IE7. Raphael,
excanvas (or whatever) and accepting the lack of drop-shadows/rounded corners
in shitty browsers make up the rest.

Seriously. 99.9% of the time it's possible to develop in "HTML5" and drop in a
few conditional comments that load extra libraries for IE 7.

~~~
jfaucett
maybe it depends on how you view the specs, but I think what most people mean
by HTML5 is the full spectrum of new features outside markup that enable app
building, ie. filesystem API, Websockets, web workers, webgl, etc, which is to
no where near getting a 90% coverage even by using tons of shims/libs. just
browse this site to see how far along HTML5 is: <http://caniuse.com/>

~~~
napoleond
Yeah, fair enough, it's a moving target. Two years ago when people said HTML5
wasn't ready for prime time they were talking about audio and video tags,
canvas, SVG, CSS media queries, and websockets (which, by the way, are pretty
usable with a shim like socket.io or sockJS). Now those things are all more or
less feasible across browsers with some (or a lot) of JS (localStorage and the
app cache can also be used as long as they're not relied on, which is a
reasonable long term strategy for most web apps anyway) but web workers and
webgl have picked up steam since then. If we keep moving the HTML5 goalpost
(I've given up on paying attention to the spec), it will never be ready for
production use.

I guess I'm only saying this because the HTML5 brand has created enormous
confusion in the marketplace. That's largely because it was touted as "the
replacement for Flash" and my point is that it is already quite capable of
doing that in most cases.

------
mddw
I'm always amazed to see how people who give advice (and good ones in this
case) are totally unable to follow them on their websites.

296 http requests. 1.85mb transfered. Yslow grade D.

So yeah, these are good advices. In fact, the OP should follow 'em if he wants
to "survive".

~~~
popopje
he says at the bottom

"And a disclaimer – don’t look at the source code of my web page – I rarely
work on that, and is using an old blogger template. lol"

~~~
mddw
Quality code ages well. Old is not an excuse for crappy or slow, neither you
can so easily disclaim your own code.

Would you take fashion advices from someone with horrible and smelly clothes ?

~~~
davewasthere
Mind you, I know builders who still have unfinished jobs around their house.
Car mechanics whose own vehicle could use work. Electricians etc...

I think valid advice is still valid, regardless of whether they practice what
they preach. I also know how little time I have to work on my own sites with
various project work I've got on...

~~~
jlas
Yes, but when great web developers on HN are a dime a dozen, I don't want to
waste time on content that isn't polished.

~~~
yen223
The biggest irony: the HN site itself can hardly be considered 'polished'. I
mean it still uses the <center> tag!

~~~
kalininalex
But it displays fine on the iPhone (and probably on many other devices and
browsers). So, for its purpose it functions reasonably well.

------
mmaunder
Agree with half, but don't worry about:

JS MVC frameworks: MVC in JS is almost always overkill.

HTML5: Most of the web doesn't have support for it yet.

Optimization: Sure, but don't preoptimize so rather go looking for the tools
once your app tells you it's slow. Also minified JS is great to save a tiny
bit of bandwidth and obfuscate, but damn it's a pain to debug your live site.

~~~
Toshio
> "HTML5: Most of the web doesn't have support for it yet."

Say what? You probably meant to say "most of the internet explorer installed
base doesn't have support for it" which is a far, far cry from "most of the
web".

~~~
pjmlp
Like all the remaining browsers if you really need to cover a wide array of
devices, operating systems and browsers.

Web development is pretty much code once, fix everywhere.

~~~
napoleond
_Web development is pretty much code once, fix everywhere._

I'm tweeting this. Brilliant.

------
Swizec
_Is_ CoffeeScript a higher abstraction level from JavaScript? Whenever I've
taken a casual look at coffeescript I came away with the impression it was
just syntax sugar.

~~~
pooriaazimi
It is. For one thing, classes (or objects you 'new') are _much_ cleaner in CS
than any trivial implementation in vanilla JS. Splats, loops, string
interpolation and comprehensions are like added bonus (they are technically
syntactic sugar, but make thing _so_ much easier, cleaner and more readable
that it's worth using CS for these features alone). True, CS makes debugging a
bit harder (though SourceMaps might make that a thing of the past), but as CS
code is much cleaner and easier to read, stupid typos are less likely to
happen and most of the time, bugs are logical not because you accidentally
didn't put a semicolon there, or used ; instead of ,

~~~
rimantas
In my experience (I wrote substantial amount of CS code during last year)
overhead for CS debugging is so small it is not even worth mentioning. In
theory it looks much more serious than appears in practice.

------
edanm
Does anyone have any recommendations for good REST books? For example, the
book cited in the article - is it good?

I understand the basics of REST, but I want to get a deeper understanding.
Also, I still regularly encounter situations where I'm not sure what the
"best" thing to do is (collections of items, linked items, etc. - how to
represent this with REST?).

~~~
czzarr
Steve Klabnik's is pretty good: <http://designinghypermediaapis.com/>

And there is this one [http://www.amazon.com/Building-Hypermedia-APIs-
HTML5-Node/dp...](http://www.amazon.com/Building-Hypermedia-APIs-
HTML5-Node/dp/1449306578) also which is longer but more detailed. You don't
need to know anything about node to understand.

~~~
edanm
I took a look at Steve Klabnik's a few days ago. Honestly, I couldn't get into
it - I'm not sure why, but I felt it was disorganized. I felt there was no way
to really jump in from the beginning, get a good ground-level understanding,
and then progress to more advanced topics. It felt more like a collection of
articles targeting people with various backgrounds and levels.

Maybe I'll be back to it after I've read another resource - it's quite
possible Steve's is simply for someone who understands more about these
concepts than I do.

~~~
czzarr
try the other book I shared then, it will probably suit you better.

------
jopt
This almost feels dated, like many recent articles making the same point about
web development trends. Unfortunately, a lot of this is still news to a lot of
practicing professionals.

When it comes to coding in general, and especially web, I find (I admit
anecdotally) that many people who appear in the know are living roughly five
years in the past. In a recent discussion, a friend explained that JavaScript
is an example of a strictly client-side language.

I suspect many developers are delayed by books and classes, paradoxically,
even though all the information on the new sexy things is theoretically a
click away.

------
gexla
Pretty good list. Some comments here mention this is obvious or dated, but I
think that in the wild a lot of devs aren't doing these things.

I think there are still a lot of back-end devs which this very much applies
to. If you are a back-end dev who has been able to get away with not knowing
CSS (and possibly even JS) well, then you need to fix that deficiency. For
example, I typically work with a team of developers where I rarely have to
touch CSS issues, but on my own projects, I get a lot of enjoyment on this,
maybe because it's just a change.

Client side MVC is overkill in a lot of cases, but when doing client work you
will come across these, so this is a good suggestion.

Optimization is something that can get left out if you have a dev team in
which nobody picks up that piece. For me, I don't do things the client hasn't
authorized payment for me to do and I'm generally busy enough that I hit those
paid items and then I'm immediately switching to another project. Often my
client is another developer who has pieced together a team. Nobody gets paid
to do the optimization, maybe because the main developer is sloppy, lazy, or
just doesn't know. It's just one of many details which should be covered but
is often left out because of deadlines or a tight budget.

~~~
pimentel
I've wondered about client-side MVC. What level of UI complexity justifies
it's use?

~~~
randomdata
I would suggest that you should start applying MVC practises as soon as you
start adding Javascript to your page. You don't necessarily need a complex
framework, so long as you stick to the separation of concerns.

------
louischatriot
Good guidelines overall, altough I find that learning 5 client MVC frameworks
may be a bit too many :)

~~~
amazedsaint
Alright, 3 then ;)

------
speg
#1 has a bunch of links for JS but none for the CSS part of its title. What
are some good CSS resources for a developer who typically isn't suited for
design.

~~~
thefreeman
I would start by looking at some of the available CSS frameworks. There are a
million, but first to pop in my head are bootstrap , kube, blueprint, 960.

Also I would familiarize myself with pre processed CSS ie. SASS and LESS

------
se85
This reads to me like a "6 steps to becoming a better web developer" article
because the author completely fails to talk about anything "new".

~~~
blablabla123
Being familiar with 5 MVC frameworks is required to be considered as web
developer? ;)

Some people also don't like web pages stuffed to the limit with JS code, so I
wonder whether everybody agrees that you should take for every task a
specialized library. (Responsive framework, modernizr, ...)

~~~
tterrace
That's what I stopped on... FIVE javascript MVC frameworks? Maybe five WEB
frameworks for the top languages, but knowing five JS MVC frameworks seems
like a complete waste.

------
danso
As others have pointed out, it's hard to take this post seriously because of
how poorly the site is implemented...but beyond that, the advice seems either
painfully obvious or outright counterproductive.

Moreover, it depends what kind of web development you want to do.

If you want to work as part of a team in a top shop, then sure, know
frameworks and write perfectly linted code. However, if you're a freelancer
who survives by making small commercial sites, then you're working with people
who don't care about a third of a second difference in load times. Or, they'll
care way more that you get a button hover-animation to look slick than they
will about downloading jQuery uncompressed. And if you're a
freelancer/outside-party, you're not going to be able to insist on their IT to
use your deploy processes anyway, so minifying/jammiting in a productive way
may not even be an option.

~~~
amazedsaint
My blog is still on blogger, I havn't modified it much for the last few years,
and the template is due for renewal as I put in the disclaimer towards the end
of that article.

But the points I put forward is mostly what I practice these days, and the
basis is the consulting experience I had from revamping the websites/web
products across multiple domains for the customers I've worked for.

------
amazedsaint
As there are lot of comments here, thought about clarifying few points in that
article

1) About clean separation of concerns.

A lot of customers expect you to cleanly separate your client side
javascript/css/artifacts from your server side implementation. Even to an
extent where you can just take it and repackage the same with minor
modifications using a container like Phonegap, and distribute it for mobile
devices later. HTML5's significance is beyond web - it can take your app
beyond the browser.

2) About the REST Layer

Anyway you are investing in building a web application, so you need to ensure
the plumbing portion is re-usable beyond your traditional 'website'. If you
want to build a native phone application or a Chrome plug in tomorrow, you
should be able to use the same service layer.

------
rizzom5000
Tips to learn to survive? I don't know how anyone can even begin without
familiarity with most of these. Some of them are somewhat mind boggling
though. "...familiarize yourself with at least five..." MVC frameworks? What?

------
tangue
I remember when I was coding ASP sites with tables. We were happy because the
CC hover property was implemented for the first time in IE4. Web development
is always changing. We are professionals sandcastles builders.

------
znowi
What I like about web development is that it is _always_ changing. Each day
something new to learn and try. Those are nice tips, but hardly a revelation
for the HN crowd. A bit surprised it's the top story.

~~~
bbotond
It's the top story because we all thought: "I'm going to send this to _THAT_
person!" - then clicked upvote.

------
Volpe
7\. Progressive Enhancement.

It should be mentioned more, the current trend of tech is leaving it behind,
for no good reason... There should at least be a debate on it... but it seems
it's in the "Too hard" basket right now.

~~~
camus
does make sense for a website , doesnt make sense for a web app.

~~~
Volpe
Why not? Should web apps require javascript? Shouldn't the be usable even when
javascript is unavailable.

~~~
phpnode
only if the cost of supporting <noscript> is less than the benefit, which for
a lot of sites it probably isn't. The people who turn off javascript are in
the extreme minority

------
aberratio
Nice list of skills that web developers should have. But the general advice
"Learn Your Craft Well" has nothing to do with changing times. (The times are
always changing, aren't they?)

On the content: Anoop seems to work more on the Backend side of the web and as
software architect. It is not uncommon that people who are specialized on
backend are not familiar with current frontend standards. So his advice might
be addressed to these guys?

~~~
mylittlepony
Someone mentioned that .NET people is lagging on these things. Personally,
I've noticed that they like using HTTP, HTML, JS, and CSS abstractions, they
generate the code within their server-side language, so they don't try to
learn these technologies.

------
pcl
It's a good list. One nit:

> websites are expected to work in different form factors by default

Ironically, I found the font size of the article to be on the small side when
browsing on my iPhone.

------
Legion
Interesting that learning something besides .NET didn't make the list. (Or
anything back-end at all, for that matter)

------
pjbrunet
Bling for your LinkedIn profile.

------
_bear_
Here are some things you should probably learn. And in 2 or 3 years time,
you'll have to learn more things.

------
rietta
Overall, I think the OP's article is excellent.

------
Toshio
I couldn't help but notice the self-aggrandizing "most valuable professional
evah" logo front-and-center on this guy's blog, so I feel compelled to add the
7th tip to his list. Here goes.

#7 - Learn the value of humility.

~~~
gtd
What's the value of humility in the professional world?

Honesty, integrity, credit where credit is due, etc, but an overdeveloped
sense of humility is the best way to go unrecognized, at least in America.

~~~
Toshio
I've always regarded microsoft's mvp initiative as a corny-douchey surrogate
for a thriving, healthy grassroots movement.

~~~
jasonlotito
I find people who use "evah" to mock others "douchey" as well. And fairly
egotistical.

You might consider that for some people, that little logo might actually mean
something. Whether it does for you isn't important. After all, your immature
reaction and comment is far worse in my eyes then any offense the author of
the article committed. Not that you'll care.

------
wildranter
The web is a mess. Where's the news in that?

Code once and run in all platforms is pretty much a myth no matter the
framework you use, including the web ecosystem.

I've lost count of how many times I wished we could run in the browser a
decent language like python or ruby. Or describe the data of documents in
something more meaningful like JSON instead of HTML. And then there's the DOM,
CCSS, and all the browser specific nonsense.

Can I just ignore this crap and code my applications already?

~~~
Osmose
I'm confused about the JSON > HTML part of your comment. Independent of which
one is better overall, wouldn't HTML be more meaningful than JSON because it
has semantics attached to tags?

~~~
pserwylo
I've been working working working on a relatively complex user interface in JS
at work lately (merging suspected duplicates from a CRM together, and
specifying which fields from each duplicate contact is the "correct" field) .
It involves a lot of DOM manipulation and user input/feedback.

We make use of a jQuery in our app, and I was quite happy to see that although
I develop in Chrome and Linux, the UI worked pretty much flawlessly on Firefox
and Opera on Linux, and IE8 (and methinks 7, but can't remember) on Windows.

We may be lucky in that we can ignore IE6 and earlier Firefox and Chrome, but
my point is that something like jQuery does a damn fine job of abstracting
away browser differences. May not be perfect, but better than we can afford to
do.

I say this because we probably all aware that we're stuck with JS in the
browser for a while...

