Why I Hate Frameworks (2005) • Hacker News Board

Re: Why I Hate Frameworks (2005)

#311

Post by leke » Sat, Jul 08, 2023, 11:15 AM UTC

thescriptkiddie wrote: post #242

a_wild_dandan wrote: post #171

Earlier quoted context omitted.

This is why React won: No template language to learn. No prescriptions for managing your app. No piles of abstractions to do basic things. It's just a UI lib. Import it, declare what to paint on-screen, done. Oh, you want routing? "Not my business", says React. Go add a routing library. You want a framework for managing global state? Go find one. Want a kitchen sink frontend solution which bundles all of these common…

> Oh, you want routing? "Not my business", says React. Go add a routing library Great, now I have to sort through hundreds of different routing libraries and dozens of different build systems, and then do it all again when I need a state library. This is why people hate React.

Yep, Ideally it would have one, but be optional.

Re: Why I Hate Frameworks (2005)

#312

Post by xmcqdpt2 » Sat, Jul 08, 2023, 11:19 AM UTC

bruce511 wrote: post #134

VoodooJuJu wrote: post #120

Earlier quoted context omitted.

This misses the mark. CS classes and degrees are akin to reading books about swinging hammers rather than just swinging the hammer.

A lot of people think CS is "learning how to program in xyz." In fact programming is just a tool used to implement CS ideas and demonstrate their application in the real world. In my degree we spent maybe the first 6 weeks on actual learnjng-to-program (in turbo pascal.) Then another later on in Scheme. In 3nd year we did C, I don't recall what instruction we had there - maybe a week? Then 2 weeks in 3rd year where w…

During my PhD (not in CS) I met a CS PhD who was working on parallel algorithms. At the time I was struggling with large-scale simulations and HPC stuff so I got very interested. I asked him what programming languages he used.

"Oh I don't know how to code. We don't write programs in CS Theory."

Re: Why I Hate Frameworks (2005)

#313

Post by bossstein » Sat, Jul 08, 2023, 11:26 AM UTC

If we step back and look at this as a problem of abstraction. An advantage of abstraction is that the people working at the higher levels of the abstraction don't need to know what is happening at the lower levels. Therefore people can specialise and we can achieve better efficiency as an industry. If everyone needed to understand everything we'd be screwed.

In reality there are abstraction that work very well. You don't need to understand the internals of python to use it for example, though you may be able to use it better if you do. C however I would argue that you do need to have a mental image of what is happening to use it.

Also the operating system. People use that all the time without knowing how it works.

Maybe we are just at that early in web dev and we are waiting for the Unix of web frameworks to arise. Or perhaps there is an inherent tension between the developer needing to fiddle with the details while the framework tries to abstract those details away.

Re: Why I Hate Frameworks (2005)

#314

Post by hazz99 » Sat, Jul 08, 2023, 11:29 AM UTC

tough wrote: post #304

If you pick enough frameworks you can learn how the underlying system works. All web frameworks are the same to me, doesn't really matter if they're python, javascript, php, or whatever tbh. req/res body cookies that's it

I disagree, “req/res body cookies that’s it” is not the underlying system. It’s an abstraction over the TCP/IP and HTTP stack.

What happens when you need to disable nagles, avoid copies of the request body, use websockets, gRPC, etc? You’d need to pray that the framework gives you an escape hatch.

Re: Why I Hate Frameworks (2005)

#315

Post by dgroshev » Sat, Jul 08, 2023, 11:37 AM UTC

The fallacy here is the assumption that we get "hammers" as libraries, and not some splinters of wood in one crate and a whole bunch of hammer heads in another.

A "hammer" is useable on its own, it's a self-sufficient object of value. The "libraries over frameworks" mindset as practiced leads to splitting libraries by underlying technical concerns, not practical utility. There is no practical utility in a "routing library" or an "ORM library"; there is a lot of utility in a "login system", but realistically a login system has a lot of cross-cutting concerns, from database access to sessions to forms to templating.

Instead what we get is a wide selection of hammer heads and handles, all requiring assembly and not quite fitting to each other.

Re: Why I Hate Frameworks (2005)

#316

Post by sealeck » Sat, Jul 08, 2023, 11:39 AM UTC

xmcqdpt2 wrote: post #312

bruce511 wrote: post #134

Earlier quoted context omitted.

A lot of people think CS is "learning how to program in xyz." In fact programming is just a tool used to implement CS ideas and demonstrate their application in the real world. In my degree we spent maybe the first 6 weeks on actual learnjng-to-program (in turbo pascal.) Then another later on in Scheme. In 3nd year we did C, I don't recall what instruction we had there - maybe a week? Then 2 weeks in 3rd year where w…

During my PhD (not in CS) I met a CS PhD who was working on parallel algorithms. At the time I was struggling with large-scale simulations and HPC stuff so I got very interested. I asked him what programming languages he used. "Oh I don't know how to code. We don't write programs in CS Theory."

