4 ms·

It's great to a point, but when front grows complex enough you sooner or later realize you're repeating a lot of backend logic on the front, and doing a lot of

It's great to a point, but when front grows complex enough you sooner or later realize you're repeating a lot of backend logic on the front, and doing a lot of manual labour keeping track of all states, events, etc. What div is visible, which one to hide, which buttons to disable, adding new rows into forms dynamically with pre-populated values... that kind of stuff is way (and I mean waaaay) easier when coded in a declarative reactive way.

mosselman 7y ago
> later realize you're repeating a lot of backend logic on the front So you mean something like keeping state of forms in something like redux and sending out an event every time you press a button so that state gets update and the change is pushed down the tree of elements so that the letter you just pressed gets rendered in the form? Or did you mean client side validations of forms that you also have in your back-end? Obviously you didn't and I am being a bit of an ass, but this is what is the somewhat recommended way of going around this and it is so convoluted. > doing a lot of manual labour keeping track of all states, events, etc. The state of most web applications can be kept inside of DOM elements and the url just fine. > What div is visible, which one to hide, which buttons to disable This is where CSS-classes and the aforementioned JS libraries come in and they do this job just fine. > adding new rows into forms dynamically with pre-populated values... that kind of stuff is way (and I mean waaaay) easier when coded in a declarative reactive way. I don't believe you are right. It is not easier at all to add some DOM elements with React than it is when you use small bits of JS. Let's say you use jQuery, then it is 1 dependency you add with a small wrapper script for your dynamic form, with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? I don't think I'd build Slack mostly using HTML rendering from the back-end, but most of the things that we build are CRUD applications that can easily be built using things like Ruby on Rails. Let's say the Trello's, Githubs and Amazons of our world.
- ivanhoe 7y ago
  > with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? Because with sufficiently complicated UI you will simply at some point have to start writing abstractions and libraries to help you handle all that mess, and then you'll basically end up building a good part of those "thousands of dependencies" yourself - reinventing the wheel. For smaller projects it's an overkill obviously, no one says you have to use it everywhere. But for bigger projects it's a way more optimal to sacrifice some performance in order to be able to build faster and maintain the project easier, and even if you try to make your own solution chances are that with time it will evolve into something very close to how big players solve it. At least that's what happened to all my custom frameworks (front and backend), 10+ years ago when I myself still believed in not needing extra bloat of frameworks... you one day realize that someone already solved your problem, and solved it way better than you ever would...
  - mosselman 7y ago
    > Because with sufficiently complicated UI This is an argument that I often see from people trying to defend front-end frameworks. That mythical complex UI. So far the only thing I can imagine that comes close might be something like a chat application. Apart from off-line ready apps, I grant you. In that case there would be no point in trying to accomplish that with vanilla JS or jQuery. > But for bigger projects it's a way more optimal to sacrifice some performance in order to be able to build faster and maintain the project easier, I am arguing that you build slower if you build your front-end separately from your back-end rather than use something like Ruby on Rails. > you one day realize that someone already solved your problem, and solved it way better than you ever would... I am saying the problem isn't there 95% of the time. You are just better off rendering HTML and some small pieces of JavaScript. > 10+ years ago when I myself still believed in not needing extra bloat of frameworks... I don't believe this at all, I just oppose the current state of affairs in the JavaScript world and don't subscribe to what is generally considered a good stack. I am not saying you should reinvent the wheel either, I am talking about existing tools like jQuery or Stimulus JS.
    - 7y ago

mosselman 7y ago

> later realize you're repeating a lot of backend logic on the front So you mean something like keeping state of forms in something like redux and sending out an event every time you press a button so that state gets update and the change is pushed down the tree of elements so that the letter you just pressed gets rendered in the form? Or did you mean client side validations of forms that you also have in your back-end? Obviously you didn't and I am being a bit of an ass, but this is what is the somewhat recommended way of going around this and it is so convoluted. > doing a lot of manual labour keeping track of all states, events, etc. The state of most web applications can be kept inside of DOM elements and the url just fine. > What div is visible, which one to hide, which buttons to disable This is where CSS-classes and the aforementioned JS libraries come in and they do this job just fine. > adding new rows into forms dynamically with pre-populated values... that kind of stuff is way (and I mean waaaay) easier when coded in a declarative reactive way. I don't believe you are right. It is not easier at all to add some DOM elements with React than it is when you use small bits of JS. Let's say you use jQuery, then it is 1 dependency you add with a small wrapper script for your dynamic form, with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? I don't think I'd build Slack mostly using HTML rendering from the back-end, but most of the things that we build are CRUD applications that can easily be built using things like Ruby on Rails. Let's say the Trello's, Githubs and Amazons of our world.

ivanhoe 7y ago
> with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? Because with sufficiently complicated UI you will simply at some point have to start writing abstractions and libraries to help you handle all that mess, and then you'll basically end up building a good part of those "thousands of dependencies" yourself - reinventing the wheel. For smaller projects it's an overkill obviously, no one says you have to use it everywhere. But for bigger projects it's a way more optimal to sacrifice some performance in order to be able to build faster and maintain the project easier, and even if you try to make your own solution chances are that with time it will evolve into something very close to how big players solve it. At least that's what happened to all my custom frameworks (front and backend), 10+ years ago when I myself still believed in not needing extra bloat of frameworks... you one day realize that someone already solved your problem, and solved it way better than you ever would...
- mosselman 7y ago
  > Because with sufficiently complicated UI This is an argument that I often see from people trying to defend front-end frameworks. That mythical complex UI. So far the only thing I can imagine that comes close might be something like a chat application. Apart from off-line ready apps, I grant you. In that case there would be no point in trying to accomplish that with vanilla JS or jQuery. > But for bigger projects it's a way more optimal to sacrifice some performance in order to be able to build faster and maintain the project easier, I am arguing that you build slower if you build your front-end separately from your back-end rather than use something like Ruby on Rails. > you one day realize that someone already solved your problem, and solved it way better than you ever would... I am saying the problem isn't there 95% of the time. You are just better off rendering HTML and some small pieces of JavaScript. > 10+ years ago when I myself still believed in not needing extra bloat of frameworks... I don't believe this at all, I just oppose the current state of affairs in the JavaScript world and don't subscribe to what is generally considered a good stack. I am not saying you should reinvent the wheel either, I am talking about existing tools like jQuery or Stimulus JS.
  - 7y ago