Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

261–270 of 550 posts

Re: Using a framework will harm the maintenance of your software

#261

Earlier quoted context omitted.

> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the la…

> Not all software has an implied framework within it. The definitions of "framework" are always a sticky issue. If you take "framework" at face value, it's minimally a set of idioms. "an essential supporting structure which other things are built on top of" - which necessarily includes a mental model of execution. This relates closely to why naming, in software development, is considered so difficult. All software h…

An important part of being a framework is that it is made for reusability, similar to a library. Just because your code has some thought out structure/architecture doesn't mean that it has an inherent framework.

Re: Using a framework will harm the maintenance of your software

#262
post #9

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."

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…

If your argument is that using someone else’s abstractions is bad because you can write your own (which is what this article is saying), then the standard cliched reply is accurate. Cliches are cliches for a reason.

Re: Using a framework will harm the maintenance of your software

#264

Earlier quoted context omitted.

I did some Django but in the days, and I completely agree that as long as you have CRUD, Django shines. The issue starts when you cannot really fit your uses cases into simple CRUD and you start to fight against the framework to achieve this. The author also made a point of negligible gains - even if you spend a week to setup auth, sessions etc. if still negligible for longer running projects

I've worked on to many long dead projects with scant doco and the best ones are always where people colored inside the lines. Remember google web toolkit? That flamed out hard 15? years ago. I've recently had to make a mod to a decaying app written in GWT. It was easy because no one got creative. I think theres a long term risk with rolling you're own that you box yourself into a lot of corners without knowing it.

You can also get really creative with frameworks, specially if you need to quickly overcome some strange limitations imposed by framework. There is also a long term risk with using frameworks - somebody here mentioned method renames in Laravel, that makes upgrading difficult.

Im not talking about writing your own http server, or building the whole database access library. You can use some ready made libraries. As long as you keep proper boundaries between IO and business logic, you can fairly easy change the IO libraries.

Of course there is quite some overhead there, and for some projects it makes not sense.

Re: Using a framework will harm the maintenance of your software

#265
post #17

1. 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…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

Where do you draw the line between using and not using framework.

Programming language is a framework over machine language. Java garbage collector is a wrapper around manual memory management. Java Servlets is a pretty thin wrapper over HTTP request/response, is this a framework already? How about Java JAX-RS, it is built on top of Java Servlets and built to handle mostly REST type requests.

Same with database connectivity. Where framework starts? On JDBC/ODBC driver layer? ORM mapper like iBatis? JPA/Hibernate "true" ORM with automatic dirty checking?

Re: Using a framework will harm the maintenance of your software

#266
post #196

Earlier quoted context omitted.

Maybe common structure, not common parts. "Framework" is a good description: it gives you the shape, you fill it in.

Care to elaborate the difference? In both cases common code is extracted.

The difference between a framework and a library is that you call the library, while the framework calls your code.

Re: Using a framework will harm the maintenance of your software

#267
post #209

Earlier quoted context omitted.

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

Maybe you should master your tools before using them. You can use frameworks where they fit, and not where they don't. Knowing when to do which takes time and experience, but it is definitely do-able, and better. Frameworks allow you to update, and maintain your app for free, since others will do it for you. If you do it yourself, you have to do all the work and that's keeping you from adding value elsewhere. To not…

> Frameworks allow you to update, and maintain your app for free, since others will do it for you.

Usually not for free. Sooner or later there's an API breaking change and you end up spending time reading changelogs trying to figure out how to get your code working again...

Re: Using a framework will harm the maintenance of your software

#268

Earlier quoted context omitted.

The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the co…

Are we using different Djangos? Let’s take it for granted you’re using it with HTTP since it’s a web framework (this would all apply with WS). You routes call your views. Your views load your models. These feed into your templates, which go into a response. You can tweak what’s going on at each step (DRF) but there’s definitely a way it’s all supposed to work together. It’s classic IOC.

I recently spent a few months on a project where we used Django without a single HTTP / external endpoint. It basically consumes messages from a rabbitmq queue, then creates new celery tasks which are then run.

Using Django for this is of course completely overkill, but using a known framework, especially considering that Django is what's used in other applications here, did have some benefits. All our devs having to fix something in this app, will immediately be familiar with it as it looks exactly like the other Django apps we have. No new way to do migrations, talk to the db, open a shell, log- and reliability setup is identical with other apps, etc. etc.

Re: Using a framework will harm the maintenance of your software

#269
I think using a framework can help with the maintenance of the software.

Let me use the one that is usually used as a negative example in hacker circles: Spring.

Spring has a steep learning curve. Spring feels like too much magic. Spring makes simple things look complicated and hard to understand. Spring is large.

On the other hand: I don't care about making extremely simple things more complicated. In the enterprise world / large-scale SaaS development, we don't do extremely simple things. If we wanted to have a service that adds to two integers and returns the result, then it must have unit testing, integration testing, end-to-end testing lifecycle management, documentation, health checks, clusterability.

Why? Because we want to make our own lives easier by having ground rules for services and code, and anyone who starts maintaining, improving or operating a service knows that they can expect the stuff mentioned earlier.

So Spring gives us these out of the box. People learn it once, and then whenever they start to work on something new, they get Prometheus metrics, testability, proper logging, etc. right off the bat.

I find Spring (and other frameworks) annoying and boring as a hacker, and I find them very useful as a CTO when a large team is working on system and people come and go over years or decades.

Re: Using a framework will harm the maintenance of your software

#270

Earlier quoted context omitted.

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

Sometimes I stated writing a web app with Sinatra, which is about the less frameworkish thing you can do in Ruby unless you are also writing your own router. I regularly end up having to 1. Either write my own code to query the db and build Ruby objects from the response and viceversa OR use ActiveRecord. 2. Same thing about managing the database schema. Either my own code or someone else's. So why not Rails' well te…

Here's another view on using Sinatra:

* It lets me pick and choose an ORM. I usually prefer Sequel over ActiveRecord. Pretty much nobody suggests you should use Sinatra without an ORM unless you genuinely don't need a database.

* Nobody suggests you should build your own schema management. Pick an ORM which provides it out of the box (e.g. Sequel), or use a component which provides it (e.g. Padrino has a generator component which out-of-the-box supports generating migration helpers for the major Ruby ORM's and some you're unlikely to have heard of)

* Nobody suggests you should write your own code to manage tests. Just use rspec / capybara, or whatever else you prefer. And again, consider using Padrino's generator if you want something to generate scaffolding for it for you.

The point of using Sinatra is the freedom to opt-in to your preferred components as and if/when needed. If you always want the ones Rails provide, just use Rails, nobody will think less of you for doing so. Not even those of us who personally don't like using Rails.

For my part I rarely want the ones Rails provide, and so I rarely use Rails. Often I use bare Sinatra. Sometimes I mix in some components from Padrino because they can be easily torn out again.

I'd suggest that if you want something lighter than Rails but have those issues with Sinatra, look at Padrino (Sinatra + a pre-packaged set of components you can opt in or out of separately, or layer in piece by piece on top of Sinatra if/when you need them). But you can also just use Rails.

Post reply on HN