5 ms·

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

by xgb84j 3y ago

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 3y ago
> 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_ 3y ago
  > 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.
  - listenallyall 3y ago
    > 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.
    - codeptualize 3y ago
      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 3y ago
        > 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.
    - _gabe_ 3y ago
      > 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.

by xgb84j 3y ago

listenallyall 3y ago

> 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_ 3y ago
> 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.
- listenallyall 3y ago
  > 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.
  - codeptualize 3y ago
    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 3y ago
      > 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.
  - _gabe_ 3y ago
    > 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.