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

Write Libraries, Not Frameworks

brandons.me

Post reply on HN
Print view View original

301–310 of 338 posts

Re: Write Libraries, Not Frameworks

#301

Post by tchaffee »

mewpmewp2 wrote: post #105
tanilama wrote: post #83

Earlier quoted context omitted.

Yep. React went from React.createClass -> class xxx extends Component -> Hooks. But I don't think that means...change? The fundamental concept of react, that UI is a derivative from the state, stays the same. Class based or Hook (or just a really nice way to write Functional Component), stays the same.

Fc and hooks force you to think in an entirely different manner though. I would say it is an entirely different paradigm. And it is a much higher learning curve. For instance I see a lot of developers and engineers with 6 months and more experience with functional components and still misunderstanding the point of all of this. And these are smart people at high tier companies. The main thing being the meaning of havi…

Six months? Something is wrong. I learned hooks in a half day. I occasionally ask someone with more experience if I'm using the right hook to solve a specific problem, but that's a one minute question and the rest I can do on my own.

Specifically, how are useEffect dependecies complex? You list the variables that, when changed, should trigger the hook to run. What am I missing? And I'm not claiming no one struggles with hooks. But people also struggled with the lifecycle methods of React classes. In almost every case I've seen this, I've asked the developer to read the React docs. That's usually enough. I'm guessing there is some other underlying more fundamental issue if someone is still struggling with hooks after six months of hand holding.

Re: Write Libraries, Not Frameworks

#302

Post by brundolf »

emn13 wrote: post #211
brundolf wrote: post #36

Earlier quoted context omitted.

You can use React like a library. You can even go without JSX, though nobody really does. React is also kind of odd because it includes a bunch of other stuff like hooks, even though most people bring their own state management to it. But it's definitely the least-framework-y of all the major frameworks.

For years I used react without jsx - with a few minor conventions to make it shorter to write elements via JS (`_div(...)` being equivalent to the jsx ` {...} `, and some minor variant for elems with attrs) it's quite easy to build trees using plain old JS syntax. The advantages of doing that were better tooling support, since everything under the sun supported JS, but not necessarily JSX very well, and jsx isn't rea…

Yep! Really the non-JSX syntax is very close to that of most virtual DOM-based rendering libraries, including the fairly popular Mithril.js

Re: Write Libraries, Not Frameworks

#303

Post by [deleted] »

chrisan wrote: post #233
HarHarVeryFunny wrote: post #223

This discussion reminds me of one of my favorite quotes: "form is liberating". I always associated this with the sculptor Henry Moore, but the beauty of the idea is that it can be applied to all sorts of domains, whence it's also associated with Brook's Mythical Man Month about software development. The association here is that frameworks are "form". One might intuitively think that form/frameworks is/are constrainin…

1 more plus for the form of frameworks. People on your team must be on the same page and work within that form. If everyone is left to their own devices you will get a lot of friction when going into parts of the code you did not create yourself. I like to think of frameworks like a kitchen. The chef sets the menu and everyone works to produce how the chef thought it should be. Sure sometimes you will run into things…

[deleted]

Re: Write Libraries, Not Frameworks

#304

Post by iso947 »

wbl wrote: post #188
iso947 wrote: post #173

Earlier quoted context omitted.

Modern OSes don’t log to simple text files you can grep, tail, watch, open in a text editor, etc.

Unix was an improvement on all its successors.

And then it went downhill about 5 years ago as logs started being stored in binary and hidden by default

Re: Write Libraries, Not Frameworks

#306

Post by juped »

Phoenix is the only web framework I like, because I can understand and control its control flow in a way that I can't with, say, Rails. Plus running on BEAM is great - the whole Erlang ecosystem has always felt like what OOP hype-men promised us in the 90s and 00s, but in reality.

Re: Write Libraries, Not Frameworks

#307

Post by thom »

simongray wrote: post #246
thom wrote: post #212

Earlier quoted context omitted.

