TL;DR OP chose Ember for a small project, found himself [1] "fighting with Ember a lot", and felt that it would have been easier/quicker to build just a Rails CRUD app in the first place.<p>This is a standard challenge with any framework, but the issue is especially acute in Javascript-land.<p>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.<p>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.<p>Bootstrap is another: flexbox is not perfect, but it replaces a lot of CSS cruft and JS hackery.<p>Moral: above and beyond the usual tradeoffs for framework decisions, make sure the framework/library is still as relevant <i>today</i> as it was N years ago. Don't just go with inertia.<p>[1] The author's name is "Matt".
Reducing complexity in general, especially for new and small projects, is very good advice.<p>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.<p>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 <i>long</i> way since then.<p>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.<p>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.
Does the author have any experience with anything but Ember? How interactive are their interfaces? How does the person responsible for UX feel about only using server-side rendering? Did he/she just do a crappy frontend implementation and is now falling back to a fixed mindset rationalization?
Sounds a bit like crying to me. You built something using a framework and it didn't workout, "so what", rebuild it again. What's next, another blog post about why Rails wasn't right either because of scaling issues? There is no write once and live forever model. Build what you need today, learn, and if you have to rewrite it 10 times then do it.<p>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 used quite an early beta of Ember to build BugMuncehr’s new feedback interface.<p>> I wanted to add a full REST API to BugMuncher, even though no-one had asked for it.<p>> I committed to using Ember before I knew enough about it.<p>> I didn’t keep it simple, I was stupid.<p>> 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.<p>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.
As soon as you are doing more than simple HTML forms, a framework is useful. There are some things that HTML does very well, but you hit the limits on interactive UIs fairly quickly, managing state with plain HTML and HTTP is a pain.<p>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.
I am surprised at the number of people who think they can do everything without a framework and that everything would just be better if they weren't weighed down by the horrible affliction of using one. Frameworks provide real value and while not required for many small applications they can be a huge advantage in large enterprise applications.<p>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?<p>Multiply that by ten or twenty depending on the framework and you start to see what the benefits are.
Here's a relevant post DHH made just a couple days ago:
<a href="https://m.signalvnoise.com/hybrid-development-is-how-we-give-our-teams-of-three-superpowers-2021a84437d" rel="nofollow">https://m.signalvnoise.com/hybrid-development-is-how-we-give...</a>
Absolutely not. I've literally never thought while actually coding in 20 years that something would be easier with a framework, not once.<p>However, almost every day, I think things would be easy without the framework constraints of projects I've inherited.<p>Often I subvert them because I don't have time for the ceremony and formalities and instead I have actual work to do.<p>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.<p>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.
> So what’s wrong with JavaSript Frameworks?<p>> 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.<p>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.<p>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.<p>> 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.<p>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.<p>I do agree that more code bases and deployment processes is more complicated, but has absolutely nothing to do with Javascript frameworks.
Yeah I feel guilty and also not hired full time, currently using plain LAMP and freelance, but I can develop with it. In particular with WordPress, I'm able to open plugins read the code and change/add to them. Speed of development too. But yeah... Starting to learn Angular will decide which PHP Framework... Throw Go in there too. Damn... Gotta catch up.<p>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.<p>Same with implementing personal GIT server and CI/CD design.<p>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.<p>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.
Most likely will get bashed for it, but.. I absolutely love Angular 1. Productivity is through the roof for me. (caveat, I build small dashboards/automation/tooling frontends). And no fancy build process, sometimes I just work off 2 files (1 HTML, 1 JS)
I looked at a lot of them at todomvc.com and decided I didn't want or need a framework. Instead I chose to use Apache web server, CouchDB, PouchDB, jQuery, and Bootstrap.<p>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.<p>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.
Good thought but I am not sure if OP's examples illustrate his thought well.<p>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.<p>Then, I rather use Pug (former Jade) + Stylus + Node. Super simple, proven and you can go quite far.
To answer the question directly, no you do not.<p>However, please do enumerate all the wheels you'll be reinventing if you choose not to.<p>If you <i>do</i> 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.
There are server-side libraries like Unpoly (<a href="https://unpoly.com/" rel="nofollow">https://unpoly.com/</a>) that give you most of the benefits of heavyweight JavaScript frameworks, but without the complexity and code duplication.
Do you really need a backend framework?<p>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.