This is really great, and I'm really happy people are finally waking up to this. I've stuck with Django through all of this and never looked back. Nowadays with stuff like HTMX, things have never been better!
Could we do this for CSS-in-JS next please? With React 18 making a strong push for compiled CSS, we have libraries now that let you write CSS (compiled) using Typescript. This is also absolutely crazy to me because we COULD BE JUST WRITING CSS instead (especially with variable support).
CSS has been mangled so many different ways, including the loathsome Tailwind, that I can't imagine what a newb web dev has to plough through these days. Some of us with longer memories were overjoyed to see browsers finally adopting standards after the erosion of Microsoft's reign but now it appears we're intent on destroying the value of what we waited 15 years for. Fer Kreissakes just write raw, unadulterated CSS and enjoy your freedom from the CSS hacks that were unavoidable back in the late 90s/early 2000s.
The worst Tailwind I've seen is HTML littered with a, a:hover etc. declarations on every hyperlink. OK, you can create a global Tailwind stylesheet in your config but doesn't that defeat Tailwind's purpose?
Oh, and that's discounting responsive breakpoints. So if you have 3 of those that can be 3 lots of a, a:hover etc. for every hyperlink. You couldn't make this up.
I prefer CSS. We even have browser support for CSS variables now so what else do you need? Tailwind wipes out half of the features of CSS and replaces them with mindless inline repetition and bloat all in the name of convenience. I call it inconvenience and refuse to work on Tailwind projects.
> We even have browser support for CSS variables now so what else do you need?
Not writing CSS in a different file and have it applied to all my page would be a start. Creating a class for each different component and then writing CSS for that component is not really great. I like the Svelte way where you have your components that have HTML, CSS and JS, and some global CSS too.
> Not writing CSS in a different file and have it applied to all my page would be a start.
Are you saying you do or don't want CSS in a different file? You can have whichever you please. You can put your CSS in style tags on an html document if you want, or use javascript to inject a style tag wherever, that you can write inside a template string, I guess. Depending on whatever templating language system you're using, you can put css in that language's version of style blocks, such as in React or Vue I've seen .jsx or .vue files with blocks of styling code in them (usually just option 2 above with sugar, using js to inject a style tag).
> Creating a class for each different component and then writing CSS for that component is not really great.
You can use CSS variables and basic rules to combine styles if you'd like? I'm not exactly sure what you mean. I mean, the styles cascade, what are you trying to accomplish that can't be done easily by using a universal rule to apply some baseline fonts or what have you?
Wow, I truly hope you are wrong. Non-scoped CSS where you have to come up with names for everything and that doesn't live right next to the markup in the same file as the component is the worst. The whole cascading part is also something I hope I never have to deal with again with conflicting styles being inherited and overridden all over the place. Just let me isolate everything and let me freely copy a component file with all styling included without relying on any global CSS.
In my experience, this is usually solved with more TS/JS abstractions, something like global theming. Often they are hacky and poorly implemented, and always they are leaky.
Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too.
I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on.
Most web frameworks seem to be obsessed with the web platform to the point they feel more like glorified macros, leaking its web gunk everywhere.
Yes, but - if you don't understand how the web works and that it's made of HTTP and JSON and databases, you're probably going to find yourself trying to solve a problem you don't understand very quickly. I've always wanted to build a nice chair or cabinet, but I don't have the tools or the experience. It's not the tool's fault.
There is quite a lot of inherent complexity of web as a platform. If frameworks were any more abstracted they would be too brittle for a lot of use cases.
Btw, use Sorbet for Ruby static typing. It's very ergonomic.
We adopted Sorbet for our codebase a couple of months ago, and I couldn't be happier with that choice. Sure, it's not as powerful as Typescript (e.g. no way to specify a union of constants like `type Result = 'ok' | 'error'`), but it's worth it just for the nil-check alone. And it's great for documenting too. It's easy to forget what type a method expects for its parameters.
Just write a function, use type hints to say what arguments it takes, and throw a decorator onto it. Very similar to fastApi but with the django framework behind it.
You should check out Wundergraph coupled with a backend framework to at least manage the database schema. Check out this video [1] it's so fast and nice.
This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA?
I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million years with Rails than five minutes with most of the React SPA monstrosities I've had to work with recently.
I get it: if you want to build a super-complicated, dynamic front-end, there's only so much you can do with the classic Rails-style approach (server-side rendering of HTML templates with some vanilla Javascript, or perhaps jQuery, sprinkled on top). Once you get past a certain level of complexity I can understand the argument for having totally separate "frontend" and "backend" applications where the frontend is built with something like React and the latter renders nothing more than a JSON API.
But why, why, why has the entire industry seemingly decided that the latter, complex approach is the default, perhaps even the only, way to build a web application? The last four companies I've worked for all used the "separate FE/BE" approach for every app, and at all four companies it was a terrible, unnecessary choice that added exponential amounts of complexity and slowed development to a crawl for no discernible benefit. Time and time again I'd get frustrated because the most simple, basic features would take ridiculously long to finish, be a nightmare to test, and be full of infuriating little subtleties and footguns that made the implementation fragile as an eggshell. Even something as simple as adding a <form> would take ten times longer than I knew it would have taken me in Phoenix or Rails.
And yet when I try to explain that I don't think we need the "separate FE/BE" approach for the task at hand, people look at me like I've suggested we don't need electricity. It's all they've ever known and they can't imagine there might be a better way, or at least one that isn't so agonisingly, pointlessly complex. What's happened to the industry? Why has web development become like this?
Companies are already used to hiring frontend and backend separately, it is much easier to find an expert in either than an expert in both. It is also one of the few opportunities where you can meaningfully split up work. How much of an upside that really brings, is secondary. It already happened.
I do not buy into the YAGNI or in-most-cases arguments. Most cases are interactive applications, not the overengineered listicle websites that would be crap, even if they were not SPAs. If you write an interactive application, SSR will soon make your life miserable. The scrolling document approach to application UI sucks, especially on mobile.
I personally think full stack is more popular than separated roles. They want to hire full stack because you don't really need an expert most of the time, and full stack smashes the two jobs together while paying less. This makes management easier on the surface because you can swing the entire team towards back end or front end work. And of the more capable full stack devs, you can get them to dive into expert topics as needed (JIT expertise).
You do not need an expert most of the time, except when you do, at which point you better have one on board. You can mix and match, but keep in mind that context switches are expensive too.
That is debatable. In the grand scheme of things, politics included, it probably does not really matter. Otherwise, companies not employing this pattern should be at a competitive advantage.
> Companies are already used to hiring frontend and backend separately, it is much easier to find an expert in either than an expert in both.
I think this gets cause and effect the wrong way around. If companies stopped unnecessarily dividing their stack in two, we wouldn't have so many FE developers who don't know how to do anything on the BE and visa versa. I've worked with frontend "experts" who barely know how to query a database. Specialisation is unavoidable, but it makes no sense to me why we need to be that specialised.
Yes, frontend developers often barely know how to query a database, whereas backend developers often create terrible user interfaces, whereas fullstack developers are not particularly good at either. It is a tradeoff.
I've noticed this trend with folks who move from Rails to Phoenix. At some point they switch and then never look at Rails again even if it's been years since they stopped using it. It's not like Rails was frozen in time at 2017 when they stopped using it. There's been 5+ years of progress since then.
Hotwire is one of the best things I've encountered. DHH and gang did a great job coming up with this abstraction and using HTTP for most of its communication. I'm using it today in a fairly big app and it was a breeze implementing it.
Complexity wise I'd put Phoenix Live View at like an 8.5/10 where as Hotwire feels more like a 3/10 since it builds on everything you already know. For creating just about any app I'd choose Hotwire all the time and it's also especially interesting in that you can use something other than Rails as a back-end with it if you want. I used it with Flask in a few small apps. The only server side component is for when you want to broadcast changes to more than the person who made the request but that's optional.
Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though.
Managing any (Literally any) client-side state is also easier with a framework. I'd rather use Preact than write vanilla JS for basic state management.
> Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though.
I've heard this before, and just don't get it. I have, can, and do create view "components" in both Django and Jinja2. They're just templates. Templates that get included in other templates. I've never (never) got to a point where I thought "darn, I want to abstract out this foo thing as a component, but can't". When I really want front end interactivity - like charts - then I'll use a JS library or a web component. With htmx, I can even do partial page updates.
None of that requires the very significant overhead that React/Angular/whatever bring.
>I'd rather use Preact than write vanilla JS for basic state management.
I'd rather use the backend. Because it owns the state, and cache invalidation is one of the two hard things [0].
If you think templates are a substitute for components there is very little to discuss. Templates hide hierarchy, are not easily composable, are not easily shareable (Can you publish a set of templates on NPM?) and cannot easily have complex self-contained logic.
Another big upside of JS components which does not exist in templates is typechecking.
Templates are good if you don't have complex hierarchies and have relatively simple layouts that aren't very dynamic, but they're not the same as components.
JS frameworks have relatively low overhead compared to the total size of most sites. React is ~50kb gzipped. There are also of plenty lightweight options.
> I'd rather use the backend. Because it owns the state, and cache invalidation is one of the two hard things
The backend does not own UI state. If I need to filter or sort a collection I don't want to make a request to the backend. If I need to make a selection I don't want to wait for the backend to respond before the UI updates. And so on.
It does with Phoenix LiveView. And for stuff that shouldn't need to talk to the backend I find Alpine.JS to be a comfortable option that's very lightweight and several orders of magnitude less complex than React.
How have you found the latency to be? Are you shipping in multiple regions? Is this something you think about actively? I know there are ways to optimistically update if you want, but that sort of defeats the purpose imo. (I say this as someone extremely interested in Elixir/Phoenix)
I tried something like liveview way back in the day (10 or 15 years ago) and latency was the killer. It’s probably much better these days with 5G and more efficient refreshing (we did full page refreshes, IIRC). But this is still the reason I won’t use liveview or an equivalent. If you do run into latency issues, you’re in for a world of pain if your entire application is architected incorrectly.
I get that those are the benefits. All I'm saying is that, in my opinion, the benefits you get from building a SPA are not worth the increased complexity it adds, at least for most of the projects I've encountered in the real world.
As someone that's new in the industry: nobody taught any other way. All during college it was Node/React/Mongo, or Node/Angular/Mongo. If I didn't spent some time on HN and learning about the rest of the tech I wouldn't know any better too.
I'll add to that that it's a bit intimidating to jump into Rails/Django/Spring/whatever today, they seem to have been getting more complex with time, and now when learning material is scattered between different versions. Also, having no occasion to do any of them professionally, it's a bit hard to know which one to pick, and take the time to learn them when I'm paid to know TypeScript and its last features.
How do you implement editable list of items where requirements are that:
- editing/creating new has to be in a popup
- people don't want full page reload because they lose context (and have "feel" it beeing slow even if it is not)
- edit-table is not a solution because amount of settings will fit popup
- some things like item name in a list has to be updated in the list after saving in popip which requires two way data binding, because cannot do page reload
- pagination and filtering is required and for same reason as above cannot be full page reload
I don't see how you implement that in a way that is maintainable with "sprinkling jQuery" on it.
I would like to build it with full page reloads which would be fast and would take away complexity but every business analyst or product owner I saw was saying that "users feel" it is slow and they lose context even if list has stable sort and filtering was kept between reloads.
As someone that's basically been forced to build SPAs their whole career, these kinds of comments are always the one I hunt down with hunger in these threads, because the "complaint posts" about SPAs always sound really nice: wait, there's "actual" frameworks (SSR platforms) that take care of all the things I hate implementing for me? Awesome! But then I come to the threads and there's comments like, "cool, but how do you implement {this thing that is one of the ten variations of things I implement in SPAs for my career}," and the answers are always varied but often boil down to "oh, yeah, actually, you should build an SPA for that."
Probably the majority of the internet doesn't need to be implemented as an SPA but I guess I just keep getting gigs for apps that do need an SPA implementation? Maybe I'm self selected for it by working so much in this "niche" of the industry? I have recently been tasked with building out an ecommerce thing and it's finally a time where I'm like wait why would I build this as an SPA, and I've heard that most of the internet is basically just ecommerce sites lol.
Anyway, I would love to see some of the common things I implement in SPAs, and how I'd implement them instead in Django or whatever, cause I'd love to stop having to reimplement cookie and auth management and whatever else these things supposedly give away for free
1. Highly dynamic tables of data with filtering, sorting, pagination, etc
2. Inline editing of a Resource (Widget of some kind) without needing to refresh the entire page
3. Inline progressive forms with lots of logic (one time I had to implement an SQL query generator game)
I am mostly annoyed with people jumping out with absolutes which are fake.
Yes you don't need to make everything SPA - but yes SPA has its legitimate use cases. There will be always bunch of people overusing stuff or using it in wrong contexts but yeah complaint posts are usually written with narration of "all or nothing".
But I also did it in an old Rails app with a bit of jQuery and partials. The modal loaded its markup from an endpoint. Saving was an http post that returned html which I injected into the DOM using some basic sorting / filtering logic. It was… ok, but there was duplicated logic on the front and back ends. I think if I had to abandon SPAs again, I’d probably have the “save” endpoint return the full page and just replace the html each time so that all logic lived in one place. To hell with efficiency— it’d probably be just fine and quite simple.
With Angular it is not even a breeze it is something you have out of the box no questions asked. Save endpoint returns data only for single item on the list and it is updated in place in the list with two-way-binding on return of request.
Great question! I'm actually writing a lengthy blog post on this topic, but it's not published yet. Until then, I think Piotr Solnica has written some really good takes:
And please pardon the self-promotion, but if you're a Rails guy and I can convince you to give Phoenix a try, I hope I can also convince you to try my course on the topic: https://phoenixonrails.com/
There's a lot of programming propaganda that floats around and gets amplified that talk up the advantages of some approach. Often the advantages being discussed aren't even the outcome of the technology, they're just the goals of the technology. Said propaganda will also completely fail to include the disadvantages of the approach. The result is a whole bunch of people who will flock to the new tech, and only 2 or 3 years later will the real story start to come out. The tech usually does have legitimate uses, it's just those uses were niche rather than "everyone should do it this way".
A big recent non-web example of this is NoSQL databases. Endless hype about their advantages. Virtually no discussion about their disadvatages. (In relative terms. It was actually there in absolute terms, I know because I picked up on it. But it was buried for a couple of years in the hype.) Endless hordes of developers switching to them, and confirmation-biasing their way past the first few red flags. Do they have a niche? Yes. Were they massively, massively overused? Absolutely. I've seen projects killed by the choice to use them, and many others switch away from them in a tearing hurry because their systems were coming down around their ears. Would a lot more discussion of their disadvantages been helpful? Who knows. In the midst of a hype cycle sober engineering discussions become a form of betrayal or personal attack for a whole bunch of engineers who too-quickly incorporate the new tech into their personal engineering identity.
SPAs are the same way, and more generally, heavily REST-based backends. Is there a time and a place for them? Absolutely! Are they always the best default organization? Heck no. Do they come with a lot of costs that need to be accounted for with the benefits? Yes.
Stepping up to a stratospheric level of abstraction, outright philosophical astronautics here, I think one of the biggest mistake programmers make is to sit down at some technology decision in which one must weight the costs or the benefits, and implicitly without thinking about it, assign a flat ZERO to some tech's costs or benefits. Most often costs, though the latter can happen. Especially in their earlier years, though even older programmers can get caught up in a hype cycle if they're not careful. Costs are never zero. Benefits are effectively never zero because nobody talks about techs with no benefits at all.
I believe this is best explained with the saying “if all you have is a hammer, everything looks like a nail”. Say you came into tech after jQuery and the like. You know your SPA frameworks/libraries. Maybe you are somewhat lazy at sniffing around for new trends/tech.
You are presented with a new challenge. What will you chose? The stuff you know you can do it with or something else entirely?
I'm working on a web framework in Ruby that works kinda like React/Preact but it's 100% server side, so you can write components declaratively as in React, but you don't need to have separate apps for your frontend and backend. I think it's can be a good approach for many types of apps.
follow the money to understand the decision making; it’s almost always locally rational for some situation that is non-local to you and typically is a higher dimensional problem than you assume.
a good place to start is to ask how the boss became the boss, given that the boss quality inevitably degrades to Dilbert
I've written frameworks, libraries, SDKs, APIs, and drivers.
Most are not frameworks. Frameworks are a lot of work to write and maintain.
The most painful part of writing a framework, is the "rubber meets the road" part, where I suddenly realize that all that TLC I put into developing Guiding Principles, Mental Models, Basic Philosophies, etc. ad nauseam, were for shit, because no one is using my marvelous tool, the way I expect[0], and no one is oohing and ahhing over my masterful implementation. That ends up as a huge smorgasbord, serving a lot of Crow, Egg On Face, and Humble Pie.
> Amal sits down for a one-on-one with Alex Russell, Microsoft Partner on the Edge team, and former Web Standards Tech Lead for Chrome, whose recent post, The Market for Lemons, stirred up a BIG conversation in the web development community.
> Have we really lost a decade in potential progress? What happened? Where do we go from here?
I like using `rails middleware` as an example because it's true, tons of things in that list are important.
A good example of this is: Rack::MethodOverride
Try making your non-JS server rendered view functions and HTML form submissions handle PUT, PATCH and DELETE. Depending on which lightweight alternative to Rails you're using this can become very tricky and you end up spending an entire day of Googling and maybe finding a questionable solution instead of having that available without thinking about it.
> Unless I’m misunderstanding you, this is trivial in every stack I’ve used (.NET, Node, Rails, and Go). I can’t imagine why this would be difficult.
It's trivial in Rails because the middleware mentioned handles it.
Forms only allow GET and POST if you submit it from a browser without JavaScript. That means you need to do things like introduce a hidden form field such as _method with the real method you want to use such as PATCH and then your framework's middleware level needs to understand how to translate that to call the correct function to handle the request. There's all sorts of edge cases around dealing with files and detecting if the request needs to be translated, etc..
Say it isn’t so! :-D Just as an example: When was the last time you read about Angular on the HN frontpage? Basically last decade. Does that mean nobody uses Angular? Hell no. It is extremly widely used by big-ass corps. It’s just that their devs generally aren’t in the HN crowd.
What companies do, what their support cycles are and how conservative their tech leaders are is an extremely heavy influence on the programming languages, frameworks and libraries they will use. You can research in advance and adapt your expectations.
Can you name some companies that are actively investing in Angular right now besides Google? It feels like React has taken over for many large businesses (non-tech focused) because it's "easier" to hire React devs.
I used to work for a company where our manager (a few steps below CTO) was pushing for us to migrate to React from Vue so they could hire more people to come in and help with feature development. We pushed back and afaik the team is still using Vue today.
I’d say 50% of the devs I know use Angular. .NET shops love it. Fidelity and a lot of other financial businesses use it. I’d put money on heavy usage in the enterprise, though I haven’t been in that world in a long time.
Angular core has 3.5M weekly downloads. Quite a lot fewer than React’s 20M but still significant.
Sorry, I cannot, due to a confidentiality clause. Most of my employer’s clients use Angular though, some exclusively. They’re mostly machine tool builders from Germany.
Also, as someone else already guessed, they also all use .NET. This is not a coincidence of course, even though there is no rational argument to be found (“they both use classes!”).
Or they have invested so much into some JS "framework" (most likely React) that they are heavily biased to get this to work properly. Same thing happened at the previous place I worked at.
This made me lol and maybe I misunderstood but, what?
Only once in my career I've come in on a fairly mature project that was, for the most part, done The Rails Way (TM). The code did its boring job quite well and every new place I looked I was able to understand and find things very quickly.
On the flipside, people can definitely lean too much into a framework in cases where it doesn't work and leave a mess, so it it's definitely a fine balance of knowing when to break from convention.
But I have a hard time sympathizing with people who use a framework and break a bunch of its conventions for no other reason because they think they know better (ie, without even trying to make it work). Even if they are among the rare breed who write good documentation, a lot of frameworks out there have really good documentation I've already read. We're just making web apps here, people.
I dislike frameworks for the same reason most of their proponents like frameworks, you can not expect to out-compete all the smart people working together on a common goal. Frameworks are bad at cultivating off-colour ideas, they tend to have a well curated API but are often stuck with a singular architecture. Sometimes the solution is to be found in some lateral dimension. One such example is PostREST, it does away with 80% of API boilerplate by inferring the API from the database schema using functional programming magic. You sort of have to become a Postgresql wizard to get everything out of it, but I feel that this knowledge is somehow more valuable than yet another backend framework.
You just described my last employer to a T, and all because of ego. They kept solving problems that the framework they used already had solutions for. You were actively discouraged from coming up with any different solutions, because the VP of development was stupid and didn’t want anybody changing the patterns he used when they started the company. This included things like “using base classes or modules”, any third party libraries, code linters, database views, and many others.
It was a huge waste of YC money, but the money kept pouring in.
That would rule out almost all server side templating systems, and most non-JSX client side ones (svelte, vue and angular all involve it to some extent) so I don't think that's quite right.
I think maybe you've misread the author talking about the fact that most server side templating systems are fundamentally fancy ways to concatenate text as meaning writing the literal text concatenation yourself without having a library do it for you?
> So half of this blog post has actually been sitting on my drive for a couple of months because I’ve had a good long sad about the distressingly low bar we’ve set for something to bill itself as a Framework. I suppose this is partly because we’ve never really agreed about what constitutes one, and spoiler alert I don’t have a proper working definition either. But let’s get this out of the way first: React is not a framework.
I never got why people care about the difference between a library and framework and try to categorize these offerings, especially when we don't even have meaningful definitions. The way I've seen it, you're usually going to have one front end "base thing" and build everything around it - be it Vue, or React, or Angular, or Svelte, or jQuery, or Next.js, or Nuxt, or JSF, or Vaadin, or Laravel's Blade templates, or the Rails equivalent etc.
In some cases, it will try to provide everything out of the box, in other cases you're going to integrate a bunch of other stuff to do what you want, but you're rarely (at least in my experience) going to have something like React combined with Vue, or Vue with Svelte in the same site, which is sometimes touted as one of the advantages of libraries. I think I can recall one micro frontend project in my past like that. Furthermore, I've seen very few cases where integrated libraries are ever swapped out for something else once there's lots of code written against them, so they get coupled with the rest of the codebase regardless (unless you're really good at establishing boundaries/abstractions), so that's another supposed advantage that doesn't always pan out. And even when you use most of the frameworks out there, you still need to think about UI components and such, of which there are many libraries to integrate with your framework, so you still need additional bits introduced.
It's almost like saying "Next.js acts 75% like a framework, whereas React only provides 25% of what you'd need for a full batteries included experience and therefore will mostly be treated as a library on its own." Silly way of framing it, I'll admit, but the end result will most likely be the same - one big repo of front end code (possibly a sub-folder), regardless of how many packages it's made up of. Just pick a group of solutions that fit your architecture of choice: Laravel, Rails and Django front end offerings are all good for SSR, whereas for SPAs just pick things depending on how much of an integrated experience you want, anything from Nuxt to barebones Vue, with libraries imported based on needs.
Personally, I like the benefits of SSR (how integrated development can feel, easy to reason about), but I dislike the coupling and how you eventually will need to upgrade "the entire thing", which might be a big rewrite (e.g. moving from Spring to Spring Boot, or upgrading Rails/Laravel projects across major versions). I like the ability to throw away and replace SPAs if the need presents itself (AngularJS, anyone?) and the clear decoupling thanks to the API (running the old and new thing side by side is nice for dev). Oh, also SPAs lend themselves nicely for build parallelization, but have the downside of two deployment units (e.g. separate front end and back end containers/packages). Solutions that give you most of what you'll need are great, but only for as long as you don't have to fight against them due to needing to do something different.
The usual heuristic I've encountered is that a library is something where your app code uses it and asks it to do things, and a framework is something where your app code hands off top level control and the framework asks your app code to do things.
Whatever you think of that terminology, I think the majority of available things you can use do fall substantialy into one or other of those categories and the difference in working style while using them is a distinction worth being aware of.
> Whatever you think of that terminology, I think the majority of available things you can use do fall substantialy into one or other of those categories and the difference in working style while using them is a distinction worth being aware of.
I think that the offered terminology is nicely put and should be good enough to describe most cases! However, what we might find is that either it's more of a spectrum than a binary library/framework division (e.g. your example of falling mostly into one or the other, even if not wholly), or that things start to depend on how we use certain technologies.
In my experience, Vue, React and Angular, even Svelte would typically all be used as frameworks, even if that's not the mainstream description of them. The "project" with whatever business logic needs to be implemented would be built within those technologies - using their approaches to components, data binding, validations, routing, state management and so on, possibly by integrating additional bits of code with them, where not available out of the box, still typically with one or two idiomatic (popular) packages.
But hey, regardless of the naming/classification aspects they can all be a good choice (as can Nuxt or Next.js, as well as SSR) for at least certain kinds of projects, as long as some inherent drawbacks of the architectures themselves aren't forgotten about.
Mmm ... while e.g. in React a lot of state libraries are specialised to React, I've had a fair amount of success using e.g. MobX for state management and React as the view rendering layer it was originally advertised at.
But yes, it's not completely binary, hence my saying 'most' a lot - the library/framework distinction definitely has a wide and fuzzy boundary line ala the time years (decades?) of disputes happened because somebody drew a negotiated official border with a really blunt pencil - but I'm advocating the idea that the distinction is a useful way to carve reality at the joints in a sense of "all models are wrong; some models are useful."
Plus, I mean, the 'is it inside' thing would make PSGI/WSGI/Rack/etc. count as a framework since generally they call your application, but they're not really framework-y in spirit on their own (middleware starts to get fuzzier, of course, but I think we're agreed that 'fuzzier' is an inevitably recurring theme here)
Could we do this for CSS-in-JS next please? With React 18 making a strong push for compiled CSS, we have libraries now that let you write CSS (compiled) using Typescript. This is also absolutely crazy to me because we COULD BE JUST WRITING CSS instead (especially with variable support).