
Web Development: A Crazy World - cygwin98
http://rubiken.com/blog/2013/02/11/web-dev-a-crazy-world.html
======
rpeden
I've found that a large subset of programmers share the same trait as a large
subset of photographers: they become so obsessed with tools that they lose
sight of the fact that the end product is what matters at the end of the day.

For example: there are many people who spend thousands on cameras and gear,
and still take terrible photos. There are many developers who spend a lot of
time keeping up with what they think is the latest trend, and yet they never
finish any projects that get used.

Then you have the photographers who take great shots no matter what gear they
use, and developers who write and ship great code and products using Java and
other unsexy languages.

Can better tools help you be more productive? Absolutely. But if you spend all
of your time worrying that you're not using the latest and great tools, you
won't get much done, and you won't be satisfied with what you do get done. I
have 15 cameras and unfinished projects in 10 languages that demonstrate that.

My advice? Sit back, pick technology a couple of steps behind the bleeding
edge, and focus on results. Choosing Ember over Backbone isn't going to cause
your project to fail; building the wrong thing or failing to finish, however,
will.

~~~
eranation
Author of the original rant here, funny it became viral and translated to
Chinese (and back to English) :)

The rant was made as a comment here: [http://www.zemanta.com/blog/i-bet-you-
over-engineered-your-s...](http://www.zemanta.com/blog/i-bet-you-over-
engineered-your-startup/#comment-685047168)

Picked up by a Tilo Mitra: <http://tilomitra.com/the-crazy-world-of-code/>

And as discussed here in HN before:
<http://news.ycombinator.com/item?id=4226990>

The point of it was actually: it's impossible to always keep up anyway so take
something you like or already good at and move with it otherwise you'll never
get your project done. It's nice to learn new frameworks, and you should, but
it's mandatory that by the time you pick up something there will be something
else that is considered better / more popular.

(I'm not saying "use Java Applets / Flash / XML+XSLT" just because "you are
already good at it", sometimes you must let go of what you know and adapt to
change, just don't over-kill it by learning EVERY new technology as it comes
out, taking 1 step back is always a good thing)

I think the spirit of it was a bit lost in translation so here is the original
text:

> I agree, I can't keep up, I just finished learning backbone.js and now I've
> found out on HN that it's old news, and I should use ember.js, cross that,
> it has opinions, I should use Meteor, no, AngularJS, no, Tower.js (on
> node.js), and for html templates I need handlebars, no mustache, wait,
> DoT.js is better, hang on, why do I need an HTML parser inside the browser?
> isn't that what the browser for? so no HTML templates? ok, DOM snippets,
> fine, Web Components you say? W3C are in the game too? you mean write
> REGULAR JavaScript like the Google guys? yuck, oh, I just should write it
> with CofeeScript and it will look ok, not Coffee? Coco? LiveScript? DART?
> GWT? ok, let me just go back to Ruby on Rails, oh it doesn't scale? Grails?
> Groovy? Roo? too "Springy?" ok, what about node.js? doesn't scale either??
> but I can write client side, server side and mongodb side code in the same
> language? (but does it have to be JavaScript?) ok, what about PHP, you say
> it's not really thread safe? they lie?? ok, let me go back to server coding,
> it's still Java right? no? Lisp? oh it's called Clojure? well, it has a
> Bridge / protocol buffers / thrift implementation so we can be language
> agnostic, so we can support our Haskell developers. Or just go with
> Scala/Lift/Play it's the BEST framework (Foresquare use it, so it has to be
> good). of course we won't do SOAP and will use only JSON RESTful services
> cause it's only for banks and Walmart, and god forbid to use a SQL database
> it will never scale I've had it, I'm going to outsource this project... they
> will probably use a wordpress template and copy paste jQuery to get me the
> same exact result without the headache and in <del>half</del>quarter the
> price

p.s. it would have been a longer rant today, I have lot of new things to add
to it, sadly things didn't get any better: Now I'm trying to choose between
yeoman and brunch, coffeescript vs livescript vs typescript, LESS vs Sass vs
Scss vs stylus, Haml vs Jasmine vs that weird language called HTML, testacular
vs mocha, fixtures vs mocks, RequireJS vs CommonJS, with almonds or without, I
started using underscore then figured out it's already "old school" and I need
to actually use lo-dash. So I think I'm going to take your advice ;).

~~~
api
The absolute worst is SOA (the "enterprisey" buzzword for lots of small
services) architectures in which _every service is written in a different
language_!

"Oh, our payment processor is in Node, but our site's in Ruby. Our file
caching layer is in Python with bits of C for high performance and our crypto
stuff is in C++ with Boost and libcryptopp but it talks to a Java app that
uses Cassandra..."

(Runs outside, sets self on fire, shoots self in head...)

~~~
aditya
What's wrong with that if every service is using the right tool for the job
and provides a sane API? Maybe maintenance?

~~~
api
A few things:

(1) Code reuse, or lack thereof.

