[ern]

I agree with you about the need to remain buzzword compliant for jobs, but are we "skilling up" or spinning our wheels? There is some worthwhile learning, but a lot of it is just BS status signaling. Learning another SPA framework that solves the problems of the last framework, while introducing new problems? Learning yet another way to bundle your web content? A new transpiled language to patch the holes in JavaScript?

A lot of what we regard as "skilling up" is just a product of our immature dev culture-learning stuff for the sake of buzzword compliance that doesn't improve anything in the long run. And the high failure rate of software projects shows that we aren't gaining a lot from this culture anyway.

Buzzword compliance is the tech world equivalent of sexual signaling that led to peacocks getting extravagant tails. Developers are stuck in a feedback loop with employers...the more pointless garbage they learn, the more employers value the pointless garbage, and the more developers are forced to learn more pointless garbage. Until they break down, and leave the field to younger men, who perpetuate the cycle.

Fundamental good practices should be learned early on, and honed at work. For the rest, we should work to break the cycle.

[cholantesh]

>Learning another SPA framework that solves the problems of the last framework, while introducing new problems? Learning yet another way to bundle your web content? A new transpiled language to patch the holes in JavaScript?

I understand that HN is (probably?) pretty web-centric, but this portion of your comment makes me wonder if it's just the web that's fucked. I'm not hearing a ton of complaints re: burnout or being left behind from the server-side, database, BI, or embedded spaces. Or maybe I'm not listening.

[thatwebdude]

You're right, it is pretty fucked up. A rat race, really.

I appreciate what parenting has done to me, it's re-prioritized things for me, but it's also shown me that I should make an exit in the next five years, to save myself some sanity.

[geebee]

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.

[cholantesh]

Hey, thanks for this in-depth response. I've generally felt that thinking high-level and not getting bogged down in implementation details is a great idea, but I do try to keep up, only really investing in a technology when it seems established (for instance, Angular a couple years ago, and VueJS now). Occasionally I get restless, and I do feel that tying myself as much as I have to .NET has limited me in some ways, but I guess there's a balance to be sought.

[WA]

This is such a great comment, I had to say thank you. I'm extremely reluctant right now to hop on the JS frameworks bandwagon. I played around with Ionic 2 for a bit and while its nice, they (and Angular 2 and TypeScript) release updates every few weeks. This results in me having to go through code all the time – or leave it untouched for a year. But if I do the latter, I'll run into almost unsolvable problems later.

I wrote my web app in a small self-made PHP framework 8 years ago and it's still running to this day, with only minor adjustments. The advantage is: I understand the entire "stack". In comparison, the current JS madness feels extremely fragile. I feel like it's impossible to write good code in it that'll be around for the next 8 years, when all of those dependencies are either updated to something entirely different – or simply disappeared.

[rev_bird]

I'm way late to your response, but just wanted to thank you for taking the time to write this out. It's probably the most convincing argument against "BS status signaling" I can remember reading.