Hacker News Reader

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 frameworks and the day we crossed the pain threshold with Relay, dev time slowed to a crawl. Really hindered our ability to ship product as you say, and the switching costs were high, because frameworks underpin everything you do, you can’t just swap them out like libraries

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.

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.

> 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 version in say 300 lines, do it, because it's easier to fix later. Select vendor libraries/pluggins judiciously.

Right, so pick old boring frameworks. Rails, Django, Phoenix, etc.

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

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

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

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

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

It's pretty easy to find that the example I gave isn't gamed... A cursory search on GitHub can find a couple examples like dotenv [1] and npm's cli [2] both use it via an older version of nodejs/readable-stream [3].

There's also the classic left-pad debacle - https://github.com/left-pad/left-pad/issues/4

[1] - https://github.com/motdotla/dotenv/blob/master/package-lock....

[2] - https://github.com/npm/cli/blob/latest/package-lock.json

[3] - https://github.com/nodejs/readable-stream/

> 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

The point is that it's better to depend on something simple and quickly fixable than something convoluted. Vendors/sponsors can and do go away.

If you have a skilled API builder, they know how to do KISS. If a specific need requires something that's not KISS-able, such builders will be honest about it and recommend a pluggin. But every shop and domain is different such there are indeed cases where throwing libraries at the problem is the right tool for that particular job.

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.

This argument reminds me of people who confuse market success with product quality. I.e. some people believe that if the product sells well, then it must be a good product.

