4 ms·

We're using React on NFL.com's new home page and Vue on https://nextgenstats.nfl.com/ https://nextgenstats.nfl.com/ (two different teams). AirBnB is mostly Reac

We're using React on NFL.com's new home page and Vue on https://nextgenstats.nfl.com/ https://nextgenstats.nfl.com/ (two different teams). AirBnB is mostly React too.

TekMol 9y ago
Interesting. What would you say are the main advantages over simply passing the data through a server side rendering library?
- ericmcer 9y ago
  You don't have to render stuff on the server?
  - TekMol 9y ago
    I never felt any pain that my servers do rendering. Did you encounter any problems with it?
    - deleted 9y ago
      [deleted]
- IgorPartola 9y ago
  Not the grandparent, but it makes things a lot easier. Basically, think of something as trivial as form validation. You need to do it both client and server-side regardless, but client side you might have additional complexity, like "if paying by credit card, show those fields, and if paying by PayPal, redirect." This means that your server might need to be aware of these branches of state that might happen, and it means complexity. On the other hand, if you keep UI state to the UI layer on the client, the server side becomes super simple: you have an API that says something like "here are the shipping and billing details using a credit card. Charge it" or "shipping and billing details + PayPal token. Charge it." There is no "if we are rendering a PayPal processing error, re-render the entire state of the page, preserving all the checkboxes and showing the right bits of the DOM." It's just pure business logic. Something like Vue is also much better geared at doing a UI than a server-side rendered template. It's dynamic by nature, and directly affects the DOM. The state is kept in such a way that it pertains to the UI. If you are processing something like a request to /orders?filter=recent&order=amount&page=3, you have to re-parse the state from the URL and then get the results every time. Vue/VueX will keep the state in a convenient fashion and the URL can be instructed to reflect it. No need to write custom code to interpret it. Simple CRUD stuff is super easy with Vue + VueX + Bootstrap + Django. That's been my stack and I like it. Complicated stuff if much faster to develop using this than to try to use something like Django templates + jQuery.
  - TekMol 9y ago
    Well, these are the general arguments for these frameworks. But how do they apply to the linked page? I used it for a while and did not come across a Credit Card vs Paypal form.
    - IgorPartola 9y ago
      The linked page simply talks about Using a simpler compilation toolchain than the Vue standard one (Webpack), at the cost of it supporting fewer features. It's sort of like the argument of using clang vs GCC: it assumes you already are using C for your project, just talking about which compiler. Actually a better example would be autotools vs CMake.
- bigmanwalter 9y ago
  In my opinion, client-side rendering is here as a justification for the unfortunate splitting of the Fullstack developer into Frontend/Backend roles. Frontend developer used to be a designer who also knew HTML/CSS but the problem with that is that in order to do CSS well, you need to be a programmer. Especially if you're trying to achieve effects that work best as a mix of JS/CSS. Unfortunately, when it comes to design, UX and UI, most developers are lazy and refuse to learn the basics of it. So in order to prevent PMs from assigning them design-related tasks, the role of Frontend developer was born. And once there was a separate role, it only made sense to isolate the Frontend developers' environment from the backend developers' so that they could stop stepping on each others toes. Essentially, the whole Single Page Application architecture is because there is a class of developers who imagine that it's sensible to completely ignore design considerations and who built a moat around their responsibilities in the form of an unnecessary abstraction. Now rather than our views having direct access to our databases, we need a separate API endpoint for every single database call and since we can't trust client code, we need to authorize/authenticate every single little action rather than being able to blindly trust the code that's being run like we used to.
  - jdavis703 9y ago
    Boy I don't mess the days of dealing with SQL queries inside of PHP "view" files. Reminiscing aside, you can build server-side applications in both Vue and React.
    - bigmanwalter 9y ago
      I'm not advocating for SQL in views. MVC and ORM are great. As is free auth and form generation from database models. I haven't seen a framework that gives me everything that Django or Laravel does for free.
  - k_sh 9y ago
    You are _completely_ missing the point of frontend applications, here's a few to get you started: - Ease of creating complex user flows. - Decentralization of application work: app runs on client, less CPU cycles for my server! - Separation of concerns: API does one thing, client application does another, there is a bright red line between the two.

