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

81–90 of 111 posts

Re: The Problem with Frameworks

#81

Post by nlitened »

gorjusborg wrote: post #17
recursivedoubts wrote: post #11

I like the idea of a "curated" platform: putting together the best libraries in a somewhat opinionated way, but not writing a lot of additional code on top of it, and making sure that most of the curated glue code can be ditched if someone using the platform doesn't want or need something. This would let people get going quickly and not have to make a thousand decisions or figure out all the integration points, but r…

In the clojure ecosystem, Luminus ( https://luminusweb.com/ ) is pretty much a curated set of libraries for web development. I still think that relationship still creates friction. The framework itself has swapped out libraries in the past, and you are basically dragged along if you upgrade.

As far as I understood from my experience, there’s no way to upgrade your Luminus after you had started your project, you only upgrade individual libraries — so any further changes in the Luminus framework itself don’t affect your old projects.

Re: The Problem with Frameworks

#82

Post by chaostheory »

berkes wrote: post #47
toddmorey wrote: post #25

Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…

To counter some of your counters, or, actually, to give some advise that I've learned along the way: > - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack Yes. Which is why it is crucial to know software patterns, be able to research architectures and have (someone close, with) experience in making those choices - and seeing them fail. Frameworks are not a real answer…

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 CRUD application? Imo you’re better off with an open source framework.

Re: The Problem with Frameworks

#83

Post by chaostheory »

commandlinefan wrote: post #35
random_kris wrote: post #15

Earlier quoted context omitted.

Well with spring boot you can use spring wrappers but there are always (atleast in my expirience) ways to override their way of doing things or just completely skip their wrapper and just use whatever is under the hood

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

Re: The Problem with Frameworks

#84

Post by chaostheory »

beaconstudios wrote: post #33
thomascgalvin wrote: post #23

> According to that definition, React is not a framework, but Gatsby is. I dislike articles like this. The vast majority of people would consider React a framework, and if you need to redefine such a basic word in order to make your point valid, there's probably an issue with your argument, not the definition.

I think it's reasonable to say that React is a UI framework because you have to build your UI within it if you choose it. The author's argument that because it doesn't provide the kitchen sink it isn't a framework, misses the issue that you can have frameworks for subsets of a project. You get UI frameworks (React, Angular), CSS frameworks (Tailwind), backend/API frameworks (GraphQL), etc that only lock in one area.

It’s a bad argument. React is still a framework and not a “library”.

Re: The Problem with Frameworks

#85

Post by gregplaysguitar »

jamesfinlayson wrote: post #72
nicoburns wrote: post #12

Earlier quoted context omitted.

> A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. I definitely agree that the attitude of never upgrading dependencies doesn't work! But I've seen plenty of teams using dependencies successfully that took the opposite approach of updating them regularly (say, spending an hour updati…

Agreed - I drive-by minor version updates at every opportunity that I can because I know if I don't, things will get pretty painful sooner or later.

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

Re: The Problem with Frameworks

#86

Post by sprkwd »

gwbas1c wrote: post #18
recursivedoubts wrote: post #11

I like the idea of a "curated" platform: putting together the best libraries in a somewhat opinionated way, but not writing a lot of additional code on top of it, and making sure that most of the curated glue code can be ditched if someone using the platform doesn't want or need something. This would let people get going quickly and not have to make a thousand decisions or figure out all the integration points, but r…

15 years ago, there was "LAMP:" Linux, Apache, MySQL, PHP.

…and I still use this.

Re: The Problem with Frameworks

#87

Post by douchescript »

The problem with the frankenstack, where you levy a couple of hand-picked libraries, is that there’s no guarantee or roadmap that will make newer versions of your libraries (and their dependencies) play together nicely a year or two on. If the number of libraries can be kept to a minimum, then maybe it’ll be a viable strategy.

Re: The Problem with Frameworks

#88

Post by jamesfinlayson »

gregplaysguitar wrote: post #85
jamesfinlayson wrote: post #72

Earlier quoted context omitted.

Agreed - I drive-by minor version updates at every opportunity that I can because I know if I don't, things will get pretty painful sooner or later.

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.
Post reply on HN