
The Sad State of Web Development - dham
https://medium.com/@wob/the-sad-state-of-web-development-1603a861d29f#.mqej2kpqv
======
AndyMcConachie
I agree so much with this article. Especially the cursing. Modern web
development regularly makes me curse, and it's comforting to see another thus
frustrated.

I think this comes down to a common problem with software in general. Software
is easier to write than it is to read. This leads to sophmoric software
engineers writing more than reading, since it's easier. This leads to the
wheel being reinvented again and again.

It doesn't help that most developers don't have any formal training. And the
morass of informal hacker camps don't really teach proper structured code
design. SW engineering is about managing complexity for the future. And no
matter how hard people might try, efforts to turn SW engineering into a
configuration exercise will eventually fail for everything but cookie cutter
projects.

To take something like JS, whose inventors all largely agree is a terrible
language, and continually patch it with more half broken, ad-hoc crap is an
exercise in sysiphean masochism.

~~~
geebee
To me, the really depressing thing is the way that JS development is becoming
required of all web aps developers. It is so dominant on the front end that
you really can't avoid it.

Even worse is the notion that because it's already on the front end, why not
write the whole thing in JS? So now, javascript becomes the only language for
the backend as well. It's not just Rails and Django that go away, it's ruby
and python.

I don't think that'll happen, like I said in a different comment, I do think
that isomorphic ruby and other languages transpiled to javascript will play a
big role in the resurgence of a lot of good languages that aren't javascript.

Even if that's not the mechanism, I am pretty much 100% sure that other
languages will reassert themselves in time.

------
brudgers
I'm sympathetic to the overall take. But people aren't stupid. This stuff is
hard. Facebook built React as a solution to Facebook's engineering challenges.
If your website runs at Facebook's scale, it may not be appropriate because of
all the decisions you've made that are different from those that Facebook
made. If your website doesn't run at Facebook's scale, it may not be
appropriate because your website doesn't run at Facebook's scale, isn't
dependent on a graph database, and doesn't need near real time updating for
billions of feeds.

The problem is that the tools market is not clearly segmented. It's a car
dealership that sells rollerskates alongside cruise ships. Google's Angular
sit's next to Fred's Freshman Front End Frame Work in the Node Store...and one
week The Changlog covers Angular and the next week it's interviewing Fred so
that the content stays fresh and relevant.

When Hanselman says "We're all amateurs" he may be wrong but it's a charitable
place to start.

------
habitue
Imagine being a naturalist and observing this behavior in the wild:

"Wow, these developers have a really fertile experimental ecosystem. Why are
they doing this? It looks like they're reinventing things over and over again.
It looks like they are doing some things worse (than I would) on purpose! What
puzzling behavior! Perhaps there are some interesting incentives causing them
to do this... Perhaps there are good things that result from this behavior...
Hmm let me think about it. They must be very strong reasons if so many
developers are engaging in this curious behavior."

Now imagine the author in the field:

"Just grow hands and pick that thing up you dumb birds!" (JavaScript has an
anemic standard library)

"Why are you all trying to break an acorn open in different ways? Standardize
on something you idiots!" (If there were one true way that instantly convinced
everyone, the variety in library design would go down.)

JavaScript development has a lot more to do with path dependence than perhaps
other more modern languages do. The language itself doesn't constrain your
strategies in the way, say, Java does. You can create object/class
hierarchies, or you can use closures to encapsulate private state.

You can use jQuery to manipulate the exact piece of the DOM you're interested
in, but maybe different oarts of your code clobber each other's changes. Or
you can use virtual DOM techniques to create the DOM you want in one go, but
spend more cpu generating a diff.

You can use grunt which is purpose built for assembling js projects, but
requires learning a big configuration language. Or you can use gulp which is
"just JavaScript" but is more complicated to configure.

My point is that the JavaScript ecosystem doesn't have all the answers yet,
and they're looking for them. Closures, prototypical-inheritance, async io...
this language is pretty unique and there isn't a template to go off of. (What
other language has a DOM? What the hell is that?) Every time someone just
attempts to emulate another language's solution, inevitably they leave better
solutions on the table by ignoring what JavaScript is capable of.

~~~
EvanPlaice
A monolithic standard library would be ideal in a utopia where nothing changes
over time.

Unfortunately, the reality is much different. New technologies, new
approaches, new constraints are introduced all the time.

Monolithic architectures grow to the point where they eventually collapse
under their own technical debt. Unless, there is a very active core of mai
tainers that aggressively deprecate old APIs over time.

Javascript doesn't try to be the end-all be-all solution. Ot provides an blank
slate and a decent set of standard tooling for devs to build and compose
modular components.

Sure, the degree of experimentation can get ridiculous at times but nobody is
forcing you to use the latest/greatest modules/libraries. Nobody is forcing
you to transpile to ES/Typescript/Clojure.

You can totally get away with creating static table based layouts in FrontPage
if you want. Except, the devs using all those fancy new tools will be running
laps around you and producing. 100x the output.

