| HN Mirror

Every now and then, things go haywire in the web world.

The last time I recall feeling this way was 2005-ish, when Java frameworks took off. Previously, small to medium sized java apps used servlets, jsp, jdbc, and something along the lines of the "java cookbook."

It was, in fact, inefficient, with lots of typing, and it was difficult to manage dependencies. I think the work that went into dependency injection, ORMs, MVC frameworks, and so forth was undertaken by smart people.

The result, unfortunately, was close to fatal for java as a language for small to medium sized web applications. Spring, Pico, Struts, Struts 2, Spring MVC, iBatis, Hibernate, Spring JPA, Wicket, Stripes, Tapestry... just to be clear, I understand that Java frameworks are no longer this chaotic, so I don't mean fatal in the sense that it never worked. I mean fatal in that this was the moment that I, and a lot of people who quietly enjoyed java and felt embarrassed when people made fun of java devs (blub programmers) here on HN reluctantly joined the chorus and gave up on it, never to return.

People complain about the complainers, asking why choice is such a bad thing. The problem was, getting any of the choices to work nicely together was a challenging. All of a sudden, something as simple as a crud front end became extremely challenging. I lost a lot of time and become, not exaggerating, very unhappy during this time. It made me not want to be a developer anymore.

I believe we are now in a similar time with javascript frameworks. It's not that these frameworks aren't addressing an important problem, intelligently. It's simply getting a basic crud app up and running is tough, and making the inevitable modifications to test, alter, implement business logic, and so fort, is vastly more complicated in SPA frameworks with some other backend than it is in, say, Rails. That doesn't mean these frameworks are the product of poor design or bad developers, it's the opposite. These are the product of exceptional people working on hard problems. But if you don't need it, you're putting yourself in the path of tremendous complexity and churn, for very little benefit.

If I learned one lesson from 2005, it's to have the conviction to stick with old, outdated technology, for longer, even when people are telling you it's wrong and out of date. I knew in 2005 that writing your own jdbc and routing around through Servlets wasn't going to be the right way to do it for much longer, but that doesn't mean you have to use the first round of frameworks that addresses this! Eventually I hopped over to Rails (a lot of people here on HN think rails developers picked it because they were magpie developers, I'm not sure how many people realize a lot of us picked it reluctantly, only after it really became clear that the time invested in a new framework would pay off).

And that would be my advice now, if you're free to make this choice. Stick with integrated systems, and pick one that is clear and well researched. If this isn't a possibility for you because of your requirements, then yes, by all means, do use (what I heard Ember described as) a rapidly evolving hack pad for brilliant developers working on extremely difficult problems.

Otherwise, watch, observe, try things out, but I'd stick with a better researched and integrated system like Rails, add javascript as needed but sparingly, Just because you know you won't be doing it like this forever doesn't mean you have to stop doing it like this right this moment!

And be aware, the solution to the java churn for many of us (myself included) wasn't that a winner emerged, it was that with a loud crashing noise, a different solution that addressed these problems swept them off the table.

I wouldn't be at all surprised if something like that happens here. The existing MVC approach is still a bit deficient with highly synchronized apps. Current advances in Rails 5 make it possible to do some of this... but (and now I'm really making guesses), I think that non javascript languages, transpiled to isomorphic javascript, may lead to highly productive integrated frameworks that finally tip the reluctant ones, like me, to give up on our older ways of doing things and finally make the plunge.

This may turn out to be so effective that people take a look at tons of javascript code, written in framework specific ways, and start wondering how to get it back over to ruby, or python, or many of the other wonderful languages that have been temporarily sidelined. You may, in fact, be better off having a code base in an older, more dated framework, that gives better clarity than the current, more modern javascript version would give you.