re: Todo-MVP: Or 'Why You Shouldn't Use A Web Framework' - The Revenge VIEW POST

FULL DISCUSSION
 

A thoroughly interested read. It's nice to stand back every now and then and ask "why am I doing it this way?" Usually the answers are terrifying "we've always done it this way" or "it made sense at the time". I'm totally for a proportional solution. Why build a rocket when you're only going to the supermarket?

 

We haven't always done it this way. We do it this way because we tried the way he's suggesting for years and it was proven hands down to be slower, more expensive, less secure, and infinitely harder to add new head count into...

 

Citation very much needed here.

Again people keep pretending that David and others are somehow not productive by not using a framework. You keep saying it but the evidence in his eyes (and my own) say otherwise.

I dont use a framework for the current project and i am very productive. I see another team using Spring, and they tie themselves in knots constantly trying to understand the damn thing. Who is productive again?

Writing new code is ALWAYS slower than not writing it.

How many people knows Spring?

How many people knows your solution? Only you? Ten?

If you are writing code for money, you should know it is not about your productivity. It is about productivity of people, who would support your product after you.

Usually frameworks wins due to popularity... and it is their core purpose.

There are bad frameworks.
There are misused applications of a framework.

I guess not your one arbitrary ad hoc example team. I work in a company with thousands of engineers and I've worked on teams as small as two and everything in between. I can cite dozens of ad hoc examples as well, but I'll go ahead and point to any job board and the percentage of jobs that state "We want you to not use a framework to work on this project." Any Fermi estimates of how many you're gonna find? I'll go with Zero. The industry runs on frameworks because they work and work well for 99% of what we do in real life every day. Can I think of some situations where a framework would be a detriment? Yes. Can I think of ways to cherry pick libraries to solve those edge case architectures? Yes. Does that matter for the vast majority of bog standard web apps that the vast majority of us churn out week to week? Hell no. Perfectly good frameworks in the wild today remove boilerplate, provide tons of affordances, have solid communities, and make it easier to focus on your use case specific code. Not to mention being able to hire new headcount that can be up and running on real work with very little onboarding. That's why they're used, as many have stated. The difference between you and me is not that either of us can or can't use frameworks to build applications, it's that one of us is on an esoteric quest an the other has better things to do than fiddle with library curation. If your article said, "I know frameworks are super useful but here's some use cases where you should consider not using them and here's how you'd go about it" you wouldn't be receiving all this flack in the comments. Your "This way or the highway because straw man imaginary problems" is why people are crapping all over it.

The difference between you and me is not that either of us can or can't use frameworks to build applications, it's that one of us is on an esoteric quest an the other has better things to do than fiddle with library curation

Actually I'd just rather not have to learn how to use a new framework every couple of years because that's what happens to all of them. I have better things to do than learn some other person's idea of how a web app should be built when in essence all i really need is

main function, start server, with router, routes mapped to controllers... job done.

The fact you are strawman-ing the argument in terms of being "esoteric" is pretty sad.

Re job ads, find any Go jobs with a framework and come back to me. All the job ads I look at in my area dont specify frameworks at all, shrug. They usually just look for good engineers with some familiarity with particular programming languages.

So you're building static sites? Because you haven't listed Auth, Storage, Caching, Queues, Jobs, Search, Web Sockets, API, templating, DI, or any other number of things that are used quite frequently if not 100% of the time on the apps I'm building every day. Your "Job Done" looks a helluva lot different than my "Job Done". And if that's your use case fine, but don't try to pretend that that's common. That's all choices that I can either take the time to make myself and then explain to dozens or hundreds of other people, or I can just say, "Here's the standard way the framework has chosen to solve for it, learn it once and use it for the next 100 apps you spin up. If you run into an edge case we'll flip out the stock solve for something that works for that." You make some super weird arguments my friend...

Chris, Rails has been around for 12 years. I think the first version I used was 3 something, we're almost at 6. It's essentially the same thing.

I think JS frameworks deserve a bit of your distaste but most server side frameworks don't change that fast.

There would be riots if they did.

So you're building static sites? Because you haven't listed Auth, Storage, Caching, Queues, Jobs, Search, Web Sockets, API, templating, DI

All covered by libraries, if and when i need them.

Apart from DI, you dont need libraries for DI (although things like frameworks will trick you into thinking you do)

Chris, Rails has been around for 12 years.

This is a fair point.

I would still contend the overall tone of it being wasteful/impossible to build non-trivial applications without frameworks is bordering on absurd.

Look at most Go projects, you wont find any frameworks there. How are people making "real" things with Go?

I think you conflated two separate answers by two different people 😬

I think both camps have valid points but I've only seen one or two people talking about the value of frameworks in equalizing the developer experience between different levels of skills or in companies with high turnover.

I don't think you always need a framework but I don't also think you never do.

Yes I was trying to reply to both with the quotes but maybe the UX of this site didnt expect such a nested flamewar ;)

I don't think you always need a framework but I don't also think you never do.

I dont disagree at all. I feel like the main point of this post is that it shouldn't be the default position that you do.

I can hire a mid level developer and outsource the cost of teaching them the parts of my code that are just infrastructure and focus on the actual application exactly because I know that they know where the code is put.

How can I outsource that? By using a framework and make sure they actually know it when interviewing.

Could a good developer be brought up to speed in a frameworkless environment? Sure.

Will it always happen? Nope. I've seen the horror of multi year apps written "just with PHP" (I was hired to rewrite it in Django exactly because nobody knew how it worked and they just kept it there as legacy).

It really depends on the people in this framework less space. You guys are capable developers and made a sensible choice.

As a freelancer I came across small agencies with developers with variable levels of skills with unmaintanable apps using a framework. They would have had unmaintanable apps nonetheless without such framework. The difference is that the new set of eyes (me in that case) was able to just focus on the spaghetti app code, not also the spaghetti infrastructure code.

My personal experience of growing big with a framework is that you ultimately will end up just using it as a layer between your logic and HTML, the more your skills improve.

Something like

def action
  # call my business logic, ok bye
  # return some HTML
end

I don't see the big difference in the case of a well experienced developer like you are.

My favorite framework is Flask because it just does the boring parts of web apps and can be plugged with functionality pretty easily. Also has a neat concept called blueprints that allows you to put controllers wherever you want

Not if the code you are re-using is not fit for purpose.

Or if it forces you down roads that are not necessary.

Plus almost every framework that has any kind of popularity has books, books written about them. Does that not tell you there is a big cost to using them, at least in terms of understanding them.

code of conduct - report abuse