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

31–40 of 91 posts

Re: The case for frameworks

#31

Post by chrsjxn »

the_gastropod wrote: post #26
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?!

Long running sessions seems pretty straightforward. The cost of an SPA is heavily front-loaded, so the longer you have the app open, the more that cost can be spread.

Authenticated content is likely for a mix of reasons. It can't be indexed, so doesn't need to optimize for SEO. Users that log in are higher intention, so they're less likely to bounce if the page loads slowly.

It's definitely more complex than just these things, but the inverse (an app that requires SEO and minimal upfront costs) are often used as justifications for moving away from modern frameworks.

Re: The case for frameworks

#32

Post by santoshalper »

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…

Yeah, but you're still likely reinventing capabilities that exist in react or a plugin. Even if you re-use it, you still have to build it the first time instead of iterating on your product.

Re: The case for frameworks

#33

Post by technojunkie »

As long as WordPress fully embraces React as its future for Gutenberg, the case for frameworks still continue to be made for React. ~43% of all websites run WordPress, and those on version 5 or newer include React.

Try to convince modern developers who build Gutenberg blocks to use React-free libraries or frameworks for their component libraries or front-end.

Re: The case for frameworks

#34

Post by dools »

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.

It's also how you end up with a product you can sell now versus a product you can sell in 24 months' time.

Re: The case for frameworks

#35

Post by regularjack »

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.

In the projects that I've encountered, the ones that ended up with massive tech debt were the ones that didn't use a framework.

Re: The case for frameworks

#37

Post by chrsjxn »

It's fun to look back on the success of SPAs from the perspective of someone who learned to build websites pre-jQuery.

jQuery allows for websites to be interactive with minimal latency, but it's pretty low level so it leads to a lot of common problems. Like locking the main thread, undisciplined architectures, and a ton of issues with back/forward navigation.

SPA frameworks are developed to solve jQuery problems, but they introduce some new ones. Everything being JS is a big win, compared to split apps. But you have to deal with the up front cost of loading all the JS and a higher memory footprint.

And we iterate. SSR frameworks tone down the up front cost of SPAs in favor of more complex infrastructure. Frameworks that deploy to edge networks take another bite out of latency, but it isn't entirely clear what that will mean long term.

It feels so iterative that blaming framework popularity on malice is wild. There are real benefits to businesses, developers, and customers at every step along the path. Of course developers are going to follow along.

Re: The case for frameworks

#38

Post by [deleted] »

santoshalper wrote: post #32
hudon wrote: post #6

Earlier quoted context omitted.

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…

Yeah, but you're still likely reinventing capabilities that exist in react or a plugin. Even if you re-use it, you still have to build it the first time instead of iterating on your product.

[deleted]

Re: The case for frameworks

#39

Post by waboremo »

ramones13 wrote: post #28
waboremo wrote: post #21

Earlier quoted context omitted.

> 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

NPM statistics are easily gamed https://dev.to/andyrichardsonn/how-i-exploited-npm-downloads...

I don't doubt there are a lot of insignificant packages being used, again especially by beginners, I just don't buy it's to that scale

Re: The case for frameworks

#40

Post by swyx »

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…

“it is difficult to get a man to understand something, when his salary depends on his not understanding it.” - Upton Sinclair.
Post reply on HN