So, in an attempt to solve framework fatigue, you introduce a competitor to MEAN? :)
Mattias Petter Johansson
281

Mattias, I’ve edited my original post to clarify the purpose a bit, since that purpose seems to be getting lost on some readers including you. I’m not solving JavaScript Framework Fatigue for anyone but myself. I’m documenting where the path that I took on that journey finished, just in case there are others who like me don’t quite feel that the current popular choices quite satisfy their desire for that critical base from which to build.

It’s for the folks who are seeing Angular/React everywhere, and are getting a bit frustrated that others seem happy to go deep into development with those libraries, while it doesn’t quite seem like a good fit in their case. I think web development has solidified this year into those who are happy with Angular+React (or some of the others popular choices like Meteor or even Sails), and those who are not happy with that and are still looking for the next better thing.

If you’re not using Angular+React at this point, you’re probably going to welcome this article more than if you are using them. It’s for those people. It only shows where my path led me. It solved my JFF and allowed me to go deep into a new project that was being held up pending final decisions on what to use.

“My years as a developer has taught me that every app, company, problem, and even person is different and will have different requirements. Instead of going in this constant hunt for the best generic tool, strive to understand your problem context, and then go out researching tools.”

Exactly. And I just quickly posted a summary of the results of that research. I’m sharing my results. If you don’t like them, don’t use them. They may not be for you, and I’d bet my choices are suitable only for quite a small subset of web developers. In my case, my three+ decades as a developer have taught me to focus on what works best for you, take each project separately, and to avoid being critical of others because you can never know what they’ve already been through and learned, and just can’t know their story. Mine is that my professional career as a server software developer began in January 1984, at Bell-Northern Research. That makes me a very experienced veteran developer, but in this industry that’s actually a liability. It often leads to being stale. It’s a dynamic industry and there’s a ton of new learning to be done constantly. Maybe you have less JFF because you have less dev fatigue in general; at my age (50s) it’s all I can do to try to stay somewhat informed of what choices others have made, so that I can investigate and find out if I might be able to learn something from their experiences; and typically this is from the keener younger guys with more energy and brain cells remaining, who at least seem able to keep up more easily.

“I don’t want to put down your efforts, and applaud your effort to contribute, but I don’t think that JavaScript fatigue is caused by a wealth of options or a lack of leadership and standardisation around tooling, it’s caused by an attitude of trying to find an optimal set of tools without defining your problem first. Doing that does not work well, and will make you sad.”

Now that is sad. Regarding being critical of others without enough information to do so: case in point, your clear assumption that I didn’t define my problem first. Is that because of the article? Because you felt that if I didn’t post a requirements doc that there must not be any? You didn’t think the article was already way too long? Or notice that part of my excitement was that I had found a small number of core technologies upon which to base multiple projects I had planned? It’s pretty clear in the article (especially in the data persistence paragraph) that I’m talking about multiple projects, with different needs and trade-offs. Yet you want to criticize me for reaching conclusions without defining my problem first? In bold? I think you have some maturing to do yet. I wish you well but I hope you learn that uninformed criticism of others rarely goes well (if ever).

Show your support

Clapping shows how much you appreciated Appurist Software’s story.