Do You Really Need a JavaScript Framework?

This is a standard challenge with any framework, but the issue is especially acute in Javascript-land.

Many JS libraries and frameworks exist to cover missing libraries and functions that would be "batteries included" in other languages. As core JS has evolved (along with CSS), the value of those frameworks decreases, but their legacy is deeply present in Github, StackOverflow discussions, and other libraries.

JQuery is one example: a minuscule wrapper around document.querySelectorAll() plus ES6 arrow functions gets you 75% of the way there, without having to understand how/where JQuery is being "clever" in various event handling corner cases.

Bootstrap is another: flexbox is not perfect, but it replaces a lot of CSS cruft and JS hackery.

Moral: above and beyond the usual tradeoffs for framework decisions, make sure the framework/library is still as relevant today as it was N years ago. Don't just go with inertia.

[1] The author's name is "Matt".

For the past several years I've started new personal projects with PostgreSQL+Python+[Flask|Django] on the backend and Bootstrap+Knockout on the frontend. I recently tried to start a new project with React instead, and while the actual act of development on a working React-based codebase is fairly nice, getting it to that state apparently requires a load of dependencies that I simply wasn't prepared for.

I retreated back to using Bootstrap alone for the prototype and found it much easier to work with than I remember. I'm sure part of that is that I've gained a ton of experience since I last used jQuery without a UX framework like Knockout, Ember, or React - but part of it also seems to be that browsers have come a long way since then.

In fact, I'm considering eschewing all front-end dependencies for my next prototype - ES6 has far better support in modern browsers than I recall, as do the more recent CSS capabilities like flexbox.

I figure that at best I'll have a lightweight, clean project that works well enough for a prototype; at worst I'll learn a lot about where modern web standards are.

Frameworks save people time. Not every framework is perfect or maybe 90% of the functionality is never used, but alot of good stuff that solves problems. Maybe the lack of research on your part before you chose something like ember is the real root cause, or maybe the lack of building a proof of concept to determine if ember was the right choice before yapping about your own failure with a framework that you really don't know.

> I wanted to add a full REST API to BugMuncher, even though no-one had asked for it.

> I committed to using Ember before I knew enough about it.

> I didn’t keep it simple, I was stupid.

> Web apps often look complicated from the outsite, but underneath most of what they do is simply Create Read Update Delete, and you really don’t need a fancy JavaScript framework to do that.

So, to summarize, you failed at your first usage of a JavaScript framework due to your own bad decisions. Therefore, all the benefits SPA structure can offer the multitude of other projects is meaningless as, "...most of what they do is simply Create Read Update Delete." Honestly, you've just swapped the bandwagon effect for confirmation bias as you fell back to Rails.

Also, it's possible Ember is bloated. The nice thing about Mithril and some other frameworks is it takes so little to have routing, reusable, components, etc. We're talking 20-30 lines. At that point you are hurting yourself if you have a UI of any complexity and you aren't using a modern approach.

For example if you are using Ember you gain the advantage of a client-side ORM called Ember Data which handles caching and cache invalidation for your API data. Did you handle that in your non-framework application? If you did, how long did it take you to implement? How well tested is it? How many developers besides yourself have reviewed it? How much documentation did you write and how long does it take to bring new developers up to speed on it? If it breaks, who will fix it?

Multiply that by ten or twenty depending on the framework and you start to see what the benefits are.

However, almost every day, I think things would be easy without the framework constraints of projects I've inherited.

Often I subvert them because I don't have time for the ceremony and formalities and instead I have actual work to do.

And 100% of the time, without exception, the result is faster, simpler, and more maintainable without the thousands of lines of framework code and the FactoryFactoryProviders tagging along.

Making things as fancy as possible isn't a virtue. It's grossly inept and deeply negligent. They are the antithesis of engineering. the prime objective is to remove complexity and have direct functionality.

> Having separate codebases for the API, control panel and feedback interface seemed like a good idea, but in reality it just meant more software with more dependencies to keep updated, more tests to run, and a much more complicated deployment process.

Huh? What am I missing here? He made the mistake of creating separate code bases blames it on using a Javascript framework? He could have kept in in the same code base just like using Javascript without a framework.

He then complains about Ember and that's all the explanation we get for why Javascript frameworks are bad. That paragraph didn't even remotely answer the question.

> Even if I was a seasoned pro with Ember, it’s still a case of two frameworks vs one, two codebases vs one, two test suites, two deployments processes, you get the idea.

He makes the same argument again but even worse. Why do you need 2 codebases and 2 deployment processes? You don't. I still don't get how this has anything to do with Javascript frameworks. Sure, you need 2 test suites, but you also do without a Javascript framework.

I do agree that more code bases and deployment processes is more complicated, but has absolutely nothing to do with Javascript frameworks.

Edit: I don't personally use WordPress but saying the stack is LAMP/LEMP so I can work with it. It's just a matter of dealing with the random unclosed PHP tags and figuring out the interconnected classes. It's good for learning how to structure code I still have to use classes myself but assume I need a reason to use object oriented like a video game.

Same with implementing personal GIT server and CI/CD design.

One thing, I imemented defuse/php-encryption recently with memcache was watching the server's htop and see the php-fpm pool requests appear in the processes neat.

So far using Angular CLI, the real time updating is sweet, also the event bindings loops on what appear to be HTML... Yeah gotta spend more time on it this Angular 4 in 60 minutes was a good intro but gotta use it.

It was beautiful.

I chose those tools after boiling my brain over which of the JS Frameworks there was "best" and really couldn't come to a conclusion.

After a few beers one night it occurred to me that maybe I should look for what was "easiest for me" instead and that changed how I looked at it entirely.

Same thought, another example: I like React + its ecosystem quite a lot but often, no, actually most of the times, I realize that I don't need React because the project I am just building is more or less kind of a landing page with some simple UI.

Then, I rather use Pug (former Jade) + Stylus + Node. Super simple, proven and you can go quite far.

However, please do enumerate all the wheels you'll be reinventing if you choose not to.

If you do choose a framework, please make sure it covers most of the requirements of your project. If it doesn't, or you're not sure, then maybe you don't understand something so ask for help.

I'm doing some projects using only React/React Native and static edn files to load the data and it has been a great experience.