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

21–30 of 91 posts

Re: The case for frameworks

#21

Post by waboremo »

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…

> shop-tuned version in say 300 lines

But if that was the case, you would do that, resorting to other tools for something that tiny is silly and only really done by beginners. Something that tiny would also unlikely have bug or documentation issues.

There are some great tools that are poorly documented/buggy, yes, but they are quite rare and it's much easier to use them and fork the repo (if inactive) than to build from scratch.

This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal, and far more likely to have poor documentation than open source plugin #4159. So you really haven't solved or avoided the problem at all.

Re: The case for frameworks

#22

Post by bentlegen »

I thought this was an interesting, alternative lens at looking at the economic balance between supporting long-tail customers with higher performance needs vs. developer time/cost. I suspect internationalization efforts operate similarly; it’s not often worthwhile to translate your software into many languages, many of which are rarely read/spoken by users of your software.

Re: The case for frameworks

#23

Post by segphault »

I am deeply sympathetic to Alex Russell's position on frameworks, but the reality is that he's never going to move the needle by badgering developers to prioritize performance over developer experience. The ecosystem won't move on from React to more performant and standards-based alternatives until those alternatives provide a competitive developer experience.

As someone who wants to advocate for standards instead of frameworks in my org, the problem I have is that the standards process is moving too slowly to address very basic and obvious developer needs. For example, the fact that Web Components are registered in a global namespace is really inconvenient in a large organization where you have many different teams making a large number of components. Sure, you can work around this with a BEM-like naming scheme, but you shouldn't have to. There's a great proposal for scoped custom element registries by one of the Lit developers that would actually address this issue, but it's been sitting in a repo for years without any meaningful activity and there doesn't appear to be any momentum around implementing it. Meanwhile, this is a thoroughly solved problem in the React and Vue ecosystems. That's just one small example, there are a ton of other papercuts and annoyances that there's no hope of fixing in the foreseeable future if solving them is going to involve a years-long slog through the standards process.

The DOM part spec that emerged from Apple's template instantiation proposal has the potential to provide an extremely efficient standards-based target for React-like frameworks that would solve a lot of the performance problems, especially if it's used judiciously for just the dynamic parts of the page in conjunction with server rendering and declarative shadow DOM. But nobody seems to be working on making that a reality, activity on that spec is pretty much dormant. React is going to keep winning until the standards furnish comparable ergonomics.

Re: The case for frameworks

#24

Post by mattgreenrocks »

AWebOfBrown wrote: post #18

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 compl…

Ah yes, the classic "our problems are the hardest" perspective.

These are usually the narratives we tell ourselves to let ourselves off the hook.

Re: The case for frameworks

#25

Post by ramones13 »

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…

IMO, aggressive npm install is the superset of the framework problem. We code review every line written by other developers at our company with a fine toothed comb, but will add a dependency from a massive advertising company or some dude in Russia without a second thought. It’s wild.

Re: The case for frameworks

#26

Post by the_gastropod »

onlypositive wrote: post #13

Half of those example sites he says should be SPAs should not be SPAs at all. They can be, and are, but certainly don't need to be by any stretch.

Yea. I didn’t understand the criteria given: long running sessions and authenticated content. Why do those necessitate a SPA?!

Re: The case for frameworks

#27

Post by zdragnar »

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…

The major JS frameworks have all been around for 5 years; several for 10 (react turns 10 this May).

Compare that to the average tech employee tenure, or even the average lifetime of a startup company.

Re: The case for frameworks

#28

Post by ramones13 »

waboremo wrote: post #21
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…

> shop-tuned version in say 300 lines But if that was the case, you would do that, resorting to other tools for something that tiny is silly and only really done by beginners. Something that tiny would also unlikely have bug or documentation issues. There are some great tools that are poorly documented/buggy, yes, but they are quite rare and it's much easier to use them and fork the repo (if inactive) than to build f…

You would think that, but this seven line NPM package has 68M downloads a week - https://www.npmjs.com/package/isarray

Re: The case for frameworks

#29

Post by ramones13 »

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…

This is how you end up with massive tech debt though right? Replacing a dependency is going to be more expensive than writing something yourself, especially if it’s been around a long time.

Re: The case for frameworks

#30

Post by drewbug01 »

ramones13 wrote: post #29
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…

This is how you end up with massive tech debt though right? Replacing a dependency is going to be more expensive than writing something yourself, especially if it’s been around a long time.

The length of time a thing is around is the key bit, not whether or not you initially wrote it yourself.
Post reply on HN