Quibble the first: a language is not a framework. Python and Ruby may be "opinionated" in some sense, but they are not opinionated frameworks. The article's complaints about Ruby in particular...
> 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.
...are very clearly complaints about Rails. 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.
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.)
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 opinions. :) 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.
Sadly, Rails pretty much is Ruby at this point. I don't think I've heard a company use Ruby for anything other than Rails in like a decade. If they are, it's because they're already all in on Rails, so they might as well keep it in the same language :\
One quite interesting use of Ruby outside of Rails was its inclusion as the scripting language in various versions of RPG Maker, a popular piece of game creation software. The developers of the software are Japanese, like Yukihiro Matsumoto, and I gather Ruby is used in broader situations in Japan than Rails.
I see Ruby used pretty frequently in small parts of larger systems. I looked at a customer’s project last week and they were using Ruby to parse incoming e-mail.
The other somewhat significant use of Ruby that you may have heard of is Puppet. Much less in vogue for infrastructure as code these days but still useful for e.g. managing corporate fleets of Linux laptops.
Yes, which is ironic because python is the language with a lot of magic syntax compared to Ruby. Ruby gives you blocks which you can do a lot of powerful things with, while python creates a magic syntax for many of those use cases (with, decorators, list comprehensions, etc).
If I remembered correctly Rails originated the concept of an opinionated framework, and everybody else copied it to some extent. Yet it's the only platform that the author disses. Maybe this has something to do with the suspicious stuff that happened in the Rails community a while back.
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).
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.
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.
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.
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.
IMHO, using the flexible tool has a sunk cost on it. We choose them for the If's and When's. And the majority of times they never come.
My experience comes from React. My love to it came for the freedom, but once I figure my way of working on it, then I realized that I wanted a comfortable way of doing things in React. And that is something that the community "agreed" in silence, not for nothing next.js is getting the 1# of way of doing things.
With this we are somewhat trading the "flexibility" of React. But this is why I ask myself, what is the flexibility I wanted? I am always going to use the same router library, the same ui library, I wanted an "opinionated way of doing things", my own opinion, but I just liked the flexibility of the api of React.
At the end, I understood that we want opinions, but opinions that match our mental model. With the help of those we can figure efficient doings in efficient time. Because too much freedom gets in the way.
If I were starting today I would directly choose next, instead of trying to make my own framework with create react app, I would choose an opinion with solid foundations like next.
On the other hand, a lot of use cases are an absolute perfect fit.
Desktop software and mainstream OSes are basically opinionated frameworks, and almost nobody aside from hobbyists gets majorly impeded by limitations, they're just so big that they cover most of the use cases just fine.
Like, hardly anyone seems to complain about LibreOffice unless they're trying to use Calc as a database or something. And when they do complain, it's usually something with a workaround that seems easier than using Tex and CSV and a perfect flexible toolkit might be.
If you think in terms of the framework's constructs as your base primitives, you can do a lot in opinionated systems(Just not everything) by adapting your plans to fit the framework.
If you think in terms of underlying abstract logical ideas, the way a programmer building his own in vanilla JS, you'll probably be disappointed by frameworks that only give you a few high level blocks.
But how to implement something cleanly with only high level black box primitives is a skill nobody seems to focus on, everyone seems to think on a pretty low level when designing, and then choose a framework that lets them fit their ideas, and apply ugly hacks rather than do what the framework says.
Libraries are servants, frameworks are like managers.
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.
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.
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.
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".
Why are they called hooks in React though? I have a hard time associating meaning with it, given the way React hooks behave.
And I really dislike React hooks because it is so, so "viral" to the code base - "viral" in the sense that any non-component that uses a hook must also be a hook; and so, before long, either the majority of your application code becomes hooks for no other reason than the fact that you want to use a hook deep in the call chain, or you take the hook out and keep passing the argument down.
Because they "hook" into the component lifecycle. Which is why I'm not sure I understand your complaint... hooks are meaningless outside of a component because there's no lifecycle to hook in to. If you have plain-old-javascript with a hook in it something is not making sense.
> Because they "hook" into the component lifecycle.
For me, "hooks" in other frameworks/libraries that I have encountered don't work like that. Usually, the hook is something static and predefined by the framework/library, and _my_ code attaches to those hooks. The way you explain React hooks sounds like we're _conjuring_ hooks in the components willy-nilly, and then attaching things to them. However, I have never found an explanation for the name "hook" in the official React documentation; the explanation might be somewhere in the documentation, but I never found it.
The majority of third-party hooks that I see use useState, useEffect or useContext, which hook into the React lifecycle of the component they are used in.
If they aren't using one of those (or more rarely one of the other built-in hooks), then they probably don't really need to be hooks and should just be plain functions.
> And I really dislike React hooks because it is so, so "viral" to the code base - "viral" in the sense that any non-component that uses a hook must also be a hook
I've actually voiced similar concerns in the past, though also about the fact that they can lead to render loops that are hard to debug in more non-trivial use cases, vs a simple shouldComponentUpdate method: https://blog.kronis.dev/everything%20is%20broken/modern-reac...
Of course, we are certainly in the minority and many people seem to enjoy React with hooks more than most other solutions out there. That said, personally i think that class based React, Angular or Vue are all (sometimes) more pleasant to work with and reason about. Then again, i prefer the likes of MobX to Redux as well.
The tutorial for React doesn't touch on Hooks at all, and reading the hooks main documentation: https://reactjs.org/docs/hooks-overview.html does a poor job of introducing them to someone who doesn't know what the concept is, I think the explanation is "too dense" and relies to heavily on the description to convey meaning, when it simply doesn't do that. I think they just need a simpler approach to explanation. I felt like I needed to re-read it a few times to get what it was talking about, which isn't a sign of good documentation.
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.
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.
So in short, react can give you some benefit in certain situations, but will harm productivity in most realistic ones (my anecdote, of course).
> Most react projects that don't have a frontend guru on board are seriously troubled.
You know, I think the React hype has truly ended when the recurring theme I keep seeing on Hacker News is that React is bad. I'm thinking maybe it hit critical mass and this is the reason I keep seeing statements like this.
> staying on top of the current trends in frontend development ecosystem demands a smart lifelong learner geek.
Am I the only one who thinks frontend development is, like, actually not that hard whatsoever?
I think it’s self evident that React has won for the time being, so there’s no point in evangelising it anymore.
But let me just say: I love Next.js. More opinionated than React, but almost no learning curve and solves probably 80% of the things that bug me about React.
Remix looks cool, look forward to hopefully trying it on a small personal project sometime this year. The main issue with React is the things it doesn't give you, and these frameworks are beginning to solve that quite well.
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.
Getting started with React nowadays is as simple as
$ npx create-react-app
Follow the instructions, then run:
$ npm install
$ npm run dev
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:
$ vercel
Congratulations. You've now created a React app and deployed it.
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.
Have you gone through both the React and Angular tutorials on each of their respective sites?
The angular one is far and away a much more detailed and useful tutorial than the React one. During the React tutorial on their site, I felt like I was being led by the nose towards competency and if I wasn't competent by the end it's my fault. Meanwhile the Angular one appears to give you some understanding of the angular concepts by the end.
At the end of the react tutorial, I feel confused and I'm still wondering what "hooks" are, as I haven't seen them mentioned once in the React tutorial. I tried your commands to setup a react site locally, and all I got was a web page showing React logo with a link to.. Reactjs... Meanwhile, the angular demo at least gives a little helping hand in building an app.
Your premise about poor decision-making is pretty spot on. I just wouldn't call React very accessible; As I'm definitely the target market for React and the process of starting the tutorial for React resulted in some NPM errors and a pretty useless demo site.
For what it's worth, I had the opposite experience learning React vs. Angular from the official tutorials. In React, there was a particular mental model that the tutorial aims to convey, and once I got it things started making sense pretty quickly. Angular had just so many details, the motivation for which isn't obvious at first, which made it just a little too much at once and I wound up bouncing off.
There is a particular problem with the React docs at the moment, which is that they still haven't decided what to do about hooks. These were introduced as an entirely new API that was competing with the old class-based one that React developers were familiar with (i.e., they do the same thing, but in a different way). So the way they handled that was by leaving the old documentation using the old class-based API intact, but also made a whole separate section entirely about hooks and how to do things with them. (I wound up largely reading the two in parallel and ignoring the details of the older class-based API; I found hooks easier to learn for the above reason, that there are fewer different complicatedly-interacting details to try to figure out all at once.)
I can't imagine that the long-term plan is to just keep things like this, since it's so obviously suboptimal, but perhaps it's difficult to decide what exactly to do.
It’s a difficult situation. A new React project should obviously use functional components and hooks. But there are still large code bases that use class based components, and I don’t see that changing too soon, so it needs to be taught.
Imo the docs/guide should include all the old stuff, but at the end and with a big warning saying “here’s the legacy stuff”.
After working with Angular 1.x for four years in the beginning of my career, I have very little appetite for Angular. And a detailed tutorial is only half the battle IMO.
The last time I attempted to use Angular 2, which was around 2016-2018 (don't remember the exact date) I just couldn't wrap my head around the new mental model: it wasn't Angular 1.x, but it also wasn't React. It used TypeScript and TypeScript decorators, and to me that seemed really heavy handed. I also wasn't used to the mental model of "use the CLI to scaffold files" such as models and controllers, and all of that really turned me off.
Nowadays things look a bit different. TypeScript has significantly improved and it really is a pleasure to work with. I'm also open to different kinds of coding styles, so maybe I'll give it a shot. But honestly? React is ubiquitous at this point. And Remix and Next.js are far more interesting to me than Angular.
- Spring Boot: by far the most popular and has a large amount of nice integrations for most of the functionality that you might possibly want; also kind of complex and a pain to debug in non-trivial cases
- Dropwizard: a combination of many popular libraries out there with a common core to make it a proper framework, takes a bit of getting used to but is also rather nice to use
- JHipster: a pretty interesting take on the idea of generating lots of code from models, close to Rails scaffolding in that regard
- Eclipse Vert.X, Helidon, Micronaut, Quarkus: a bunch of smaller frameworks/libraries that might be easier to wrap your head around and offer alternate paradigms or ways to do things; sometimes not quite "idiomatic Java" but also can be way more performant than the likes of Spring Boot
Quibble the first: a language is not a framework. Python and Ruby may be "opinionated" in some sense, but they are not opinionated frameworks. The article's complaints about Ruby in particular...
> 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.
...are very clearly complaints about Rails. 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.
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.)
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 opinions. :) 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.