There's no doubt that JS could use a better foundation as a language and much
of it is coming in ES6/7\. Managing complexity won't be so difficult once the
module loader standard is available. JSPM already provides a leek into the
future.

It's kind of ironic that you use a naturalist as an example. If nature
followed a centralized monolithic design approach (ie intelligent design)
rather than natural evolution, Earth's atmosphere would still be nitrogen
based and we wouldn't exist to axe grind over the minutiae of programming.

In fact, I'd argue that monolithic design has had great success in spite of
resource scarcity because Moore's law hadn't reached a ceiling yet.

------
im_down_w_otp
I'm pretty sure all this complexity for complexity's sake is directly
correlated to the pattern of satisfying investor demands for justification of
money raised, which then leads to massively overhiring all sorts of engineers,
which then leads to a lot of implicit and/or explicit "make work" necessary to
provide the illusion of productivity.

~~~
sjmulder
Maybe some of it also has to do with curiosity. Web development isn't the most
fulfilling work intellectually, and when I find myself drawn to interesting
ideas I want to play around with them somewhere. Of course the cookie cutter
web app I maintain feels like the perfect candidate.

~~~
im_down_w_otp
I'm not sure I follow. This is what I heard:

1\. Template composition + event handlers is a solved problem.

2\. Solved problems aren't interesting problems because they're already
solved.

3\. Churning the superficial shape and structure of this solved problem into
ever more fractured and complex abstractions keeps it interesting.

?

~~~
EvanPlaice
AngularJS is a prime example. Two-way data was a solved problem until people
realized it wouldn't scale.

Single Page Applications solve a lot of problems (ex better UX, offloading
load from the server, better separation of concerns) but they introduce a lot
of new ones (ex SEO, UI unresponsiveness, etc).

This is the steady and painful march toward progress. Add new functionality,
identify the weaknesses, ditch the useless functionality, recycle the good
parts and start again to test new assumptions.

------
onion2k
The solution is really simple - pay for support. If you rely on some mission
critical thing that you can't (or won't) work on yourself when the maintainer
gives up, then pay someone to do it for you. Hire someone. Pay the original
maintainer to carry on with it if they're open to that. Give NPM money to host
a private library of the things you need. If you build your stack on free
tools without engaging with the people who support them, and then they stop,
then you have no real grounds to moan. "That guy didn't want to work on the
thing I need for free any more!" is not a valid complaint.

------
geebee
This is a rant, but I feel the author's hurt, and it helps me a bit to read
it.

Here's my story, for whoever wants to read it. I started programming for the
web in the late 90s. At first, it was a jumble of __P languages (JSP, ASP,
PHP) and a database connection, kicking out HTML, with an odd bit of
javascript. It got more organized, with libraries and cookbooks.

Then, an interesting thing happened. In 2004, the java web programming
cookbook became obsolete, but everything was a framework. Struts was the first
one. Then, an explosion. Struts, Struts 2, Spring MVC, Tiles, Wicket,
Tapestry, followed by DI frameworks like Spring MVC, Pico, Google Guice, and
lots and lots of ORM frameworks, Hibernate, iBatis, JPA…

Programming, for me, became miserable, as in, I didn't want to be a programmer
anymore, because everything was insanely complicated, and not in a good way.
Not complicated like fascinating data structures and algorithms, more like,
complicated in that it is insanely difficult to write a to-do list. As another
college of mine (who passed a notoriously difficult CS curriculum at Berkeley)
said, "reading about spring DI makes me want to turn off my computer and go
home."

Rails, to me, was truly wonderful. Even rails was a bit tricky to pick up,
since I was used to a very loose way of doing things (Java, Servlets, JDBC,
and use a library and/or figure out everything else as it comes up). But it
was worth it, it kept things organized, and most importantly, simple was
simple, and enjoyable.

I went through a blissful time where things were good for me again, and now? I
haven't felt this way since 2005, but it's been 10 years, so yeah, I guess
we're due for another massive disruption. There is a ticker on the web
counting the days since the most recent release of a javascript framework.
Ember, Angular, React… you know, they're the product of very intelligent
people, but simple isn't simple anymore. Remember "agile development with
rails?", which fictitiously took us through a meeting with a client where we
built software right there in the moment? Long gone.

I've said this a few times here on HN - I expect all this to be swept off the
coffee table with a great crashing sound. Just as I had no idea rails was in
my future, something else like that is in my future too. Right now, I wish I'd
had the courage (maybe even the anger) to stick with the older stack and get
things done, and refuse to get caught up in something so chaotic. No, that
doesn't mean refuse to change, it means refuse to change unless it makes a lot
of sense.

My tenuous prediction is that isomorphic ruby (and other languages) transpiled
to javascript will change web programming so much that the Javascript
framework chaos will most likely end with a very different and unanticipated
approach.

------
merb
I need an SPA, but I still agree with you. Currently I'm unhappy about the
SPA, but an SPA could also be built without a Framework and sometimes people
built internal apps, there are good use cases for a SPA.