(2) Multiplication of surface area for things like security bugs... now you
have five different stacks to keep track of security updates for instead of
just one.

(3) Multiplication of deployment resources-- now you need multiple VMs, maybe
multiple instances with different stacks to run them on, etc.

(4) Developers can't pinch-hit for each other unless they know every damn
stack in the world.

(5) If you sell, God help whoever has to support that stuff in your new
organization.

~~~
thwarted
_(5) If you sell, God help whoever has to support that stuff in your new
organization._

It would be interesting to know if an acquisition fell through because due
diligence revealed something like this and the purchasing entity didn't want
to deal with that mess or it conflicted with their culture.

~~~
lifeisstillgood
Absolutely not - no it manager worth their salt will pass up the opportunity
to say - well we can do it but we will need more cash - we have to hire a ruby
team a node team a ...

:-)

------
purephase
While some might complain or worry, this is what makes this field so
fascinating. A myriad of options, toolsets and methodologies means that it is
alive, open and thriving.

Imagine is Adobe, Oracle or MS had won the Flash/Flex, Java or ActiveX
battles, where would we have been today?

As much as I use Chrome (and love it), I can't help but admire the work done
by Mozilla to rescue the Netscape codebase and mould it into Firefox. I think
they deserve a lot of the accolades that enables this zany ecosystem to
thrive.

~~~
dgesang
> Imagine is Adobe, Oracle or MS had won the Flash/Flex, Java or ActiveX
> battles, where would we have been today?

I don't know what 'would have been', but I know that we would not be where we
are today (in a positive sense) without those companies and the many many
technologies and products they have provided us with (even though some of them
can only serve as bad examples).

~~~
purephase
I'm not bashing them as a whole, just some of their technology decisions. To
be honest, I've always felt that MS gets a bad rap. As much as it was anti-
competitive, bundling IE in Windows enabled users to download alternative
browsers. Obviously, there are other ways to do it but I doubt many users
would have gone down that road with higher technical obstacles.

As for Oracle, not much can redeem them. Flash had it's day, but I wish Adobe
would let it die already.

~~~
dgesang
> As for Oracle, not much can redeem them.

If anything. :)

> I wish Adobe would let it die already.

I know many here can't accept the truth that Flash had, has and will have its
place on the Internet. There was a need for such a technology and there still
is. I will be here for another 5-15 years or so, so we should make the best
out of it instead of screaming 'DIE ALREADY'. But as always, there is plenty
of room for improvements. :)

FYI: Adobe donated Flex to the ASF a while ago and the mailing list is already
the most active on ASF. It is actively developed and people are quite
motivated.

~~~
purephase
If it wasn't the security issue laden monstrosity that it is, I could see it
living on.

