3 ms·

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

> 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.
- ivanhoe 7y ago
  > So far the only thing I can imagine that comes close might be something like a chat application. Sorry, but if you think that chat is a complex UI you obviously don't understand what type of complexity I'm talking about. Multi-page, multi-level forms with a lot of conditional rendering are far bigger problem to handle than chat. Challenge is not in a single particularly advanced action, forms I'm talking about are mostly just a bunch of ifs and event handlers that update the DOM accordingly. Problem is the overall complexity arising from a sheer number of different combinations you need to control, so you end up with thousands and thousand of lines of jQuery functions and events interacting and stepping on each other's toes. For instance I'm currently working on an IP management app for big, international law firm. In order to invoice a client for even a very basic service like trademark registration you need to handle multiple countries, multiple laws, multiple currencies, and it has to be all in one dynamic form because they need to fill hundreds of those and it has to be simple and quick. These forms are huge, each loads a dozen of subforms, dialogs, etc. conditionally based on different business and legal rules that apply and user has to be able to edit all of that interactively. I've built the first version of that app 10 years ago using jQuery and it worked for a long time, but it took us more than 3 years to fully finish and it was huge and hard to maintain and had a number of limitations, as some legal rules were just too complex to handle. We now did a new version in Vue in less than 6 months. Much easier, much cleaner, our code deals just with our logic, not touching DOM at all, so it's much easier to debug and maintain it. Overall much nicer experience and thanks to that we were able to solve a number of problems that the old version had. And this experience translates to pretty much any serious business web app that I've ever built.
spookthesunset 7y ago
> 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. And oh lord have I seen the result of these home brew “not a framework but actually is a framework” frameworks. They are all a rats nest nightmare for anybody but the original developer to work on. The first thing that happens when the original developer moves on is the whole thing gets rewritten using the framework du joir.

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.

ivanhoe 7y ago
> So far the only thing I can imagine that comes close might be something like a chat application. Sorry, but if you think that chat is a complex UI you obviously don't understand what type of complexity I'm talking about. Multi-page, multi-level forms with a lot of conditional rendering are far bigger problem to handle than chat. Challenge is not in a single particularly advanced action, forms I'm talking about are mostly just a bunch of ifs and event handlers that update the DOM accordingly. Problem is the overall complexity arising from a sheer number of different combinations you need to control, so you end up with thousands and thousand of lines of jQuery functions and events interacting and stepping on each other's toes. For instance I'm currently working on an IP management app for big, international law firm. In order to invoice a client for even a very basic service like trademark registration you need to handle multiple countries, multiple laws, multiple currencies, and it has to be all in one dynamic form because they need to fill hundreds of those and it has to be simple and quick. These forms are huge, each loads a dozen of subforms, dialogs, etc. conditionally based on different business and legal rules that apply and user has to be able to edit all of that interactively. I've built the first version of that app 10 years ago using jQuery and it worked for a long time, but it took us more than 3 years to fully finish and it was huge and hard to maintain and had a number of limitations, as some legal rules were just too complex to handle. We now did a new version in Vue in less than 6 months. Much easier, much cleaner, our code deals just with our logic, not touching DOM at all, so it's much easier to debug and maintain it. Overall much nicer experience and thanks to that we were able to solve a number of problems that the old version had. And this experience translates to pretty much any serious business web app that I've ever built.

spookthesunset 7y ago

> 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. And oh lord have I seen the result of these home brew “not a framework but actually is a framework” frameworks. They are all a rats nest nightmare for anybody but the original developer to work on. The first thing that happens when the original developer moves on is the whole thing gets rewritten using the framework du joir.