[squidbeak]

Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.

[xgb84j]

The point where frameworks like Angular and React pay off and what I think of as complex projects are those where there is a some nontrivial feature. This coukd be a project with 1 developer working on it for 6 months.

For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.

Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.

While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.

[listenallyall]

> a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals

The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.

[_gabe_]

> the more it benefits the development team to write that code in their language of choice on the backend

Why?

TS is maintainable and very pleasant to code in. Most people’s computers are way faster than making round trips to a server. You talk about serializing everything to/from JSON, but my phone can do that in milliseconds (if not faster). Compare that to 100-200ms of latency between a faraway server, and all of a sudden doing things client side makes sense.

Engineering is all about tradeoffs. I’m tired of people trying to make blanket statements like “React is always better”, or “SSR is always better”. It’s not, and we know it’s not. There are several successful, performant, maintainable apps written using React. There are plenty written using a backend framework and SSR too. Heck, there’s successes that use both!

The common denominators in the success stories? Competent engineers. And I expect a competent engineer can analyze requirements and determine what would be the best outcome for their target users. A booking site absolutely benefits from a front end framework that handles client side logic. It probably also benefits from a clever backend for processing the data after the user is finished with it. Let’s not pretend there’s a one sized solution that fits everything, because there isn’t.

[porker]

> Why?

A tangential answer (focusing on backend not language) is because I'm (we're) going to have to reproduce much of the fronted complexity of the business logic on the backend to validate what the frontend sends.

I'm mostly agreeing with you. I've built multiple web-platformed insurance systems and booking systems in the last decade and moved from fully server rendered pages to client rendered forms. The complexity increased with that change but as you highlight once it's done the ability to test different frontend flows is great.

But I'd like a way to share more of the business logic rather than writing it twice.

[listenallyall]

> Compare that to 100-200ms of latency between a faraway server

A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to make a lot of network calls, so you're going to deal with latency, there's no client-side solution that avoids it without risking the issues above.

[_gabe_]

> almost real-time connectivity with a database

If only they actually worked like this. I’ve experienced, as I’m sure many other people have, problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails because I was too slow. It’s also much faster to only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page.

All that to say, there are tradeoffs. Finding the solution with the best latency and the best experience requires a careful analysis of all these details and figuring out which approach (or combination of approaches) solves that problem the most efficiently. Of course it’s not easy, but nothing you’ve said here indicates one solution would always outperform another solution.

[listenallyall]

> problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails

Because they are typically written using popular heavy frameworks! Big, expert teams of developers can't get it all bug-free and fast and smooth when working with them. Thank you for making my point better than I could.

> only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page

You have revealed by this statement that you have no idea how HTMX works. You are making an argument against something you've clearly never looked at.

[codeptualize]

How are you going to do the updates without FE logic? Refresh the page constantly?

The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.

You make a great point why we use client side solutions.

[listenallyall]

> How are you going to do the updates without FE logic? Refresh the page constantly? The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.

That's exactly why HTMX has gained immediate traction so quickly, it solves many of these exact problems elegantly and easily, much of the time without a single line of JS.

[josephg]

I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on.

The big projects are of course important. But even chrome needs a simple little website with a download link.

[xgb84j]

That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.

[marcus_holmes]

I always see this as a communication/management failure.

Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those.

A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough.

The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.

[Karrot_Kream]

> The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.

But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with technical (e.g. tech bloat) limitations in mind feels important only to technical people and not to actual computing.

[marcus_holmes]

Yeah, I think so.

If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).

Our online lives would be a lot better if the product folks listened to the tech folks a bit more.

I like to draw a parallel to music; if the producer doesn't understand music at all, then maybe they should listen to the musicians a bit when it comes to creating a musical product.

[Karrot_Kream]

> even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).

What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute?

> Our online lives would be a lot better if the product folks listened to the tech folks a bit more.

I mean, according to which metrics? Again this is really popular on HN and other nerd forums but from what I can tell it's just a nerd forum indicator. I think you can make a decent case for involving tech and product together, and I can think of many, but it's a case-by-case basis and has nothing to do with degrading customer experience. This view is popular on HN because we don't actually care here much about actual customers and care more about things like "site payload" and "how much JS is running in my browser". If the argument is that people with older devices won't be able to run the JS like this, I'd argue that your networks have more latency than any bloat you get from JS. Which is why a holistic experience matters more than what your personal tech-experience gets hung up on.