It's great that this has been your experience, but I'm on my fourth SQL library at this point. I've been through several HTML rendering libraries, same with authentication, same with config management. The zipper and component libraries I used are abandoned. The data science story is sad compared to the R or Python ecosystems: Incanter dying, clj-ml unmaintained, Fastmath is good for some random stuff but not compreh…

Well, let's agree to disagree then.

If you like, but I don’t believe you can possibly have been using Clojure or ClojureScript in anger for very long if you haven’t had this experience.

Re: Write Libraries, Not Frameworks

#308

Post by avl999 »

wetmore wrote: post #12
userbinator wrote: post #9

A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls. The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago: http://web.archive.org/web/20141018110445/http://discuss.joe... (Sadly, that site is gone, b…

The repeated joke about killing your ex-girlfriend did not age well.

The interesting thing is that Joel is actually gay so he probably specifically went out of his way to not offend the sensibilities of his readers and the culture at large at that time by using "girlfried" as opposed to "partner".

Moreover dark humor has its place. Indeed 2 of the biggest comedies of the last 20 years used exactly this kind of humor (Seinfeld and The Office). Even to this day some of the most acclaimed comedies have humor in this vein (Veep and Curb Your Enthusiasm for eg).

Re: Write Libraries, Not Frameworks

#309

Post by chiph »

bane wrote: post #267
arethuza wrote: post #201

Earlier quoted context omitted.

My comment in that discussion from ~15 years ago was based on experiences with a project that I "inherited" - 30,000 Java classes and interfaces, 20+ layers of abstraction, team of 30+ people working for a long time. And most importantly, it didn't actually work! I actually "finished" it to the point of a working system for the customer with real customers in about 5 weeks by ignoring most of what they had done - req…

Similar experience here. About 6 months ago I inherited a team of 30 that had spent 4 years building some monstrous microservice "thing" that didn't work and never seemed to build reliably and barely worked even if it could be deployed. Lots and lots of late nights trying to "deploy to testing" and wasted weekends restarting things. I stopped the work, broke the team up (and let a few of them go), re-assigned the goa…

We had a similar debacle back during the dot-com boom. We were a Microsoft shop and we got a new CTO who despised our monoculture and demanded a shootout against Java. A large team of consultants and employees labored for almost 10 months to produce a system that scaled to .. 2 simultaneous users while running on the latest Compaq servers with tons of memory. Meanwhile our legacy VB6 app was serving 1600+ users on mid-tier hardware.

Re: Write Libraries, Not Frameworks

#310

Post by nurettin »

bane wrote: post #288
nurettin wrote: post #274

Earlier quoted context omitted.

As someone who fell into a similar situation just last year, I can say that it helps a lot when you have previous work that had been done before you were involved. Perhaps the existing project doesn't show you how things should have been done, but it certainly shows you some of the challenges that were faced and what not to do about them so you don't fall into the same traps as they did. So it's not always "those arc…

I agree with what you say here to a large degree. We were able to reuse things like external service connections, accounts, contracts, some of the requirements documentation and some of the already provisioned hardware, VMs and so on. Those things are not trivial to put together and easily saved us several months of work. Where I think I part ways with you is with this "they did as well as they could using the choice…

This was very well put and definitely agreed with many of the sentiments you've put forth about bottom-up (get up and running with as little rpc as possible) vs sideways development (copy the entire netflix architecture and try to make it work)

I just didn't put the blame on the previous team, maybe I should have for sticking with it for two entire iterations, still not entirely convinced. I think they couldn't help it and the decisions were already made for them by large faceless corporations. I guess what's the point of calling themselves engineers if they don't feel like they are in a cockpit pressing lots of buttons right from the start?

By profession, I call myself a computer programmer, not an engineer or architect in order to remind myself that I should weigh problems by starting from fundamentals such as a state machine, an integer constraint system or a breadth first search, before setting up service discovery or training neural networks.

Post reply on HN