But the facts are that the only real "secure" version is the PPAPI
implementation in Chrome (which has it's own limitations), Adobe has dropped
future development for embedded systems and that it is almost non-existent on
mobile does not speak to the longevity that you predict.

Flex is cool, but it's dependency on Flash will be it's noose.

------
mattjaynes
I love how YouTube approached this: Choose the simplest and most stable tools
and use those.

It's a great strategy for developers that want to ship. Otherwise one can
easily be lured by the siren calls of new tech.

I've certainly fallen victim to this temptation, but I've found that as I let
go of the new pretty things and focus more on using the old boring workhorses
of the interwebs, I get a ton more done.

Plain vanilla seems boring - but it's bad-ass in web architecture. We forget
that YouTube had plenty of competitors that were well ahead them before they
dominated.

They kept things simple and solid and that allowed them to scale. It's
certainly not the only reason they won, but I'd bet it's a huge part of it.

\---

For more on YouTube's stack, see:
[http://highscalability.com/blog/2012/3/26/7-years-of-
youtube...](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-
scalability-lessons-in-30-minutes.html)

------
bane
It blows my mind sometimes, looking at a web page made of mostly simple text
and a few images, to view the source and see page after page after page of CSS
and javascript just to make something that looks only slightly better than

[http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T...](http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html)

~~~
inigoesdr
"Slightly better" is a subjective assertion. Especially in the webdev world
where the pace of design and functionality improvements tend to move so fast.
Granted, you may display the same/similar information in a text-only page,
such as your example. But you won't be engaging users much or creating a site
that people will want to see & return to, which is where the money that is
spent on webdev work generally comes from.

------
saltcod
Wow. Fantastic piece.

This is precisely how I see the ecosystem too. If I've learned anything:

1\. Focus on _something_ —Rails, Python, Javascript, WordPress, something 2\.
Learn to actually program — any language will do

~~~
skeletonjelly
Maybe this is a side effect of this current day and age being a specialist
society? Everyone needs something to differentiate themselves from the crowd,
and Javascript being such a recent growth in setting a "standard" with regards
to frameworks and tools makes for a good incubator for specialists.

------
danso
I'm far from an expert coder compared to most on here...but...what's the big
deal? Once you've grokked server-side code and framework, is it really that
hard to move from Rails to Sinatra or even to Django? Once you know databases,
how hard is it to switch from SQLite to Postgres or to even Mongo? Same goes
with Javascript frameworks.

Now, I'm referring to the scope of what a _web-developer_ needs to know to
interface with these technologies...obviously, a database engineer is expected
to dive deep and know all the quirks/limitations of NoSQL vs SQL.

Is the complaint that "Oh shit, I don't know if I can learn new syntax?" Or is
it more, "The hiring market is segmented by too many technologies for me to
claim to be an expert at?"

~~~
hipsters_unite
> "The hiring market is segmented by too many technologies for me to claim to
> be an expert at?"

I think that's a concern to many new programmers (myself included) when
looking at the pace these tools and frameworks are coming out and then
maturing.

~~~
jmcdonald-ut
As a computer science major this doesn't worry me at all. Learning the
fundamentals, the theory, and the overall science leads me to believe we will
be just fine on the market.

As an intern I use PHP on a day to day basis. At school classes have been
fairly language agnostic, switching from C++, C#, Java, PHP, and others. I
have classes that force you to do all your work in the terminal, and some that
allow you to use powerful IDEs. Furthermore, I have classes that you rarely
even touch a computer (Algorithms, which should be more aptly named Algorithms
II since Algorithms & Data Structures is a pre-req).

In my experience, switching tools/languages/frameworks isn't as hindering as
lacking core engineering skills.

------
nahname
Learn technologies that are popular, such as jQuery. The community will help
make this easy. You will use jQuery on almost every project, so this will be
time well spent.

Master components that are core, such as JavaScript. You will use JavaScript
on every project. A true understanding will be essential to everything you
choose to do with it. It amazes me how many developers do web development
without ever trying to learn how to write effective JavaScript.

Lastly, do something just for fun. Programming is fun, enjoy it once in a
while. Try a new language you will probably never use. Use a new framework or
library. Look into something old. It is amazing how many old things are new
again.

Do all this and the web won't be such a scary place.

------
anons2011
Quite amusing and very true. Just had a little look at Handlebars - writing 3
to 4 times as much to generate very little.

Also reminds me of this tongue in cheek site :
<http://html9responsiveboilerstrapjs.com/>

~~~
equator
Heh... [https://github.com/impressivewebs/HTML9-Responsive-
Boilerstr...](https://github.com/impressivewebs/HTML9-Responsive-Boilerstrap-
js/issues)

------
bpatrianakos
I think its so great that we have so many new toys and such innovation going
on in the world of the web. I remember when I was first starting out as a
developer (when I was 10, it was 1996, I wasn't very good) all we had was HTML
and CGI scripting. CSS was the new hotness that no one understood and PHP was
just learning to crawl. Those two technologies were all there was and I don't
remember other developers ever going nuts like an adoloscent girl at a Beatles
concert over any of the stuff that was coming out then. It really is nuts how
we push all this latest and greatest stuff only to abandon it next week. I
remember just about a year or two ago the HN community was in absolute love
(like 'The Notebook' style, forever and ever, everlasting love) with Rails -
even more so than now. There were endless debates over its merits and its
pitfalls and I watched as the people who took those debates the most
personally agonized over every small bit of the development process while
those who didn't really care as much just built stuff.

It really is great that these new toys are coming out but what I see as the
real problem is that we lose sight over one particular piece of the bigger
picture. We forget to ask ourselves "Does this solve my or my users'
problem(s)"? Even when we do ask that question we then get caught up over
minutia like the elegance of code and performing between two competing tools.

That stuff doesn't matter yet! What matters is that you grasp the concepts the
tool promotes and can use it effectively. Beyond that there's usually not much
difference in the "elegance" or performance of your code between two tools and
it usually comes down to subjective views and how you work. Even if you do
choose the "optimal" tools you're most likely fucking up some other part of
your codebase anyway. None of us write perfect code. That's why refactoring is
a thing.

Are you stuck when it comes time to choose handlebars or mustache? Can't
decide between Ember and Backbone? Is Rails or Sinatra better? CodeIgniter or
Laravel? Thinking of using Django over... uh... whatever the competitor to
Django is? Then you've got your head stuck way too far up your ass and
focusing on the wrong thing. I don't mean to offend with that crack - I too
have had my head up my developer ass many times before and all it got me was a
'Hello World' page in a project that was stalled before it even started.

So my point is that using the new hotness is fun and challenging and it can do
you a lot of good but the moment you stop developing and start _chasing_ the
new hotness you've become kind of a tech groupie rather than a developer.

------
cglee
The analysis paralysis on which tools to use really comes from lack of focus
on which problems you wish to work on. Many people are either told what
problem to work on (employees), or have an unclear focus (I just want a job,
any job!).

Therefore, they feel they need to learn and use _every_ tool so that they can
be prepared for "choosing the right tool for the job".

The solution is to focus on projects of your choosing. When it's clear that
your problem is a nail, you can tackle it with any tool that can pound with
force: hammer, mallet or shoe heel will all work; frozen cucumber will not. In
other words, there are clear wrong choices - get rid of those and pick one of
the right ones. The paralysis melts away once you have a problem around which
to frame your analysis.

Another beautiful thing about web development: you can learn to use a hammer
(let's say, Rails) and you can use that hammer to pound a million nails.

It's a fallacy to think that you have to learn everything, every methodology,
so you can be prepared for some ambiguous future project, in hopes of solving
some unforeseen problem.

This approach has another great side effect: you won't be easily side tracked
by the new shiny thing that promises async evented dilly every few months. If
it doesn’t solve YOUR problem, move on.

------
davidw
_Most_ of the 'mess' I see is the current state of Javascript frameworks,
which are in the Cambrian explosion phase of things.

I'd just use Rails as a default for most things I do these days, and if it's
not a good fit, evaluate other technology.

~~~
lifeisstillgood
I was just about to post "Cambrian explosion" as an metaphor for the state of
javascript libraries.

There are good reasons to get the HTML formatting off the server and into the
client, so the new style JS is all going in the right direction. So another
metaphor:

All these frameworks are trying to solve the right problem in the right
direction - which one will win out eventually - who knows, but even if you
hitch a ride on one that stops half way, you are half way closer to the right
destination than if you wait.

~~~
redeemedfadi
What will be funny is when we move everything back to server-side once we
don't have network latency/bandwidth issues.

~~~
lifeisstillgood
Really? transmitting just the data and letting the client handle the display
and interaction seems a much more natural split.

It alos makes my server software conceptually simpler - which is always nice

~~~
metaphorm
I agree. Separation of concerns is a very good design pattern. MVC server
frameworks (like Rails and Django) have already separated out the concern of
displaying data to the user with their template systems. its a very reasonable
next step to just migrate the entire template system off the server and let
the client do it.

This has gigantic performance increases for servers under heavy load, and it
puts the display logic in a domain that is more naturally suited to dealing
with it (JavaScript and the DOM instead of treating HTML as just a string).

The pattern also promotes the use of RESTful APIs for data access from the
server, which has the wonderful bonus of allowing you to make your data
publicly accessible for free if you want to.

~~~
davidw
Templates... ok - that's fairly convincing. I'm less convinced about keeping
the model and controller client side, because they end up replicating stuff
that still has to live on the server anyway, to some degree. That just seems
to make things harrier than they were to begin with.

~~~
lifeisstillgood
I think if you are trying to replicate the same functions you are right. But
if I have, say, a User model then it is merely a conveniently name for two
groupings of functions.

My client side user should know nothing about Dbase lookups or persona
verification - just as server model should not care about displaying
addresses. Overall I think getting the crap out of the server makes it much
much easier to reason and architect

------
damian2000
Sounds like <http://en.wikipedia.org/wiki/Analysis_paralysis>

------
raverbashing
Yes, this

The amount of 'meetoo.js' is amazing(ly bad)

Because of course everybody has to have "MVC responsive html5 cascading
containers with chocolate covering"

Not to mention most of these are underdocumented, bug-ridden, too specific,
etc

Need a js library? JQuery. period (and don't get me started with mootools, I
need to ship, not swim around their docs figuring out how to do what in jquery
is easy )

And focus on the backend, a competent backend development will eat your
whatever.js "specialist" except for the most specific cases

~~~
marknutter
> Need a js library? JQuery. period

Sure, if you love writing the same boiler plate code over and over again to
make sure your dom is updated and your data is synced. JS frameworks _are_
solving a problem, whether or not people like that there are so many out
there. We are in the early days, and of course there's going to be a lot of
competition. A few will rise to the top and become standards. You know, there
were quite a few competing JS libraries before JQuery became so popular..

~~~
raverbashing
What I mean is "don't use a jQuery competitor (or jQuery 'sized' tool) in
place of jQuery"

Sure, if you need something else/more use it, still I've been burned by those
"wonderful js frameworks" and I'll make sure to not use them unless needed and
thoroughly evaluated.

~~~
marknutter
Well, at some point, there will emerge the "jquery of js frameworks."

------
42tree
This piece first appeared as a comment on this page in ENGLISH in July 2012:
[http://www.zemanta.com/blog/i-bet-you-over-engineered-
your-s...](http://www.zemanta.com/blog/i-bet-you-over-engineered-your-
startup/)

while the author claimed to have it translated from Chinese back to English,
surprisingly almost exactly the same as the original English version. I guess
English-Chinese-English translation has reached an amazing stage!

~~~
cygwin98
OP here. I've updated my blog to credit eranation (author of the original
English post) and relevant links. I was not aware of the existence of the
original English post and thought that I should share it as lots of us suffers
the same frustration.

 _I guess English-Chinese-English translation has reached an amazing stage!_

I would take it as a compliment as my 'unofficial English version' isn't too
far off.

~~~
42tree
Yes, it is a compliment :) btw, if it is possible can you also show the link
to the Chinese version?

------
beefsack
Call me a masochist, but I love the huge amount of selection, I love how
passionate people are about their own solutions meaning they rapidly improve,
and I love getting my hands dirty with pretty much anything I can get my hands
on.

It's great having too many tools in your toolbox.

~~~
baak
That last sentence conjured an image of a person trying to drag a giant
toolbox with him everywhere for some reason :) I do tend to disagree with the
sentiment though.

