[dnautics]

I'd like to add this:

- There's the possibility you will do something very wrong if you roll your own from libraries

For example, HTTP serving frameworks are popular because the HTTP protocol is complicated, not to mention best practices around security that have evolved over decades and are still evolving, and the (ideal framework) will handle a lot of high-level protocol logic (do you really want to parse mimetype ranges and do Accept matching? How about CORS? Cookie signing?) on your behalf, calling into your code only for the business logic.

[lostcolony]

Using the author's definition (necessary when comparing the two) of "I consider a piece of software development technology to be a framework if it dictates the way all or most aspects of an application built using it will be programmed and how the code will be organized, while a library covers only a specific aspect of the system and is usually less opinionated about architecture.", I'm not sure your criticism really holds; Rails is a framework, but Sinatra is a library - both serve HTTP.

Even then, a library or framework can choose to split up functionality and allow you to include it or not based on your needs; even if it doesn't, there's a high likelihood that problems that aren't unique to you already have a default solution (i.e., HTTP serving frameworks/libraries that make CORS, CSRF protections, and other browser only considerations a piece of middleware that is trivial to include if you want it. An example being Spring, where I believe the only place CSRF tokens are supported is in Spring Security).

[dnautics]

Sinatra is a framework, it's very light in that it doesn't dictate where you put your files in directories (but neither does, say Phoenix, which is definitely a framework). In sinatra, the system calls into the functions you write and you have no choice but to organize your endpoints the way that sinatra wants you to, even if some things are light relative to rails.

[lostcolony]

Did...did you miss my callout to the author's definition? Per that, Sinatra is a library. The structure of endpoints is no different than function calls; where they go is not proscribed.

I'm not saying that's a good definition.

[dnautics]

look, "all" is meaningless. What constitutes "most" is a matter of judgement. Sinatra does guide you in your code organization a hell of a lot more than something like, "a json parser library".

[lostcolony]

Sounds like you might be defining library vs framework as "library's are collections of functions with minimal if any state that needs carrying between calls to exposed functions" then. Which is a possible way to distinguish them! Just...not how the author did.

Of course, that makes things like Go's inbuilt HTTP a bit weird; it's part of the standard library, but it also necessitates setting up handlers, which would potentially make it framework.

[dnautics]

I'm conforming to the authors definition, as you present it. Under these criteria, Sinatra is categorically closer to rails than a Jason library. What might an http server library look like? It would have a function that blocks on accepting a socket, a function that parses the socket contents into a data structure, and a function that lets you send a response. That's not what Sinatra looks like, at all. If you make a claim otherwise, you are on shaky ground. Let go.

[chaostheory]

Imo the autHor’s definition of a framework isn’t very good. React is clearly a framework and not a library.