[CooCooCaCha]

I’ve been saying this for a long time. It takes very little effort to spin up a react app so there’s little point in starting a project without it or whatever front-end framework you prefer.

As I’ve become more senior I’ve realized that software devs have a tendency to fall for software “best practices” that sound good on paper but they don’t seem to question their practical validity. Separation of concerns, microservices, and pick the best tool for the job are all things I’ve ended up pushing back against.

In this particular case I’d say “pick the best tool for the job” is particularly relevant. Even though this advice is hard to argue against, I think it has a tendency to take developers down the path of unnecessary complexity. Pragmatically it’s usually best to pick a single tool that works decently well for 95% of your use cases instead of a bunch of different tools.

[quantadev]

I agree, just use React from day one. The reality is that web pages are hardly ever perfectly static, and once there's any dynamic nature to it at all you need something like React or else you'll have a train wreck of JS DOM-manipulation calls before you know it. React is perfect. You just update your state and the page magically re-renders. It's a breeze.

[lemonwaterlime]

Multiple times in this thread you have been taking the hardline stance that a framework is always necessary while stating that others are saying the same in the opposite direction. In reality, most people seemingly advocating for non-React are actually saying to start simple and add the complexity where and when it’s needed.

Further, being against a bloated framework is not the same as being against frameworks. Those frameworks are actually principles. It’s possible for a team to come up with or use existing principles without using a framework.

Finally, “always use React” brings other costs. You need a team to build your system twice. That means you need bigger teams; more funding to do the same thing, and so on. You add complexity at the team level and at the software level when using frameworks. The person above you said that blindly “following best practices” is bad while stating a “best practice” of always start with React. That particular “best practice” not always being the best practice is the entire point of this thread.

[CooCooCaCha]

Your reading of my point is very strange. When I said “best practices” I clearly meant the most commonly repeated best practices. If I cast doubt on those best practices then clearly I intend to replace them with other best practices that I think are better, and that’s what I did. And suggesting better practices doesn’t imply that I think people should blindly follow them.

> Most people seemingly advocating for non-React are actually saying to start simple and add the complexity where and when it’s needed.

In my experience that’s actually not the case. That might be what people claim, but in my professional experience some people really don’t like frontend work and they try to avoid frontend frameworks because they think it’ll make their work more tolerable, but what usually happens is they start out “simple” but pretty quickly product requirements come in that are hard to do without some framework, then there’s a scramble to add a framework or hack it into some parts of the app.

[yawaramin]

So there are a couple of problems with your characterization. Firstly, your blanket assumption that people who want to avoid frontend complexity are really just frontend haters. Sure, there are some people who hate 'web shit', but there are many others, like myself, who want to build useful webapps that are as simple and performant as possible. It doesn't make us frontend haters, it just makes us different.

The second assumption where I believe you are going wrong is that 'product requirements' will always come in and force using a framework. Imho if I look around at most of the webapps I am using, very few of them actually need a SPA framework. Take Jira for example. Does it really need to be fully a SPA? It has some highly interactive parts, which could be done with eg web components, but it's mostly a boring CRUD app that would work fine with eg htmx.

[quantadev]

Exactly right. The "start simple and add the complexity where and when it’s needed" is a badly flawed way of thinking, in web apps, because once an app becomes too big to manage without BOTH a framework AND a type-safe language (TypeScript) then it you realize everything you've done up to that point must be reworked line by line, which costs you weeks, and you have to retest everything, and will make mistakes as you try to fix the mess. It's a mess that's easily avoided, just by using a framework from day one.

You can't just switch horses in the middle of the stream. You have to ride back to the ranch, saddle up on a different horse, and restart your entire journey on a better horse.

[quantadev]

I went out of my way to say it's only my preference to use React, but that Vue is fine too. So the thing I have a "hardline stance" (your words) on, if anything, is that a framework should be used for any interactive web app.

Having been a web developer for a quarter century, I know how tempting it is (yes, for small projects) to try to just wing it and do everything without a framework, and I know what a tarpit that way of thinking is. If you disagree, then you were certainly welcome to share you own opinion.

[robertoandred]

> most people seemingly advocating for non-React are actually saying to start simple

This assumes that non-React approaches are simple.

[quantadev]

That's a good point. non-Framework approaches are not simpler actually. It's a tarpit that looks enticing. You think you can keep stuff "simple" by not using a framework, and in only 2 weeks you've got such complexity you're begging for a framework that does it all automatically, which is kinda...ya know...what frameworks are for. lol.

So you delete the non-framework garbage code and start over. lol.