The initial time investment per tool is steep.

Also, the tools' values deteriorate rather rapidly. Languages/Frameworks will
become less used over time as something new replaces them (generally), and
even your specific skills with a language will get worse over time if you
aren't using it.

------
timonv
Web Development is fine, it's the Javascript, and especially the frontend
world that's the problem.

Why do we bother with a language that's inconcise, lacks so many common,
useful functions (enumerals, strings, etc), and general doesn't do what we
want it to do? In spite of fundamental problems, people try to address them
with custom solutions. Those are inherently very PERSONAL solutions - because
everyone wants to do it well and better - bound to raise discussion and
competition at some point. That's what's happening. People are trying to fix
something broken with their own, idealistic ideas.

There's nothing wrong with that, don't get me wrong, but I think we all know
that we can do better on a more fundamental level.

~~~
marknutter
I'm shocked nobody has pointed this out, but we "bother" with javascript
because it runs in browsers, and browsers are ubiquitous. Why does everyone
who has personal issues with Javascript or web development in general seem to
forget that it has become popular because of the webs ubiquity and the promise
of cross-platform development?

~~~
timonv
And that's exactly the problem. The promise has been there for _years_, it
just never has been made up to. Sure, cross-platform development is cool, you
can do that in Java. I can also do it in Ruby, Go, Rust, Clojure, Erlang or
Haskell. And those solutions don't feel like a duct tape on a drainpipe.