I suspect that they could write code, but I don't think this is so outrageous.

Re: Why I Hate Frameworks (2005)

#317

Post by golergka » Sat, Jul 08, 2023, 11:46 AM UTC

Our_Benefactors wrote: post #200

balder1991 wrote: post #163

Earlier quoted context omitted.

Unfortunately this is true, as I grew more experienced I’m very careful with the dependencies I add to a project. I don’t work with React Native but I hear horror stories of how the hundreds of dependencies force you to either stick to the old versions of stuff or keep fixing or rewriting things that used to work. Seems totally unsuitable for a side project you want minimal maintenance over time.

Create react app, with all node_modules included, is well over 200MB of garbage OSS libraries. That’s insane for a hello world.

If “hello world” is the whole requirement behind an app, and you won't develop it further, you don't heed to use react. In fact, here's your whole app: “hello, world!”. Copy it, save it in .txt file, serve in static anywhere you want.

Re: Why I Hate Frameworks (2005)

#318

Post by whstl » Sat, Jul 08, 2023, 11:52 AM UTC

afiodorov wrote: post #285

whstl wrote: post #271

Earlier quoted context omitted.

There is no silver bullet that solves this problem. The thing I've seen the most in this industry is the opposite of that: teams that would mostly use third-party tools and frameworks, but the result was effectively the same, with complexity exploding and becoming so unbearable that the teams inflated to compensate, with productivity grinding to a halt. It happens with third-party tools as often as it does with NIH.…

There isn't a one-size-fits-all solution to this issue. Before joining the department, I was part of a start-up where, with a considerably smaller team, we were able to process even larger amounts of data. We could introduce a new feature in a single day - a feat unthinkable in the department I just described. This speed was not achieved at the expense of stability but was a direct result of our choice of tools. Addr…

Dare I suggest that it is possible that the nimble startup was moving quickly not necessarily because of tool choice, but because of the small team size and because the appropriate amount of complexity was introduced? And conversely the inflated team was slow exactly because it was inflated and complexity was introduced? This effect happens with or without bringing third-party or in-house tooling/frameworks into the equation, and is well known and well covered since Mythical Man Month.

And no, I don't see the point of rebuilding Kubernetes and Docker in-house and most critics also don't. What I'm saying that teams will be better of if they work towards not needing Docker or Kubernetes (or any NIH replacement) at all. But that requires challenging the assumption that software needs "something" like Docker or Kubernetes.

Sure, if there's a tool for X then by all means use it, but my point is more that not doing anything in-house can often lead to the same issues.

Re: Why I Hate Frameworks (2005)

#319

Post by hfkwer » Sat, Jul 08, 2023, 12:03 PM UTC

revscat wrote: post #195

hfkwer wrote: post #80

Earlier quoted context omitted.

This piece was written before React even existed. (React is from 2013, this is from 2005.) Besides, I can't think of a single "factory" oriented concept in React, could you elaborate?

Yes, of course. It was a joke. Jokes don’t have to make sense. They just have to be funny. I understand that you did not find it funny, and that’s ok. It certainly wasn’t even all that funny. There are wide variances in what people find funny. Even the most uproarious joke a comedian tells will have those who genuinely didn’t enjoy it. But at the same time it is generally considered dickish to try to convince the peo…

Sir, this is a Wendy's.

Re: Why I Hate Frameworks (2005)

#320

Post by whstl » Sat, Jul 08, 2023, 12:06 PM UTC

sfn42 wrote: post #292

josephg wrote: post #281

Earlier quoted context omitted.

Yeah fair enough. The whole factory factory factory thing feels separate to me. I think of it as a disastrous, productivity destroying meme that spreads through words like “hidden implementation” and “one interface, multiple implementations”. You don’t to be a senior to be vulnerable to the mind virus, though once it gets into the heads of your senior engineers your whole team or company can be in peril. The disease…

Sounds like you haven't really understood the benefits of polymorphism, encapsulation etc. The general idea is to compartmentalize your logic and only expose the important parts like if you need to generate pdfs from html you may need to use a lot of moving parts to make that happen but you hide all of it and only expose an interface with a single action that takes html and returns a pdf. If you later need to change…

I disagree with the suggestion that parent poster doesn't understand the benefits of polymorphism and encapsulation.

Polymorphism and encapsulation are perfectly achievable without the programming practices being criticized by them.

I don't think any sane developer would complain about having exchangeable/reusable HTML/PDF/??? generators. Funny enough, "PDF Generator" is also a very popular example of a "sane" micro-service.

The real problem starts when every single class in the application is given this treatment, even in the cases it doesn't make sense to make it replaceable. This problem is compounded by having very small classes that don't do much by themselves and have (hidden) dependencies with too many other classes. That's how you get the FactoryFactoryFactory problem.