You don't need to try hard to convince yourself that there's no causal link between the two (eg. fast food sells well, but isn't good food, high-end goods usually don't sell well because buyers aren't willing to pay extra for marginal improvements).

And so does your argument. The post OP was the reaction to was talking about quality and how misguided the whole field is in terms of using existing, concrete pieces of software s.a. React. And that is, unfortunately, the reality. Web is awful, especially because of how it's been developed, especially due to things like React. But it also sells well. But this wasn't the point.

> Pay people to fix the tech/replace the janky or slow stuff/automate manual things.

Sometimes? When circumstances allow that? This is not a given. And with the way Web is, and the way it's going, it's only getting worse. HTML is a bloated standard. JavaScript is an idiotic language. The GUI toolkit that browser offer is a combo of bloat and idiocy. The whole idea of making "single page applications" is idiotic because Web was never meant for that. It was meant to be an interface to what today we'd call a distributed document database. But is this going to change because individual programmers or individual companies recognize the problem? Are they going to fix / automate it? -- well, there's no way a single company, not even a mega international corporation at this point, which could do that.

The argument the OP was the counter-argument to was saying that Web needs a different foundation and that no modern frameworks are any good. It didn't go as far (as I did) in claiming that the whole stack is garbage. Still, you are missing the point when you are making an abstract argument about using frameworks. The point was: "we have garbage frameworks in Web, and things are getting worse, let's take action to do things differently".

Exactly, the point of frameworks like React is to patch over issues with html, css, javascript and the DOM. Dropping React (the framework) will just make you deal with those issues in particular ways that only you understand, but it won't make them disappear.

That’s strange, I thought the point of React was to make websites slow and laggy so you can save on server costs by just serving json after the initial payload.

Some of us still remember the golden years of doing the same but with jQuery snippets spread through hundreds of files with zero logical connection between them except in the developer's mind.

It's not even ancient history. React is only 10 years old.

I have no issues with frameworks and libs but the fact I know I’m on site built with react because everything gets laggy and my laptops fans start spinning is not a great selling point.

Yes, the web is a terrible platform for applications. Anything on the web that goes beyond the equivalent of linked PDFs will be wonky.

There's nothing on the web even approaching 1990s desktop applications. Specially if you care about latency, precision, and text inputs not randomly eating what you type.

Even with the wonkiness, the web is usually worth using because of the access you get to big amounts of data and backend servers providing nice services.

I've literally never experienced this with react. This sounds like an infinite loop of some sort.

Aaaand... this doesn't make React good. It makes HTML+CSS+JavaScript bad. Here's the problem. These three need fixing. Or, rather, replacing altogether if you want a platform for distributing applications. While any strategy for replacement right now seems impractical, the opposite of it is not good either. Not being able to do the right thing doesn't make the least wrong thing the right thing.

Yes, but as you said the web is a broken platform for applications. Painting a picture where we lived in a perfect world until React introduced some problems is a wrong analysis. React solved some (not all) problems of the web as a platform for GUIs, and introduced a new set of problems. People make their choice and choose which set of problems they prefer to work with.

The web works well for displaying static pages with links between them (if you are ok with some ugly things while the page loads), but once you introduce Forms or any sort of interactivity with the user all hell breaks loose and you will have to choose what you patch over, and what sacrifices you make.

Agreed. I posted this comment a few years ago, but it looks like it's relevant as here as well:

A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.

The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.

They didn’t use a framework.

This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand that code instead of working on the revenue generating features.

We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.

It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.

Did they at least use something like jquery or was it all bespoke code?

> 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 understood commercial activity onto the web or competing with other well-established web businesses from the huge tech companies. Stuff like e-commerce, productivity software, social networking tools, developer tools, financial tools, insurance tools, restaurant booking, hotel booking, doctor booking, etc. These companies probably feel like they need their edge to be things like development velocity and unit economics (e.g. no human customer support), and they probably feel like the only way to do that is to have a bespoke development platform.

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

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

You don't need frameworks to do that though. You can just libraries for authentication that do all the work for you.

The difference is important though. With libraries, you have to connect them to each other. With a framework you don't. But with a framework, if the predefined connection isn't working for your case, you spend way more time to change it. That is, if the framework is good.

That’s good advice for people working at startups, but I work for a huge non-tech Fortune 50 company that employs tens of thousands of people who work on the products. I’m basically paid to spend time on “authentication or forms or worker queues”.

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.

It's also how you end up with a product you can sell now versus a product you can sell in 24 months' 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.

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.

I think there's a problem of what we actually mean when we call something a "framework." Is an ORM a "framework" for interfacing with persistent data stores (usually SQL databases)? Common parlance says it is--and I tend to agree--but, it's also "just" a library to get in between your app and your data, which feels different than, say, a web framework that dictates how your whole project is structured, what auth methods are "supported", what interfaces your handler code is allowed to implement, etc.

But, I also I think your sentiment is somewhere between a generally wise piece of advice/wisdom and a vacuously true statement of fact. The latter because of course you should not reinvent the wheel if there's a perfectly fine wheel already out there.

Frankly, a lot of these things we call frameworks are actually fairly low quality. And I say that with the humility of knowing I couldn't do any better, but that doesn't make it less true. One of my "favorites" to shit on is the Java ecosystem. In particular, JDBC/Hibernate for ORM/SQL stuff, and JacksonXML for (de)serialization. Both are absolutely awful for various reasons, but my go-to example is that JDBC literally doesn't have an API for getting a nullable integer column value out of a ResultSet; instead, you have to get a non-nullable int primitive which will be `0` if the database value was `NULL`, THEN you have to call a second method to ask "Was the previously returned value from this ResultSet actually a NULL instead of whatever I got?". This manifests in Hibernate as requiring an easy-to-forget-or-misuse annotation on your DTO class.

My point is that some of these frameworks are a total nightmare for reliability and robustness, and I'm not convinced that just reflexively opting in to all of the "de facto" frameworks at the beginning of a software project is always the right move.

Prior to product market fit you should take the shortest possible path to delivering your essential feature set. You have a short runway and if you hit the end, it's game over.

That path may or may not involve a framework. One common developer mistake is to use a framework not because it will save time, but because it's a brand name and they think it'll save them from having to learn about a particular problem space.

For example, any developer should be able to build a simple task queue in a couple of days. You can read about how they work, find a simple example or two, and code one. Will it have lots of features? No. Will it scale? No. Does any of this matter before you have product market fit? No.

Along the way you make sure you have good separation of concerns in your overall architecture, so that _if_ it turns out there are many actual humans who want to pay for this idea, you can swap out what you wrote and replace it with something better.

As a bonus, by the time this happens you'll understand task queues (and in particular what your product needs one for) very well. So picking and implementing the right framework will be easy.

If a framework is the easiest way to get to something the market can validate, use it! If it's not, don't.

It's really not that hard to understand how any of the common building blocks of a modern web app works. To understand it deeply, sure, that may take 20 years, but at PMF that depth is not critical yet.

Let's be honest - 80% of the time when we talk about doing things "right" we are really talking about concurrency and scale. Premature optimization is the root of all evil and so on...

> Along the way you make sure you have good separation of concerns in your overall architecture, so that _if_ it turns out there are many actual humans who want to pay for this idea, you can swap out what you wrote and replace it with something better.

This is the key right here. Very little else matters. Where a lot of companies get this wrong is they either go the route of picking a minimal framework and writing everything in-house only to have created a very unique monster that took a lot of time at the end or they go all in on frameworks without identifying the bottlenecks as they go along and they wait until its too late to make an easy transition.

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

Yes yes yes. Great comment, just here to say amen.