Live data from Hacker News

Why I Hate Frameworks (2005)

factoryfactoryfactory.net

171–180 of 407 posts

Re: Why I Hate Frameworks (2005)

#171
post #47

I remember following up the Angular tutorial. I was about 15min into the tutorial, and I was already editing 8 different files. I never got lost so quickly. I lost a job because I could not use angular, but never felt bad about it. I remember somebody commenting here on HN about a developer conference, where the speakers were bragging about their software being complex. This is an awful trend with software, and is re…

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 commonplace features together? Use Create React App, or Next.js, or whatever fits your use case.

That's why I love React. The complexity of the solution matches the complexity of the problem.

Hello world:

    const App = () => Hello world!
    root.render();
Basic reactivity (output click event to console):

    const App = () => 
Composition & enumeration (dynamic bullet list!):

    const OneTwoThree = () => [1, 2, 3].map(i => {i})

    const App = () => (
      
        
      
    )
Set UI output data and CSS style based on asynchronous query results:

    const App = () => {
      const [isGoogleUp, setIsGoogleUp] = useState(true);

      const checkGoogleStatus = () =>
        fetch('http://google.com')
          .then((response) => setIsGoogleUp(response.ok))
          .catch((err) => setIsgoogleUp(false));

      useEffect(() => {
        checkGoogleStatus();
      }, []);

      return isGoogleUp 
        ? (Google is up!)
        : (Can't reach Google.);
    };
I can't imagine things being much simpler than this. No extra CSS files. No `Controller` classes. No janky, bespoke HTML "attributes" to make array loops or conditionals work. Just pure JavaScript (JSX optional) painting what you declare. That's my jam. I can't endure the agony of learning another damn template language or SomeCompany's (leaky) abstractions.

Re: Why I Hate Frameworks (2005)

#172
post #162

Earlier quoted context omitted.

Those techniques were precursors of calculus. They're often taught in introductory calculus courses (at the university level). I consider them part of the field of mathematics we now call calculus. Indeed, if you study the history of mathematics you'll find that calculus isn't just something Newton invented out of whole cloth, as he himself was well aware: "If I have seen further, it is by standing on the shoulders o…

You could argue that algebra was a precursor of calculus and that basic operations were precursors of algebra. This is a rather reductionist argument. They hadn't even invented zero or algebra when they found ways to produce square roots or that you could make interesting ratios from the sides of a triangle (yes, I know about the history of zero and that is a slight exaggeration, but no symbol for zero existed in Mes…

Most people who take trigonometry (or "precalculus" as they usually call it today) couldn't tell you anything about limits let alone derivatives, integrals, and the fundamental theorem of calculus.

And to those people, the calculator is a magic “black box” that spits out cosines. My original point stands: if you are using a tool professionally you should understand how it works, at least on a basic level. For a calculator, that means calculus, Taylor series, Newton’s method, etc.

Re: Why I Hate Frameworks (2005)

#173

The worst part of this kind of thing is that young carpenters honestly, really, truly, just need to learn to use a hammer. They can't even conceive of the problems that are being solved by the hammer factory, let alone the factory factory. But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan comple…

I'm going to start calling construction apprenticeships "builder builders".

Re: Why I Hate Frameworks (2005)

#174
post #5

Simplicity is easy to mandate: "just use simple tools!". It's not always obvious when the finished product looks wonky and slanted and has to be retrofitted several times that the complexity was always there, in the world. The complexity in our tools is hopefully there to help with some complexity in the world. In my experience, it's always the junior who shouts "This could all be so much simpler!".

> the complexity was always there, in the world Essential complexity is exactly that. The entire game is to separate it from the accidental complexity. My career/life was revolutionized by a paper that is 100% focused on this very topic: https://curtclifton.net/papers/MoseleyMarks06a.pdf The solution to eliminating accidental complexity is ultimately presented as a flavor of relational model, which I simply read as "…

For others: this is the classic Out of the Tar Pit paper, which I also adore so so much. It promotes very explicit state management and functional programming to reduce accidental complexity.

our friend ChatGPT summarizes the paper thus:

"In summary, "Out of the Tar Pit" argues for a shift in software design principles, advocating for the reduction of accidental complexity through functional programming and dataflow concepts, proper state management, and the use of formal methods. By focusing on these principles, the authors believe that software systems can be made simpler, more robust, and easier to understand and maintain."

Re: Why I Hate Frameworks (2005)

#175
post #92
post #89

Earlier quoted context omitted.

I would add that intuition and knowing how to question it is also vastly important. My main driver is Ruby - I have a good feeling about code that can be refactored to use Enumerable more effectively; but I also know that Enumerable offers so much that I might be expecting too much of it. So 80% of the time I point to a method that solves the exact problem and the rest of the time I know how to write it differently.…

> I would add that intuition and knowing how to question it is also vastly important. I agree. Especially knowing how to question and how to break problems down. I'm not sure intuition is a thing that can be taught, but it's a thing that emerges as a consequence of being curious and learning how to question and find answers to those questions. That aspect is also why I think that being generally curious and having a…

And the concept of intuition is discussed in ch22 of thinking fast and slow (can’t find my copy atm) with regards to how firefighters are able to make those split second decisions.

If you’re interested/havent already read: https://stenzelclinical.com/wp-content/uploads/2021/12/Kahne...

Re: Why I Hate Frameworks (2005)

#177
post #121
post #40

Earlier quoted context omitted.

Calculators do a lot more than arithmetic these days. Without knowledge of calculus, most people think of a calculator as a magic “black box” that outputs square roots and cosines.

Roots were calculated at least as far back as 1800BC thousands of years before calculus existed. Trig functions were indirectly messed with since around at least 300BC and was definitely discovered by Indians around 600AD. Meanwhile Calculus wasn't published until the 1700s.

And sine, cosibe, and tangent are just ratios between different parts of a triangle and can be derived relatively easily (just like how you can derive pi if you know the diameter and circumference of a circle).

Re: Why I Hate Frameworks (2005)

#178

Earlier quoted context omitted.

There must be some metric of the resonance of a particular piece by looking at the number of reposts and distribution of comments amongst them (plus an analysis of the sentiment of the comments and characteristics of the thread trees in each separate posting). Just looking at this listing, without looking at the comments in each one, this seems to have a sustained resonance. Maybe I’m biased–it certainly resonates wi…

Its resonance may sustain because theres always people entering the field who are trying to build something, and either get caught up on a frameworks hypetrain or have fond enough memories using a given framework to build something quickly, and then getting burned trying to build something ambitious with a given framework because its opinionation proves to be too rigid one way or another, and a perpetual new influx o…

Which is precisely why a framework is necessary, but knowing how to write what you want without the framework is even more necessary.

If you only know how to code within the constraints of the framework, you're gonna fail for anything non-trivial. If you try to ditch frameworks entirely, same deal.

Re: Why I Hate Frameworks (2005)

#179
post #47

I remember following up the Angular tutorial. I was about 15min into the tutorial, and I was already editing 8 different files. I never got lost so quickly. I lost a job because I could not use angular, but never felt bad about it. I remember somebody commenting here on HN about a developer conference, where the speakers were bragging about their software being complex. This is an awful trend with software, and is re…

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…

Counterpoint: While $MYFIRM is a React + Django shop and that's absolutely the right decision due to ecosystem factors, I do wish Ember had won the frontend ecosystem race.

Having worked in an Ember shop before, having everything just work and not be constantly updating dependencies and managing around cross dependency hell and endless package underwriting was very nice. Not to mention that to this day, I still haven't found a good React equivalent for Ember data, and I miss not only how productive my org was with Ember and how nicely our codebase scaled over time with sane conventions that we didn't have to invent the hard way by trial and error.

I would say very nearly the same thing about Django in that if it used SQLAlchemy and HTMX/etc for Django Admin, it would be nearly perfect. Even so, Django is a framework that has never let me down in production and it's always irked me when I've had to build something in Flask-land or FastAPI-land that just worked out of the box in Django, or was a well maintained package in the Django ecosystem.

Re: Why I Hate Frameworks (2005)

#180
You know why this is so dumb? Because there's an analogy that's very similar that explains why we have frameworks.

A: I wanna buy a tree. B: Ok. We have trees. What do you need a tree for? A: i want trees so i can make lumber out of them. So i can cut them in two by eights. So i can build a deck deck for my patio B: Hmm we sell two de eights. You wanna buy that instead? A: Oh yes why! I would like that! I'll buy two by eights instead of trees so i can finish my job faster!

Post reply on HN