We're using React on NFL.com's new home page and Vue on https://nextgenstats.nfl.com/ https://nextgenstats.nfl.com/ (two different teams). AirBnB is mostly React too.

TekMol 9y ago

Interesting. What would you say are the main advantages over simply passing the data through a server side rendering library?

ericmcer 9y ago
You don't have to render stuff on the server?
- TekMol 9y ago
  I never felt any pain that my servers do rendering. Did you encounter any problems with it?
  - deleted 9y ago
    [deleted]
IgorPartola 9y ago
Not the grandparent, but it makes things a lot easier. Basically, think of something as trivial as form validation. You need to do it both client and server-side regardless, but client side you might have additional complexity, like "if paying by credit card, show those fields, and if paying by PayPal, redirect." This means that your server might need to be aware of these branches of state that might happen, and it means complexity. On the other hand, if you keep UI state to the UI layer on the client, the server side becomes super simple: you have an API that says something like "here are the shipping and billing details using a credit card. Charge it" or "shipping and billing details + PayPal token. Charge it." There is no "if we are rendering a PayPal processing error, re-render the entire state of the page, preserving all the checkboxes and showing the right bits of the DOM." It's just pure business logic. Something like Vue is also much better geared at doing a UI than a server-side rendered template. It's dynamic by nature, and directly affects the DOM. The state is kept in such a way that it pertains to the UI. If you are processing something like a request to /orders?filter=recent&order=amount&page=3, you have to re-parse the state from the URL and then get the results every time. Vue/VueX will keep the state in a convenient fashion and the URL can be instructed to reflect it. No need to write custom code to interpret it. Simple CRUD stuff is super easy with Vue + VueX + Bootstrap + Django. That's been my stack and I like it. Complicated stuff if much faster to develop using this than to try to use something like Django templates + jQuery.
- TekMol 9y ago
  Well, these are the general arguments for these frameworks. But how do they apply to the linked page? I used it for a while and did not come across a Credit Card vs Paypal form.
  - IgorPartola 9y ago
    The linked page simply talks about Using a simpler compilation toolchain than the Vue standard one (Webpack), at the cost of it supporting fewer features. It's sort of like the argument of using clang vs GCC: it assumes you already are using C for your project, just talking about which compiler. Actually a better example would be autotools vs CMake.
bigmanwalter 9y ago
In my opinion, client-side rendering is here as a justification for the unfortunate splitting of the Fullstack developer into Frontend/Backend roles. Frontend developer used to be a designer who also knew HTML/CSS but the problem with that is that in order to do CSS well, you need to be a programmer. Especially if you're trying to achieve effects that work best as a mix of JS/CSS. Unfortunately, when it comes to design, UX and UI, most developers are lazy and refuse to learn the basics of it. So in order to prevent PMs from assigning them design-related tasks, the role of Frontend developer was born. And once there was a separate role, it only made sense to isolate the Frontend developers' environment from the backend developers' so that they could stop stepping on each others toes. Essentially, the whole Single Page Application architecture is because there is a class of developers who imagine that it's sensible to completely ignore design considerations and who built a moat around their responsibilities in the form of an unnecessary abstraction. Now rather than our views having direct access to our databases, we need a separate API endpoint for every single database call and since we can't trust client code, we need to authorize/authenticate every single little action rather than being able to blindly trust the code that's being run like we used to.
- jdavis703 9y ago
  Boy I don't mess the days of dealing with SQL queries inside of PHP "view" files. Reminiscing aside, you can build server-side applications in both Vue and React.
  - bigmanwalter 9y ago
    I'm not advocating for SQL in views. MVC and ORM are great. As is free auth and form generation from database models. I haven't seen a framework that gives me everything that Django or Laravel does for free.
- k_sh 9y ago
  You are _completely_ missing the point of frontend applications, here's a few to get you started: - Ease of creating complex user flows. - Decentralization of application work: app runs on client, less CPU cycles for my server! - Separation of concerns: API does one thing, client application does another, there is a bright red line between the two.