The Sad State of Web Development

https://medium.com/@wob/the-sad-state-of-web-development-1603a861d29f#.mqej2kpqv

by dham • 11 years ago

103 13 11 years ago

brudgers• 11 years ago

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.

im_down_w_otp2• 11 years ago

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• 11 years ago

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_otp2• 11 years ago

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.

ajsharp• 11 years ago

I disagree that investors are the cause, though I appreciate the sentiment. Communities develop from leaders, and the only leader Node & Javascript has ever had was Ryan Dahl. From what I can tell, Ryan blindly applied unix principles to the server in a garbage language. I don't know why he thought that was a good idea; maybe he was just fuckin bored. That sentiment, that tiny is better, was like patient zero, and the frontend community with no leader of it's own, cargo-culted it to infinity.

These idiots literally invented a principle that people now refer to as "composibility". Really it means that your library is fucking tiny and does nothing.

The only form of leadership present in the frontend development community are large companies, like Facebook. So what happens is a developer who works for Facebook inherits Facebook's brand power within the community, and a bunch of junior developers who don't have a clue assume developer X is Uncle-fuckin Bob. Inmates running the asylum.

There is no pragmatic thought leadership in Javascript; only children looking for recognition and a podium at an O'Reilly conference.

habitue• 11 years ago

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.

EvanPlaice2• 11 years ago

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.

geebee2• 11 years ago

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.

AndyMcConachie• 11 years ago

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.

geebee2• 11 years ago

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.

merb• 11 years ago

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.

onion2k• 11 years ago

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.

The Sad State of Web Development

Related Stories