It's still the same as it was 10 years ago, we can't wrap our head around a
solution that works for all browsers, hence, we can't _just_ make the language
concise, let alone change it fundamentally to solve the more actual problems
of front end development. And then, if frameworks don't have to fix a language
in their own way, we can get something real going. In any case, I just can't
wrap my head around the discrepancy as to why-the-fuck-still.

~~~
marknutter
I'm not sure I'm understanding. I develop web applications that run well on
all major platforms and it's not nearly as hard to do as people make it out to
be. And the difference between Javascript and Java, Ruby, Go, Rust, etc. is
that it runs in an environment that literally everybody already has installed
when they buy a computer - the web browser. No mucking around with installing
the JVM, or downloading an application to install and keep up to date, etc...
you just point your browser to say, Facebook.com or news.ycombinator.com and
boom, you are served a nice, cross-platform application that never needs
updating. Thus, the popularity of javascript and web technologies.

~~~
timonv
Ubiquitous does not imply concise across. Which is not the case.

------
Torn
As with all technology choices, you've got to draw the line somewhere - new
and risky, or old and proven, or somewhere in between.

What matters these days is probably how well you and your team already know
the technology, how good the documentation is, community size/takeup, how
quick the devs are to respond to issues, and how mature and stable the API is
from release to release. How popular/old the technology is also counts for
more if you're looking to hire people with experience in it.

MVC on the client is becoming more and more important, once you start slapping
a lot of js on a page it can quickly become un-maintainable. We went with
Backbone as Ember was changing too quickly in backwards-incompatible ways.

MVC on the server (Django/Rails/Express/whatever) still has a place - you want
something serving restful data / html skeletons and mapping urls to responses.
In my day job that's Spring MVC because that's what people here know and it
ain't broke.

Frontend language choice: Learning JS seems to be the natural choice here.
Things that compile to JS e.g. CoffeeScript or DART might also work for you; I
don't have experience with them but I'd imagine debugging problems in the
resulting js would be a pain until browsers support them natively.

~~~
Kototama
I used to develop with JavaScript, and JavaScript with Backbone before we
switched to ClojureScript.

Backbone helped me to better structured my code but I found it also brings its
own problems. There is a quite a lot of boilerplate code and views composed of
other views were for me hard to manage.

I also wrote some macros to use Backbone from Clojure but the mismatch between
object/mutable and functional/immutable is too high.

Finally the approach from <http://clojurescriptone.com/> seems promising. It
uses a simple yet flexible event dispatcher. Add that a templating engine and
you are done.

Debugging ClojureScript within the browser is harder than normal JavaScript
but it's easy nonetheless to find what generated JS functions corresponds to
your ClojureScript code. If you compile in debug mode you can set a breakpoint
as usual. Compiling ClojureScript adds a bit of overhead to the workflow but I
compiled it continuously in the background via Emacs and forget about it, it
just popups when an error occurs.

In general I found ClojureScript much cleaner than JavaScript and it's easier
for me to write cleaner code with it when the data manipulation or the logic
is not trivial.

