He likes to generalize the kinds of problems he has with Rails and Rails-like frameworks to all frameworks. This seems impertinent, since Rails-style frameworks are a particular style/flavor of framework, those of which I'm sure experience the problems he describes, but more generally? I'm not so sure about that.
Using a framework will harm the maintenance of your software
51–60 of 550 posts
Re: Using a framework will harm the maintenance of your software
#52I decided not to use a framework. I spent about a month going over the "TodoMVC.com" demos with the intent to choose one but after a few weeks of pondering which one I concluded I didn't want to invest in any of them.
jQuery and Mustache.js do a lot and are easy to use. CouchDB and PouchDB are too and that gave me user authentication, a powerful server side DB, and offline-first/local-first features.
I've never regretted those decisions but I had no investment in SQL DBs. Over the years since I've seen other's who've did struggle with CouchDB and I get that. I came from using CGI.pm's "Save" and "Get" functions and CouchDB/PouchDB.js are similar in how you use them, but way better.
Re: Using a framework will harm the maintenance of your software
#53Unless the framework you're using treats maintainability as a feature [1], not an afterthought.
This is really just a long argument against bad framework design (which is fair), not frameworks.
[1] https://github.com/cheatcode/joystick#what-distinguishes-joy...
Re: Using a framework will harm the maintenance of your software
#54> Many people will argue that not using a framework means write everything yourself. This is a false dichotomy. We can use libraries and frameworks just fine. ...
> But we should give them a clear, and well-isolated place in our project. ...
There's an excellent, if older, presentation called "Architecture, the Lost Years" that addresses exactly this problem and gives very specific, actionable guidance on how to solve it:
https://www.youtube.com/watch?v=WpkDN78P884
But how to pull off this decoupling? The answer is both obvious and surprising. Define a boundary. On one side is the framework. On the other side is your code. Through the boundary, only dumb data structure can pass. JSON works. So do structs. So does XML. The point is that these are behaviorless blobs of data.
This buys you a lot. You can run your application completely detached from the network, a database, and other expensive dependencies. So testing becomes much simpler and easier. And of course, you can replace the framework by writing new boundary code.
The other big lesson has something to do with why frameworks get added to a project in the first place. When designing a system, the goal should be to defer major decisions for a long as possible. That's when the best information is available. Sometimes you can just defer until the point becomes moot, which is a major win.
Reaching for a framework before being forced to do so sets up the kind of situation the author is talking about.
Re: Using a framework will harm the maintenance of your software
#55I strongly caution solo developers away from using a backend framework. A frontend framework is necessary for modern web development. Every HN startup should be going as minimal as possible.
Once you have 2 or more developers, you'll need to adopt a framework for new work (Rails, Django, etc.). Once you have 20 or more developers, you'll have more frameworks than you can count. And that's ideal.
Re: Using a framework will harm the maintenance of your software
#56Earlier quoted context omitted.
No. They haven’t been for a very long time. ~2008, iirc.
Rails really does not scale. In performance or development. It’s still a great option for small sites though.
Done Rails my entire career. It scales more than you think if you’re willing to throw some hardware at it and avoid turning your controllers and models into logic layer soup.
What kills scaling is inexperienced developers doing what I just mentioned. Also, ActiveRecord is not your friend at scale. It’s wonderful in small amounts, but callbacks and memory overhead will kill you. You really need to learn SQL to avoid doing select * on seven tables.
Also, view partials. The lookup cost on those is pretty high.
Re: Using a framework will harm the maintenance of your software
#571. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 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 com…
Do you think that formal specifications might alleviate logical bugs to an extent? Yes, it appears that companies won't budget that at all. Many seem to ship fast, fix later. It is also on the customer, really. Some people expecting software developers to deliver high quality software (with near 100 % code coverage and exceptional performance), but paying them less and less, is not fair. No wonder, some devs are ince…
I shudder to think about what a formal specification of some of the full stack web projects I've developed would look like. They might take longer than the actual coding of it - especially because specifications change mid project as we build things and realize we actually want them different.
Note this is a feature, not a bug, of "agile" development - you learn and adjust on the fly
Re: Using a framework will harm the maintenance of your software
#58Earlier quoted context omitted.
I feel like this response is common enough that it's almost a trope. "Oh you don't like leaky abstraction X, so what we should all code in binary!?" I think it comes from a kind of "Just World" spin off whereby all abstractions are considered pretty much equal, and it's cavalier to not code to the "highest" of these, no matter how many rickety chairs you've piled on top of each other to get that high. Not all abstrac…
> Not all abstractions are created equal. I'd go so far as to extend the statistics aphorism about models to software abstractions: all abstractions are wrong (/leaky?), but some are useful for now . The problem with software abstractions is that they, unlike the fundamental laws of physics, model code organization and business logic that frequently changes. These changes often make no sense beyond "VP lifer thought…
No I get that all abstractions leak on some level. But some leak a lot more than others. And as an industry we don't seem to have good mental models or languages around that.
More than once I've seen using the abstraction + working around the leaks being more complex than just using the the thing underneath the abstraction.
I have no pithy phrase to describe that scenario, without the "why don't we just code in binary" retort.
Re: Using a framework will harm the maintenance of your software
#591. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 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 com…
I agree with a sibling commenter after reading the article. The main point, as I see it between the lines, is not to refuse to use functionality (app side), but instead how this functionality should be packaged preferably (module side). Nothing prevents the one “in control” to give it up and expose a meaningful degree of it to a user, along with default mode convenience for those who want boxed version.
Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially. They are like smartest CPUs soldered into shitty boards (or simply incompatible with your requirements) without a chance to unsolder the functionality and use it elsewhere. You can’t make your own and you can’t take one off the shelf.
Consider this imaginary example: someone figured out all of the nuances of dom events across all browsers ever and made a clear api to it. Library way is to provide (Context, DomEvent) => MyEvent. Framework way is to create a complex rendering idiom in which MyEvent appears naturally and is an implementation detail. In the latter case you buy two for the price of two, and only so.
Or, they want to test a new idea/paradigm in some area. Without composable libraries, they are doomed to repeat all the mistakes you pointed out because to compete with already existing solutions they have to go all the way through issues unrelated to the idea itself. All that only to battle test it. For most library makers, the desired outcome is a sum of all parts, not just one.
Re: Using a framework will harm the maintenance of your software
#60Earlier quoted context omitted.
Do you think that formal specifications might alleviate logical bugs to an extent? Yes, it appears that companies won't budget that at all. Many seem to ship fast, fix later. It is also on the customer, really. Some people expecting software developers to deliver high quality software (with near 100 % code coverage and exceptional performance), but paying them less and less, is not fair. No wonder, some devs are ince…
I shudder to think about what a formal specification of some of the full stack web projects I've developed would look like. They might take longer than the actual coding of it - especially because specifications change mid project as we build things and realize we actually want them different. Note this is a feature, not a bug, of "agile" development - you learn and adjust on the fly
I tend to make it up as I go along ([0], [1]). It works for me (I just finished up a new SDK, using this technique[2]).
However, this would not work for many outfits. It’s just the way that I work.
WFM. YMMV.
[0] https://littlegreenviper.com/miscellany/forensic-design-docu...
[1] https://littlegreenviper.com/miscellany/evolutionary-design-...