Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with Frameworks

plbrault.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: The Problem with Frameworks

#101

Post by chaostheory »

berkes wrote: post #92
chaostheory wrote: post #82

Earlier quoted context omitted.

The key issue is “if you do it right”. That’s easy to type, but hard to execute. You’re essentially creating a private framework without public scrutiny which catches a lot of mistakes. That’s one of the main values of using an open source framework. Are there times when a new framework is better than a preexisting one? Sure, when there are no frameworks that can meet your specialized project, but if it’s a typically…

> The key issue is “if you do it right”. That’s easy to type, but hard to execute. Indeed. In fact, everyone, including said seniors, will make the wrong decisions, will "do it wrong". So make sure the "do it wrong" is cheap. And the "do it right" compounds. Frameworks make "do it wrong" extremely expensive. If, after four years, you find that Symphony really was the wrong tool for your highly event-sourced bookkeepi…

> So make sure the "do it wrong" is cheap. And the "do it right" compounds.

That’s still really simple to type and hard to do.

> Frameworks make "do it wrong" extremely expensive. If, after four years, you find that Symphony really was the wrong tool for your highly event-sourced bookkeeping

1. It’s pretty simple to determine a framework’s architecture and design decisions a few months in, if not a few weeks or less

2. A “book keeper” application is such a basic commodity CRUD app, that it was exactly what a commodity framework was built for. Virtually every web based CRUD application is a conventional commodity.

Using a framework is optimizing for “cheap failure”. Creating your own inverted private framework feels like the exact opposite. All of the expensive mistakes possible with an open source framework, equally applies to your homegrown framework. The difference is that it took a lot more work and time to get to the same starting point.

Re: The Problem with Frameworks

#102

Post by zelphirkalt »

pooya72 wrote: post #94
jjtheblunt wrote: post #77

Earlier quoted context omitted.

I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.

What do you think people waste most of their time on?

Debugging and finding tiny mistakes in the new hot JS framework of the month. That and maybe trying to do something with CSS the wrong way, but not looking up how it should be done and reworking their DOM to make that happen.

Re: The Problem with Frameworks

#103

Post by oblib »

I'll chime in on this for posterity's sake.

I spent about a month reviewing frameworks on "ToDoMVC.com". My goal was to evaluate those and choose one for an app I wanted to upgrade. When I'd finished the review process I struggled for about a month trying to decide on which of those I'd invest my time in because that's a huge investment.

I finally decided to no use one. I did exactly what the author did. I selected libraries of code. I used jQuery, Mustache.js, Accounting.js, PouchDB.js, Chart.js, and Bootstrap.

With the exception of the latest Bootstrap I've been able to update all of those without any issues at all and I've gotten pretty good and using those tools.

I don't regret this at all. In fact I think this choice would make it much easier for anyone to modify my code, and that's something I want to offer users.

Re: The Problem with Frameworks

#104

Post by [deleted] »

zelphirkalt wrote: post #102
pooya72 wrote: post #94

Earlier quoted context omitted.

What do you think people waste most of their time on?

Debugging and finding tiny mistakes in the new hot JS framework of the month. That and maybe trying to do something with CSS the wrong way, but not looking up how it should be done and reworking their DOM to make that happen.

[deleted]

Re: The Problem with Frameworks

#105

Post by pooya72 »

zelphirkalt wrote: post #102
pooya72 wrote: post #94

Earlier quoted context omitted.

What do you think people waste most of their time on?

Debugging and finding tiny mistakes in the new hot JS framework of the month. That and maybe trying to do something with CSS the wrong way, but not looking up how it should be done and reworking their DOM to make that happen.

I'm sorry, put the parent comment was talking a the Java framework Spring. My question was in regard to that framework.

Re: The Problem with Frameworks

#106

Post by wtetzner »

chaostheory wrote: post #83
commandlinefan wrote: post #35

Earlier quoted context omitted.

> completely skip their wrapper Why use Spring Boot at all then?

Because it provides commodity functionality that most developers with Spring experience can understand quicker, along with the Java philosophy of customization over convention. I don’t like Java or Spring, but I understand their benefits and why people like them.

I don’t understand why people use Spring. Having worked in more than enough Spring projects, your frankly better off without any framework than using Spring.

Re: The Problem with Frameworks

#107

Post by wtetzner »

chaostheory wrote: post #100
pooya72 wrote: post #93

Earlier quoted context omitted.

What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.

Imo if you’re doing Java, you need some inversion of control framework like Spring of Guava. You can’t avoid it especially for larger projects what I really hate is that it focuses on configuration & customization over convention. At the same time, it is a strength for certain projects and teams.

> Imo if you’re doing Java, you need some inversion of control framework like Spring of Guava. You can’t avoid it especially for larger projects

I completely disagree. I’ve worked on more than my fair share of Spring projects, and as far as I’m concerned, dependency injection frameworks tend to make projects more complex than they need to be. In some ways I think Spring projects end up being much larger than they need to be because of Spring. Not to mention that it turns compile-time checks into incredibly hard-to-debug runtime checks.

Re: The Problem with Frameworks

#108

Post by wtetzner »

pooya72 wrote: post #94
jjtheblunt wrote: post #77

Earlier quoted context omitted.

I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.

What do you think people waste most of their time on?

Debugging is one. I’ve spent and enormous amount of time debugging problems that never would have occurred without Spring, and even more debugging things that would have been much easier to debug without Spring.

And even if I didn’t have to spend all that extra time debugging, I don’t think Spring actually added any real value.

Re: The Problem with Frameworks

#109

Post by wtetzner »

mtberatwork wrote: post #26
mattgreenrocks wrote: post #14

The paradox of frameworks: if you couldn’t write it yourself, then using it is a big risk if you hit a bug. But if you could write it yourself, you may not want to, as you have a better idea of what you want. Personally, I only like frameworks that don’t fight me tooth and nail to encapsulate them into adapter layers (hexagonal architecture) when the time comes. There aren’t many of them. Some of them feel almost nar…

If you hit a bug with a popular, open-source framework, the odds are great that others have as well and it will get escalated and solved quickly. The same can't be said for closed-source, proprietary frameworks. Also, writing it entirely yourself always leads to re-inventing the wheel over and over again. Furthermore, I have yet to see any proprietary framework that wasn't in some shape or form a poor knockoff of som…

But you don’t write your own framework, you write a program. Not trying to make something too generic can keep things much simpler.

Re: The Problem with Frameworks

#110

Post by gregplaysguitar »

jamesfinlayson wrote: post #88
gregplaysguitar wrote: post #85

Earlier quoted context omitted.

I used to do this before I discovered renovate [1] - now we spend time working on major upgrades but minor are generally automatic (assuming they pass tests) [1]: https://github.com/renovatebot/renovate

Oh nice - do you get many problems that slip through even though tests pass? I had a minor update to the Stripe SDK recently that broke something.

We do get very occasional issues in our React app, but not enough to outweigh the benefits of things staying up to date.
Post reply on HN