~~~
Torn
Yeah, we had to write our own view nesting logic and allow this to be used
within our dustjs templates.

Marionette (<https://github.com/marionettejs/backbone.marionette>) lets you do
all of that stuff out of the box; I've not used it though so can't comment.

------
tosh
I like many of the state of the art frameworks, especially backbone.js and I'm
really thankful for how much impact they had on making complexity in web apps
manageable. That said I absolutely agree with you regarding the fragmentation
problem which seems more like a stack problem to me.

For me personally it looks like what the web desperately needs is a common
ground for how widgets work and behave. Web Components look like what we will
get and I really can't wait to see that happen:
[https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/explainer/...](https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/explainer/index.html)

Here are some examples from Dart Web UI (web component polyfills for Dart)
<http://www.dartlang.org/articles/dart-web-components/>

Also here is a great article about the web stack fragmentation that you might
be interested in: [http://zef.me/4835/dart-web-fragmentation-vs-web-
development...](http://zef.me/4835/dart-web-fragmentation-vs-web-development-
fragmentation)

Exciting times, Thomas

------
lhnz
This has been my experience, too. But I think it's wrong to jump to the
conclusion that because going too far and having to learn too much is a bad
use of time that you should just stick to one or two things. This is black-
and-white thinking and I think in this case, your response should be in the
context of the problems you face and the career you are building.

We do need to move along with technologies if we want to stay relevant. But
you need to know what's a fashion and what's worth adding to your skillset.
After leaving University I mainly knew Java but I learnt PHP and JavaScript
because I wanted a web development job; later on I felt that none of the cool
startups were using PHP and all of its warts had become very apparent to me so
I picked up Python which seemed a lot more elegant. (However this was more a
case of fashion that gave me access to higher-impact and higher-salary jobs.
My actual needs to code in a general-purpose language with nice libraries
isn't a worthy goal in itself.)

Currently I am working entirely in Node.JS and I don't consider myself to be
drinking the Kool Aid because it made more sense to stick to one programming
language and I needed long-running processes. I do have to be careful to not
add too many libraries, however. There is so much activity in the JavaScript
world currently.

I say you should focus on your career and wherever you see that leading you.
To a certain extent programming languages and libraries will come and go (they
will coalesce on principles so this is worth paying attention to), but
architecture remains the same, social structures and positions remain the
same, and sales remains the same. Apply yourself where you can see the maximum
potential for personal growth and personal growth that doesn't slip (as it
will when you have spent 20 years programming using the library X and
everybody else switches to Y.)

------
SonicSoul
I don't agree with this rant. Just becuase 50 libraries exist doesn't mean you
have to be an expert in all of them or even use all of them.

I think it's great that so many frameworks are sprouting up, and once you've
been around long enough, it shouldn't take more than a weekend to try one, see
the benefits, and use it or learn from it and move on.

Since when is having more choice bad?

I've been out of web development for a number of years, and it is delightful
to have all these options now. I am loving working with knockout.js and
looking forward to trying ember next.

~~~
acuozzo
> Since when is having more choice bad?

[http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_ch...](http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html)

------
kenkam
I agree and can see where OP is coming from. As a Chinese, I notice the
difference in how we approach problems. Let me make an analogy:

Chinese and western dude learns guitar. The Chinese player will worry about
the scales, the hammer on/off drills, chord drills, picking drills, and maybe
practice a song and focus on technicalities; western dude would pick a guitar,
learn a few chords to play a song, realise that to play more songs he/she must
practice hammer ons, etc, but everything is so that he can play more songs.
They have never had to worry about drills. It's a means to an end.

Web frameworks are just drills to choose from. Pick the one you need and move
on. With experience, you'll be able to tell what is good and what is not.

Why worry about which framework is "best"? It doesn't matter. If WP template
and jquery solves the problem then why is he even talking about Haskell?

~~~
arash_milani
I think you are generalizing the issue too much. also take a look at the
comment of the original author of the post. he is not Chinese:
<http://news.ycombinator.com/item?id=5206578>

~~~
cygwin98
OP here. Thanks for the tip. I've updated my blog to credit eranation (author
of the original English post) and relevant links.

------
artursapek
1\. Go to Home Depot.

2\. Pick the tools you like. Get a good hammer, saw, adjustable square.

3\. Leave Home Depot and go get good with them.

4\. If something breaks or doesn't perform a task you need, go back to Home
Depot to supplement your toolbox.

~~~
jzwinck
You forgot the laser-guided dado cutter, and the telescoping illuminated wet-
dry vac with AM/FM radio.

~~~
artursapek
Who can spend time in the shop without a nice ball game on the AM radio!

------
rsobers
Marco Arment gave a great talk at Webstock about how he uses PHP and MySQL
because they're battle-tested and he knows them inside-out. I think many of us
could use a dose of Marco's pragmatism. It's worked out _really_ well for him.

