expr

It is not at all the same definition. A CDN is not a programming language library, which is how I had defined frameworks (with other qualifiers). All frameworks are (one or more) libraries in a programming language. A CDN is, ultimately, a network of running servers that serve up content. It’s a distribution mechanism for content, not a method of building software applications (which is what frameworks are). You can use a CDN to deliver the code for a framework/library to a web browser (or anywhere else, really), but that is not the same as saying that it is a framework itself, because it is not.

A bunch of people in this thread, including myself, have been trying to help answer your original question (part of which is clarifying terms, since you seem to be confused about how things work, which is understandable for someone inexperienced), and yet you’ve been very combative and lashing out at people in spite of describing yourself as an amateur. When experts in the field correct your misunderstandings, it’s wise to learn from the information you’re given rather than telling everyone that they are wrong. Your attitude will not get you very far and will simply make people unwilling to help you learn.

I mean, that’s simply an incorrect definition and not what anyone means when they use the word, speaking as a senior engineer working on web applications over the last 10 years. Such a broad definition is practically meaningless since it encompasses pretty much everything in programming.

A database is 100% not a “framework”, it is a software application that allows clients to retrieve data by supplying queries in a dedicated DSL.

cdnjs is also decidedly not a framework, nor is any other CDN. CDNs are an infrastructural component in networking that allows content to be cached in servers that are geographically distributed over large distances in order to reduce the effects of network transmission time (since content can be served from servers closer to the client). It has very little to do with programming.

A framework is a library (or possibly, set of related libraries) in a programming language that aims to be very “batteries-included”, insofar as the programmer gives up precise control over the program they are creating in exchange for having many commonly-needed things for the task (typically, SPAs or web servers) already done for them. The reason I said it’s perhaps ill-defined as a word is that the line between what counts as a library and what counts as a framework is a bit blurry.

I think you’re using the word “framework” quite broadly here. Cloudflare and databases aren’t “frameworks”. The word is perhaps ill-defined, but generally it means something like “an opinionated library ecosystem in a programming language”. React, Vue, and the like are Javascript “framework” libraries for making what are called Single Page Applications. They are hardly the only way to make websites, though, and some (including yours truly) believe them to much more trouble than they are worth for most purposes.

Laravel, Django, Ruby on Rails, etc. are all backend/server-side “framework” libraries for creating Multi-Page Applications, or in other words, the model for which the web was originally designed (that is, you get HTML and follow links embedded in that HTML to get to new pages).

At any rate, a “file system for a website” is quite vague. It really depends on what your goals are. You have to define what is you’re trying to do and who it’s for. It’s not particularly difficult to spin up an sftp server to allow remote access to files if all you care about is remote copying, but I’m going to assume you mean a file server served over HTTP(S).

There’s about a million tools out there for serving up static files, getting a directory listing, etc., and it really depends on your goals. It’s fairly simple to configure nginx to serve up a directory with a very rudimentary index if you don’t need anything fancy (nginx can do fancy too, ofc, just takes more work than what comes out of the box). I personally like Caddy over nginx these days, though. Caddy in particular requires very little configuration, honestly.

But yeah, without more information about what is is you’re trying to accomplish, it’s difficult to give specific recommendations.

We are far from knowing that true intelligence is possible with the computing paradigm as we know it, and indeed, if it’s even possible to do outside of biological systems. So it does require a revolutionary breakthrough in computer science and/or computer engineering.

I have never argued that it is never possible, just like time travel or teleportation is technically possible given a radical breakthrough in our understanding of how the universe works. But as of right now, AGI/true intelligence/etc. is still purely science fiction and LLMs are not even remotely close (and are a complete deadend towards that goal).

Monorepos don’t really change anything. Squashed commits are still not atomic, unless the MR is small enough to fit into a single logical commit. Changes made to say, a database query are distinct from changes made to route handling, yet both might be needed for the overall feature. They don’t belong in the same commit in history.

And I"m saying that doing with merges (and squashing) what should be done with rebases is bad. You can do it that way, but you shouldn’t, because it makes for worse history and less usable git tools.

Squashed commits are not atomic, unless the MR is so tiny that it logically fits into one commit. This is often not the case, though. It is frequently the case that the overall task requires modifying multiple different systems, which should themselves be their own commits, with tests for changes added to the same commit that makes the change.

A well-crafted MR should tell a story in its commits, with changes proceeding logically from one another.

It seems to me what you are really arguing against is poorly crafted history, which I fully agree is something to be stamped out.

To address the specific commands you mentioned:

1. That’s… really besides the point of git bisect. It’s binary search to find bad commits. If the selected midway point happens to be a formatting commit (which I’d argue should really be handled by pre-commit hooks anyway) and that commit is broken, it just means that the search proceeds to the midway point between that commit and the known good commit.
2. You can revert a range of commits, but the point of crafting a quality history is not doing things like having separate commits for tests. Tests belong with the code that it’s testing.
3. First off, any reasonable usage of git will have ticket/issue numbers in the commits that you can use to look up the full task information. But also, git blame won’t show the rename commit if it’s a separate commit from any changes (which it absolutely should be, due to how git handles renames). And finally, if you care about getting more detail about why the code is the way it is, git blame isn’t even the right tool for the job anyway, git log -L is.

You don’t share feature branches. So you always know precisely what is shared history: the commit you branched from.

The workflow is branch from shared history, rebase your branch as many times as necessary during development to craft a quality history, then merge back.

I rebase dozens of times a day and have never had a single issue with it.

If you’re bothered by repetitive merge conflicts (which, in my experience, are quite rare if you’re doing things correctly), that’s what git rerere is for.

Rebasing is for crafting a quality history of your own commits (or getting your branch up to date with the trunk). Merging is for integrating your commits with the shared history.

Rebasing is not dangerous. You can always go back if something is not to your liking.

You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits.

Keeping a quality history rather than squashing also makes many other git tools much better, such as git blame, git revert, git bisect, and so on.

It’s fine if the changes belong in a single commit. Otherwise, an interactive rebase to craft a clean, quality history before merging is much, much better.

Good, maybe people will use it less.

I really should link people to this site more often. The author is 100% correct.

I don’t use Libre Office, but regardless, I give absolutely zero shits what other people think.

Obviously don’t have the full context, but rarely is it ever advisable to give third parties direct access to a database. There are many reasons for this, like, for example, the fact that doing so makes schema migrations practically impossible.

No one actually copy/pastes thousands of lines of code. We use libraries.

Languages do matter a lot. Yes, they are all technically equivalent, but the craft of software engineering is much, much more about social/cultural/community considerations than it is computational ones. What the community around a programming language values matters, because it informs a great deal about what’s idiomatic in a language, what libraries are available, what kind of bugs are possible (or not), how easy code is to read, comprehend, and maintain, and much more.

What makes a language good is not what programs you can write in it, but how it constrains what you can do such that you naturally writing good code. For example, null pointer exceptions (or segfaults in C, etc.) are a classic problem that plagues many mainstream languages like Java, C#, Python, etc. In Haskell (and a handful of other languages, including Rust), null pointer exceptions are not possible, because nulls do not exist in these languages. Taking away this language “feature” actually increases the power of the language, because you can guarantee that a certain class of common bugs are not possible in your program. So languages that restrict known bad programming practices lead to programmers writing better programs and, more generally, a community around the language that resonates with these philosophies.