In praise of opinionated frameworks
code.mendhak.com
code.mendhak.com
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.
Can you expand on this? I must not have heard about it.
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)
count / length / size are not the same https://blazarblogs.wordpress.com/2019/07/27/activerecord-si...
File scoped namespaces remove an entire useless indentation in most codebases.
File scoped namespaces are better IMO but they are not deprecating the old approach or even pushing you towards it - so not really opinionated.
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.
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.
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.
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
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.
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.
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.
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.
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?
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.
Getting started with React nowadays is as simple as
$ npx create-react-app
$ npm install
$ npm run dev
$ vercel
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.
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.
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.
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”.
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