11–20 of 550 posts
From the author’s About page: “I mostly work with Ruby on Rails. A professional, Open Source platform which powers enormous (e.g. Twitter.com) and tiny applications.”
I think quotes - 'framework' - would be better, both here and in the OP; we can fix one of those.
From the author’s About page: “I mostly work with Ruby on Rails. A professional, Open Source platform which powers enormous (e.g. Twitter.com) and tiny applications.”
2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a complex monster.
3. If you have a small team that hires slowly, it's relatively straightforward to bring new devs up to speed on "the way we do things." if you are hiring rapidly and/or have a large team, the more bespoke things you have, the harder it is to maintain them.
4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries.
5. My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes.
Using libraries and frameworks is like a business outsourcing things that aren't its core competency and also aren't competitive differentiators. Most software shops do not win by having their own framework or by not having a framework, they win by using something bog-standard and saving their attention for the part of their code that "moves the needle."
But that's only "most," and your business may be one of the few.
Before you comment with "So you want us to write everything ourselves?", make sure you read the paragraph that starts with "Many people will argue that not using a framework means write everything yourself. This is a false dichotomy."
Indeed. This excerpt from that paragraph is a good thesis for the essay as a whole: > The point is not to never use frameworks, but to isolate them. To call them from a single place. One that we own. That we are responsible for and that we limit very much in what it can touch.
I don't want that. I want (maybe, at my discretion!) to add your framework as a dependency, read some API docs, and just start plugging it in where necessary.
But they all focus on greenfield projects, they all think the whole project is about/driven by them.
It matches TFA, but I think 'Framework' in that capitalisation (incorrectly) implies it's about Framework ( https://frame.work ) the company. I think quotes - 'framework' - would be better, both here and in the OP; we can fix one of those.
https://en.wikipedia.org/wiki/Framework_(office_suite)
I still think about that suite, because it had a certain kind of elegance: Everything was frame, and therefore text documents and spreadsheets were frames, and you could embed a frame in a document, which correctly implies you could put a spreadsheet in a text document.
But the cells in a spreadsheet were frames, and therefore you could make a hierarchal spreadsheet, or put a text document in a spreadsheet's cells, and so on.
It had a "frames all the way down" philosophy that appealed to me, although the implementation was hobbled by the (to us) obvious limitations of the technology of its time.
From the wikipedia link:
The spreadsheet program was superior in its day, offering true 3D capability, where spreadsheets could form an outline which can be "opened" to reveal a separate spreadsheet, as well as other frame types — a feat of sheer convenient function never again seen and further enhanced in later versions.
Framework's built-in interpreter, the FRED (Frame Editor) computer language, was based on Lisp eval function. It can reference all frames and types across the product and can sense and perform all user interface operations.