~~~
marknutter
I sincerely hope nobody reads this anecdote and decides to use PHP and MySQL
based on it.

------
blablabla123
The original post shows definitely one thing: decision making is an important
skill.

Obviously every framework has its pros and cons. But always focussing on the
cons and restlessy looking for even hotter solutions makes you more worry
about technology choice than about your code. It makes you worry more about
whether you did a sane technology choice than it makes you solve actual
problems.

At the end of the day it is better to focus on one chosen technology and get
the most out of it. If its cons matter, one will see soon enough and learn how
to circumvent. This gives deeper understanding of the technologies and give
tools to solve problems.

------
OldSchool
Maybe part of the problem is that "design" has been forced to merge with
"engineering."

That and everyone seems to want to discover a language or framework like it's
an Indy band. "I was using _____ before it became popular." That credential
and $5 gets your coffee at Starbucks.

Let's face it. If the high-paying gig comes along and, god-forbid, demands
.net or PHP, you're not going to argue, you're going to quickly adapt and get
it done right? That's because all these things solve basically the same
problem and it's a problem that you're used to solving.

------
yjh0502
Maybe this post is the original one: <http://tilomitra.com/the-crazy-world-of-
code/>

~~~
cygwin98
OP here. Added this link to my blog post. Thanks for the tip.

------
readme
I hope that there aren't any actual web developers who think like that on a
daily basis and that it's meant as humor. You don't need to use technology
invented yesterday to write good software. Infact, most of the "blue chip"
technology out there: Java, Python, Ruby, PHP, and the relevant frameworks
used in those languaes (Spring, Django, Symfony, Rails, etc...) is being
updated all the time.

Another advantage of not using the latest, hottest, tech, is that there will
be several gigs of mailing list archives out on the net of people's past
problems (also, stack overflow will be filled to the brim) with answers, to
your common pitfalls.

Go with X.js + HipsterDB and you're gonna have a bad time when you run into a
problem, because it's just so new that you're likely one of the first to run
into it.

The article ended with "I just used wordpress and copy pasted some jquery" --
I approve.

The bottom line is getting shit done, not being a hipster.

------
ChrisArchitect
I like this because it demonstrates the complexity that can possibly be
involved with some serious web development projects. Also, I think it is the
skill/ability to make the decision between these tools and platforms and know
that you only need some etc - is what separates the good educated developers
from the rest.

------
mephju
Yeah, lots of technologies out there.

Personally I consider learning a technology as an investment. And with my
investments I prefer them to be low risk. That's why I only choose
technologies which are definitely going to last a while. Sometimes it's hard
to decide if a particular technology will persist. I usually look for support
and endorsement of big players in the industry and sufficient user adoption.

Right now I am contemplating using angular.js. I think it would be low risk to
learn since it will probably last a while because of Google's involvement and
already wide usage.

Other safe options include Twitter Bootstrap, Node.js, Android and jQuery and
?

I would like to read a blog post about what Hacker News considers to be safe
options to learn. Anyone interested in writing one?

------
octix
Adopting new technologies doesn't always mean you try to follow trends or be
cool. There are plenty of reasons that new ways of doing things come up all
the time(be more productive is one of them). You may start slowly, but with
time it pays off. I mean teams that can evaluate new trends and see if they
get any benefits or not...

I personally think "just ship the damn thing" is BS, I'm pro delivering often,
but good quality of product/service starts in back-end, again I'm not saying
it should be perfect, but it MUST be open for new changes and be ready to
scale... no one wants to wake up and be impotent with number of users they
have, if you don't expect to scale, why are you doing this in 1st place?

------
chrismorgan
As you can see, he hadn't heard of Python.

~~~
conradfr
Which version of Python ? Django or Flask ? Django ORM or SQLAlchemy ?

~~~
lucian1900
There are only two practical choices right now, both for Python 2:

1) Django 2) Flask + SQLAlchemy

Not that much choice, is there?

~~~
chrismorgan
With Django 1.5 (final just about to be released, hopefully within a week)
supporting Python 3, you're not tied to Python 2.

There are other good options, too. Here's one, also conveniently Python 3
compatible:

(3) Pyramid with (a) SQLAlchemy; (b) ZODB; (c) something else—whatever you
want!

