Two quibbles.<p>Quibble the first: a language is not a framework. Python and Ruby may be "opinionated" in some sense, but they are not opinionated <i>frameworks.</i> The article's complaints about Ruby in particular...<p>> <i>It dives deeply into the concept of convention-over-configuration, and in doing so, creates a lot of behind the scenes magic that requires a lot of pre-knowledge before using or understanding it well; the true knowledge of its syntax and its behaviors feels more tribalistic to a set of esoteric elders who have taken the time to read the documentation, but is not necessarily friendly to casual beginners.</i><p>...are very clearly complaints about <i>Rails.</i> There's a waggish nod to that ("one could say it has gone off the rails"), but convention over configuration and behind-the-scenes magic are attributes of Rails, the framework, not Ruby, the language.<p>I've noticed this confusion before, to be fair, but it's an important distinction. As someone who genuinely likes Rails but loves Ruby as a scripting language, there are times I think it may have been the worst thing to happen to Ruby. (Well, the second worst, behind Ruby version managers, but I digress.)<p>Quibble the second: "Linux distros are not opinionated, quite the opposite, with each distro expressing itself slightly differently." I believe you could call those different expressions <i>opinions.</i> :) This little footnote on OSes conflates "opinionated" with "locked in," and while we all may have different definitions of "lock in," those things are not equivalent.
Sorry but this is a very low quality article.<p>Calling Angular simple is wrong - arguably it's easier to get started (but IMO create react app gets you close enough - I haven't done frontend in a couple of years with either).<p>C# is not really opinionated - they try to support multiple paradigms (most of the things added recently has been geared towards functional programming), don't have strong style guidelines (even their official guidelines are ignored by popular lint tools/guides), and they keep introducing new ways to do the same thing without deprecating old approaches (eg. file scoped namespaces). Even their standard libraries have plenty of choices, there's immutable collections, they made a large effort to abstract MVC out of ASP.NET, they introduced those new minimal APIs. They support many different technologies that do similar things.<p>Ruby allows so many ways to do the same thing and there's no one preferred way - they alias standard library functions like map/collect or count/length/size - the opposite of being opinionated - it was one of my biggest gripes coming to it. Author probably meant Rails - but the problem there is that many of the defaults are footguns (concerns, fat models, fat controllers, no service layers)
Opinionated frameworks are great as long as you fit the designed use case, you fit their documented and undocumented limits, and the pricing model is compatible with your business model. If you fit that, yeah go for it. However, many don't and find themselves reaching for the more flexible solutions, where yes you pay a complexity penalty, but you can still access the economies of scale of the community and ecosystem. Since so many people across so many domains find themselves in this situation, the flexible solutions get popular.<p>Another factor is people's skillset. As an individual contributor, I want to learn the skills with the broadest possible applicability in order to ensure ensure my long term career opportunities. Anyone that has been around the tech block a few times has seen the winds change a few times and nobody wants to be in the situation of having of a resume with none of the popular buzzwords and struggling for work. This is one big factor why people gravitate towards more broadly applicable solutions and away from more niche opiniated frameworks that have potentially a smaller applicability.<p>The the flip side of that is that I, as a manager, know that any core technology we choose means something I'm constantly going to have to recruit for or invest hugely in training in for so picking the one with the biggest talent pool is going to very tempting. Even if people don't use it the same way we do, I'll at least be able to ask basic and essential knowledge questions in interviews and externalize some of my training costs.
I wouldn’t consider things like k8s and swarms frameworks, they are developer tools/cluster management software. K8s more or less doesn’t get baked into the binaries or containers it runs.<p>What I consider to be the two requirements for something to be a framework are 1. it gets baked into the application/the application is designed in such a way that it fits the mold of the framework 2. it inverts control from the programmer (without inversion of control, it’s just a library). The inversion of control is the problem, and that’s what this post tries to point out without identifying.<p>Also, inversion of control is really only a problem IMO insofar as it unnecessarily obfuscates things. Based on my above definition of a framework, you could say most basic http server libraries (eg the one in the go standard lib) where you add handlers are a framework. But the inversion of control is mostly clear, and you’re not gonna want to ever implement your own http server unless you’re at huge scale, doing something especially weird, or need ultra performance. On the other end you have things like Spring where you basically need to learn an entirely new way of programming with dubious benefits.<p>Also an imperative language is obviously not a framework. (I won’t say all programs, because I think you can argue Prolog is a framework). I’m not sure this person even knows what a framework is. Doesn’t deserve to be on the front page of HN
The SPA frameworks section is completely off-base. React's docs explain hooks just fine ("Here's how we create internal state in a component", you're done), and calling Angular simpler than... well, anything in the universe makes me feel like the author read Tour Of Heroes and thought "oh this is just MVC for the frontend, that makes sense".
I would be extremely careful using an opinionated SPA framework, the switching costs will be extreme if you decide to migrate away down the road. Always strive to pick frameworks that are modular and can be implemented (or unimplemented) over a period of time.
Good article. not necessarily right about everything.<p>I agree with the Angular vs React part. I have dealt with several codebases of both. I do not consider myself a frontend dev, but do understand when a codebase is thriving and when it's struggling. Most react projects that don't have a frontend guru on board are seriously troubled. Most frontend developers are not competent enough to make the right decision. And by no means this is an insult to them: staying on top of the current trends in frontend development ecosystem demands a smart lifelong learner geek. Most of the reasons the normal developers have for choosing react over Angular does not apply to them and their projects. The main exception is the absolute minimum size, and none of the projects I'm talking about ended up with a small enough download size for this difference to matter.<p>So in short, react can give you some benefit in certain situations, but will harm productivity in most realistic ones (my anecdote, of course).
I'm not sure I agree with this author at all. React is extremely accessible. It's the reason it blew up and now has a behemoth of a community.<p>Getting started with React nowadays is as simple as<p><pre><code> $ npx create-react-app
</code></pre>
Follow the instructions, then run:<p><pre><code> $ npm install
$ npm run dev
</code></pre>
Congratulations, you have a fully working React application and development environment. Even more impressively, you can now ship your app and make it available for everyone to use right away using tools like Vercel. Just install the Vercel CLI, go to your app root and run:<p><pre><code> $ vercel
</code></pre>
Congratulations. You've now created a React app and deployed it.<p>Too often I see people complaining about complex React apps when in reality they're complaining about poor decision making while building these applications. No, you don't need Redux, or MobX, or a million CSS libraries. In the wrong hands, any application on any framework can become unwieldy.