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

The case for frameworks

seldo.com

Post reply on HN
Print view View original

11–20 of 91 posts

Re: The case for frameworks

#11

Post by ian0 »

tabtab wrote: post #5
dchuk wrote: post #3

Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. Product market fit is generally achieved when yo…

> Frameworks and plug-ins exist to allow this to be all plug and play Too many are buggy and/or poorly documented and take lots of trial and error to get working as intended. And you create a dependency mess by including lots of pluggins/libraries. It may be quick up front, but can jack maintenance after say 5-ish years. Multi-K-lines-of-code libraries "rot" as environments change. If you can write a shop-tuned versi…

This is true and in experience happens far quicker than 5 years for JS frameworks. Most of the frameworks I learned 5-10 years ago are already effectively dead too.

But I think OPs main point stands, your far more likely to die by not shipping things early than by having to refactor occasionally. After 5 years 50% of businesses have failed [0] and this is far far higher for startups & side projects.

[0] https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.ht...

Re: The case for frameworks

#12

Post by tshaddox »

dchuk wrote: post #9
tshaddox wrote: post #8

Earlier quoted context omitted.

> Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. How unique is your product really though? If you're a biotech company or something that also needs a website, sure, use whatever the most widely used framework is at the moment. But I feel like most of the focus of these discussions is on web-native SaaS companies whose entire business is on moving some well…

A decent rule of thumb I follow: If there's a gem/plugin/package that could do something I want in my product...use it. Don't write the code yourself, unless it actually straight up can't provide the UX or capability you need for your product.

It's hard to argue with a rule of thumb that broad, but I think it's too broad to be useful in practice. You will still always need to make case-by-case decisions at your own discretion, and the rule of thumb will be unnecessary in uncontroversial cases (you probably won't even consider writing your own code to format a number as a string on your website) and will easily be ignored in other cases ("yes, we could just build our homepage and merch page in Squarespace, but we're going to want total control over that entire product so we're going to build it ourselves").

Re: The case for frameworks

#14

Post by squidsoup »

hudon wrote: post #6
dchuk wrote: post #3

Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. Product market fit is generally achieved when yo…

The “don’t reinvent the wheel “ argument is overstated. If you’re avoiding frameworks, you tend to build up your own libs that “plug and play”. It’s not like you rewrite a sessions lib every time you build a new backend server. You copy the file over from your last project. If it’s a more involved problem, like correctly implementing HTTP, you use a battle tested library. I’ve worked at a startup that went all in on…

When you refer to Relay, do you mean the graphql client? If so, would you really describe that as a framework?

Re: The case for frameworks

#15

Post by tabtab »

ian0 wrote: post #11
tabtab wrote: post #5

Earlier quoted context omitted.

> Frameworks and plug-ins exist to allow this to be all plug and play Too many are buggy and/or poorly documented and take lots of trial and error to get working as intended. And you create a dependency mess by including lots of pluggins/libraries. It may be quick up front, but can jack maintenance after say 5-ish years. Multi-K-lines-of-code libraries "rot" as environments change. If you can write a shop-tuned versi…

This is true and in experience happens far quicker than 5 years for JS frameworks. Most of the frameworks I learned 5-10 years ago are already effectively dead too. But I think OPs main point stands, your far more likely to die by not shipping things early than by having to refactor occasionally. After 5 years 50% of businesses have failed [0] and this is far far higher for startups & side projects. [0] https://www.b…

> your far more likely to die by not shipping things early than by having to refactor occasionally.

Know your org. A startup has very different priorities than a bank, for example.

Small projects need different conventions than big projects, internal need diff than external, 200 user apps need diff than "web scale", etc. I'm more careful now to state the assumed environment because one size doesn't fit all. And fit your org, not your resume. Buzzword oriented programming is selfish; I've seen it make screwball messes.

Re: The case for frameworks

#16

Post by nicoburns »

tabtab wrote: post #2

I've said it before and I'll say it again. The main reason we need bloated convoluted web frameworks with giant learning curves and a jillion gotcha's is because businesses want desktop-like GUI's and HTML/DOM/CSS/JS is ill-suited to emulate such, and perhaps stuck that way because fixing it will likely break backward compatibility. Web is either missing or has screwed up too many common and expected GUI idioms: http…

Web frameworks are complicated. But frameworks like QT are no less complicated.

Re: The case for frameworks

#17

Post by account-5 »

tabtab wrote: post #2

I've said it before and I'll say it again. The main reason we need bloated convoluted web frameworks with giant learning curves and a jillion gotcha's is because businesses want desktop-like GUI's and HTML/DOM/CSS/JS is ill-suited to emulate such, and perhaps stuck that way because fixing it will likely break backward compatibility. Web is either missing or has screwed up too many common and expected GUI idioms: http…

The proliferation of frameworks and confusion as to which one I should take the time to learn has pushed me towards dart/flutter as a solution for a cross platform GUI language.

Having said that I have been looking at htmx recently.

Re: The case for frameworks

#18

Post by AWebOfBrown »

Everything I needed to know about Russell's performance war was answered when, whilst he was working at Google, folk started asking him why he was naming and shaming companies for poor performance when his exact critiques were swiftly applied to Google's apps (calendar, maps, gmail). I wish I could find the twitter thread from back then, but the gist of his response was that what Google was doing was incredibly complicated, far more than anything the targets of his ire were working on, and as such it was reasonable not to have fixed those issues.

He wasn't wrong in his assessment of complexity, but the fact he refused to acknowledge the business priorities were the same between Google and companies he called out, absolutely baffled me. The gist from my perspective was that companies external to his own should bend over backwards for performance, while his should not, because his personal goals were tied to improving the performance of the web. Hopefully that's an over-simplification and I've missed something, but that's what I can recall.

Re: The case for frameworks

#19

Post by samsquire »

rektide wrote: post #4

There's been shockingly little mainstream change in how we write apps in the browser. Not a lot of frameworks have stepped up to present interesting new compelling capabilities. To Alex's point: it's not just that the customer doesn't know what they're buying, it's that there's not much significant difference between the goods (frameworks) and most get us to similar ends. Mainly I think this boils down to there not b…

This is really interesting comment and thought provoking. Thank you.

I especially enjoyed the part of building frontend apps more as a server of communicating processes.

My interest is multithreading and parallelism. If I could write frontend software in the style of processes, that would be awesome.

Re: The case for frameworks

#20

Post by jeremycarter »

tabtab wrote: post #2

I've said it before and I'll say it again. The main reason we need bloated convoluted web frameworks with giant learning curves and a jillion gotcha's is because businesses want desktop-like GUI's and HTML/DOM/CSS/JS is ill-suited to emulate such, and perhaps stuck that way because fixing it will likely break backward compatibility. Web is either missing or has screwed up too many common and expected GUI idioms: http…

I've been saying a similar thing for years too. Anyone want to team up to make attempt #27 at this problem?
Post reply on HN