I'm actually working on a Pyramid + traversal + ZODB project just at present.
It's very instructive when once you have become used to URL routing and
pattern matching (I've worked with Django hitherto).

------
davedx
I've been wanting to use one of the new JavaScript frameworks on a new
project, after dabbling with backbone and getting lost very quickly trying to
clean up zombie views/events. My latest project is a front end site to a JSON
API, so I thought it was the perfect opportunity, but after discussing it with
my client we both decided not to.

Because I know what I'm doing best in PHP. So the site is going to do REST
queries, but on the backend. We still have the ability to use the API in other
clients, and we could in the future use shinyFrameworkOf2013.js, but for now
we're building something we know will work.

------
thewarrior
Thats the reason why its more important to learn the fundamental ideas behind
the frameworks and not just the syntactic sugar . A deep understanding of any
one will help in easily picking up any of the newer ones.

------
DodgyEggplant
any human (or even nature) domain knowledge is enormously detailed rich, with
countless sub-domains, methodologies and references beyond the scope of a
single person. And thanks god for that.

------
indubitably
I think this is evidence that we’re in a golden age of web development. It’s
the opposite of monoculture, and it’s awesome.

------
jakozaur
<http://zef.me/4235/pick-your-battles>

Pick technologies which are most suitable for the job, not the most "hyped"
ones. Also don't forget that sometimes the latest technologies comes with
innovation tax, you may be the first to solve some issues, because of the
small ecosystem.

------
nej
Architecture is not as important if you're building an app that will scale
slowly. But if you're betting on scalability to make money, then the story is
very different.

Relevant: <http://www.youtube.com/watch?v=rV_GIGzXrvA>

------
jccodez
To quote Jamie Zawinski: "At the end of the day, ship the fucking thing! It’s
great to rewrite your code and make it cleaner and by the third time it’ll
actually be pretty. But that’s not the point—you’re not here to write code;
you’re here to ship products."

~~~
octix
Yeah, I bet he'd say the same thing to his car service technician, just fix
the f*king thing, use duck tape if needed...

------
dgesang
Reminds me of this:
[http://www.gamasutra.com/blogs/SteveFulton/20120926/178364/N...](http://www.gamasutra.com/blogs/SteveFulton/20120926/178364/Not_Flash_The_Still_Angsty_Zeitgeist_Of_HTML5_Technology_Burnout.php)

------
mipapage
Recently redid a WP site a neighbor had for his small business. Single page
flat html using bootstrap. What fun that was! So refreshingly simple.

------
gfodor
Not only can you waste time over-analyzing the number of choices, you can
waste time discussing the choices. Like this thread. Back to work!

------
BigBlueSaw
I tend to pick the environment/framework/library that has the functionality
already written that I happen to need at the time.

------
tterrace
I would try explaining those concerns to a client to see just how silly and
nonsensical they are.

------
arbuge
He left out Basic. Bill Gates is still using that one according to his Reddit
AMA yesterday.

------
pkorzeniewski
Just choose the right tool for the job. Beside that, variety is a good thing,
isn't it?

~~~
coldtea
No, variety also means:

1) scattering of effort (each framework gets less total attention by fewer
people),

2) duplication of effort (besides what is unique in each, tons of effort is
spend in implementing mostly the same things),

3) Many half-finished frameworks

4) Worse documentation and less books/manuals/video tutorials (see 1, 2)

5) Less chances of getting an answer to a framework problem in forums/irc/SO
(again: scattering of resources).

6) Less vibrant ecosystems around the framework (if each of 10 frameworks has
10% of the market, it's not as good a business to invest in making plugins as
something that has 30-40%). Same for hosting offerings, support, etc.

So you want variety but not too much. 2-3 big players would be mighty fine. 10
players of equal size, not so much.

~~~
cygwin98
Agree. The current war of numerous Javascript MVC frameworks reminds me of the
situation of Python Web Framework a few years ago, the community was confused
by so many choices to select from. In the end, nobody wins, even the ultimate
winner Django lost the opportunity to become mainstream. In that sense, the
merging of Rails and Merb seemed to be a wise and successful strategic move in
hindsight.

~~~
metaphorm
Django is pretty mainstream. Its not as popular as Rails but its hardly a
maverick.

I think the reason why Python never went all in on a single web framework is
just because the Python community itself is much larger and more diverse than
the Ruby community. Consequently there were alot more opinions and alot more
people willing to develop those opinions into separate projects.

Maybe you're right that there are advantages to converging on a single
framework, but I'm not so sure. Rails is omakase, so if there's some part of
it you don't like its not really easy or a good idea to change it, and you
don't have any other options in Ruby. Django is also omakase but if there's
some part of Django that you really disagree with you can just move to web.py
or flask or pyramid. these are all built on the common core of Python's wsgi
module so these are just different opinions on how to accomplish the same
task.

~~~
FilterJoe
With Django in specific you can swap out a component. For example, if (like
many people) you don't like the HTML template syntax, just swap it out for
Jinja2 or Mako. In Django it is also usually easy to customize something minor
by use of overrides (OOP).

~~~
kyllo
This is also true of Rails. That's what the Gemfile is--a list of optional
packages that you can swap out. (Almost) all of your configuration happens in
that one file where you tell Rails what packages (gems) you want to use with
your application.

------
metaperl
qooxdoo solved all the problems of web development long ago in a single simple
uniform complete way.

As long as you arent forced to use apologetic strap-on technologies, I see no
reason to look elsewhere.

------
the1
W in Wordpress stands for web scale.

------
adamors
Living in a bubble.

------
snake_plissken
fvckin A+ on this.

------
waltz
how about copy a line?

