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

51–60 of 91 posts

Re: The case for frameworks

#51

Post by meheleventyone »

squidsoup wrote: post #14
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…

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

The issue described relates more to any dependency with the more core and critical the dependency the worse the problem can be. A ‘framework’ is just part of the rough taxonomy of dependencies and happens to often be core and critical.

Re: The case for frameworks

#52

Post by mejutoco »

crabbone wrote: post #50
chrsjxn wrote: post #37

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…

Let's look at it from a different perspective. Web wasn't meant to be an application platform. It accidentally became one, due to events that had nothing to do with technological merit, but were social in nature. For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be. But, it failed due to Adobe's bad market strategy. But Flash, too, was a band-aid on t…

> For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be

Flash was very nice for some use-cases, but it leaked memory. It is not a good fit for long-running apps (probably why Flex/Adobe Air failed, too).

Re: The case for frameworks

#53

Post by robertlagrant »

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.

> If there's a gem/plugin/package that could do something I want in my product...use it

I think that's fine, if you read the source code and are happy putting it in your product, then why not? At that point it's free code.

Re: The case for frameworks

#54

Post by misja111 »

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.

Possibly you will end up with tech debt. But similarly to how most start ups begin with financial debt until their product generates enough revenue, it can also be a perfectly good strategy to allow for tech debt in the beginning. If this enables you to bring a MVP to the market faster than your competitors, you're good.

Re: The case for frameworks

#55

Post by mrweasel »

There's certainly value in frameworks, but like with so many things we build today, most of them are build for a scale that most people don't need.

I'm sure React is great, Angular as well, and VueJS, but they have grown to be all encompassing, so a developer is never stuck and need to rewrite everything. Many frameworks starts up being small, so people can understand them and easily learn. Then as time goes by the frameworks grown until they become to big and someone once again feel the need for a lighter framework and the cycle repeats.

Currently I'm trying to build a VERY small web app. It does need a tiny bit of JavaScript to pull in new data every minute or so. It's much much easier to just forget about using a framework. It would take more time learning how you start a React or Angular project, than just learning the bits of modern JavaScript I need. Then I also don't need to bother with npm, webpack or any other packaging and build non-sense a framework would try to impose on me. That save even more time.

The article is correct that something like React will save developer time, if the project is large enough. If not, simply figurering out which framework to pick and learn how to set it up is going to constitute the majority of the time spend on the project.

Re: The case for frameworks

#56

Post by fleddr »

chrsjxn wrote: post #31
the_gastropod wrote: post #26

Earlier quoted context omitted.

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

Those sound like reasons that allow you to get away with a SPA, as their downsides are minimized. They are not objective reasons to necessitate SPA.

Re: The case for frameworks

#57

Post by dgb23 »

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…

> 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.

Those can be mutually exclusive.

Re: The case for frameworks

#58

Post by dmitriid »

zdragnar wrote: post #27
ian0 wrote: post #11

Earlier quoted context omitted.

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.

I just pulled in a class-based component into a modern React project. It just worked with no adjustment.

Now that's commitment to backward compatibility (and they can't have it any other way, they won't rewrite half of facebook just because their own framework changed).

Re: The case for frameworks

#59

Post by dmitriid »

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…

Don't forget that he's also shaming everyone for complexity while his own work brings untold complexity to the web platform through dozens of Javascript-only standards around Web Components.

Re: The case for frameworks

#60

Post by incrudible »

mrweasel wrote: post #55

There's certainly value in frameworks, but like with so many things we build today, most of them are build for a scale that most people don't need. I'm sure React is great, Angular as well, and VueJS, but they have grown to be all encompassing, so a developer is never stuck and need to rewrite everything. Many frameworks starts up being small, so people can understand them and easily learn. Then as time goes by the f…

> It would take more time learning how you start a React or Angular project…

That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. Really, the argument could end here. Yes, there is overhead in using it, things can get out of hand, but they do not have to. If they do get out of hand, would vanilla web technology have prevented that?

Post reply on HN