The Sad State of Web Development

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.

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.

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.

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.

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.

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.

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.