9 ms·

Well that is a whole other debate. The best thing about React is common patterns. Second best is the availability of components. I've worked with JavaScript for

Well that is a whole other debate. The best thing about React is common patterns. Second best is the availability of components. I've worked with JavaScript for a long time -- the Backbone.js days were painful. It was easy to accidentally leak event binds, code yourself into a corner, etc. The jQuery days were almost better in some ways but still had some real pain points. You missed that I'm working on SaaS and a web application. Client-side state is important -- each of my customers can load up most of their state to client-side and the performance is great. This is the whole point of client-side apps. Get rid of all that round trip latency sending HTML to the client of every click. Get rid of your complex server-side framework. Client-side is simpler if you learn and embrace it (and don't need server-side rendering). It's also much easier to have a consistent UX with client-side state. So use what is appropriate for you use case. For mine, that is 100% client-side no doubt. You can't beat the performance for an application.

timr 9y ago
"You missed that I'm working on SaaS and a web application" I didn't miss that. SaaS means "software as a service", and doesn't imply anything about the complexity of your UI. Plenty of SaaS companies use server-side rendering. Likewise, "web applications" were being written long before React was a thing. Also no, you don't have to do a full server round-trip for every click, any more than you have to send JSON back to your Reactionary UI for every click. So sure, if you can truly load all of your data in one big JSON blob and do everything else client side, then I guess you're in the 5% of people who can benefit from React. The other 95% should use a good server-side rendering framework and get things like low latency, URL routing, progressive enhancement and SEO-friendly pages for free, and build the few dynamic elements on their pages with a simpler, more robust technology. I never said that React isn't useful, just that it shouldn't be the default choice for most people.
- mottomotto 9y ago
  But I have zero use for SEO-friendly pages -- all my client-side pages are behind a login-wall. It isn't one big blob of JSON -- it's multiple endpoints. With HTTP/2, multiple small requests are fast. > build the few dynamic elements on their pages with a simpler, more robust technology This is a horrible idea that has worked poorly for so many projects. At one potential employer, they did this and their app had a message view with a read count. They didn't care the read count didn't update -- you had to reload the whole page for it to update. Those are the kind of inconsistencies that the above approach encourages because it's not cohesive. Can you do it? Yes. Should you? No, not in my book. > low latency, URL routing, progressive enhancement I've got low latency, I have client-side URL routing, I have no need for progressive enhancement -- it's just more complexity that neither I nor my customers need. These are all great ideas if you have a public website and need to cater to a wide range of visitors. I don't. I'm very happy to be able to only have to support the last couple major versions of each browse.
  - deleted 9y ago
    [deleted]
  - timr 9y ago
    "I've got low latency, I have client-side URL routing, I have no need for progressive enhancement" Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group. Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for the fact that you can't use URLs for their stated purpose. It's honestly sad that we've wandered so far from the norms of the web that URLs have lost their meaning.
    - mottomotto 9y ago
      It's not an ugly hack at all. It works well, the browser history works properly and the interaction is just as if the pages were being fetched from the server. At any point in time, the user can do a hard reload and the page will rerender as it did before. The URLs are the same as if I was doing server-side rendering. So I would ask you at this point to turn this all around. Look at it from my perspective. I've been doing fullstack for more than a decade (professionally, hobbyist for twice as long) so I've done plenty of server-side rendering in frameworks like Ruby on Rails, ASP.net MVC, etc. I've contributed (as lead) to open source gems that have over 800k downloads. So I have invested a lot of time into the server-side. But today, with client-side, there is a huge simplicity factor. You can only get to it after wading through the turbulent waters of "flavor of the week" client-side projects and noise. But when you do get through that and identify your pillars to build on, this is what you have: * all of your complexity is on the client-side for web * you can make a simple fairly clean REST or GraphQL backend that will work with multiple clients (web, mobile, etc) * for at least REST, you no longer really need things like an ORM on the server-side as all of the endpoints are simple and basically fetching a single data type (I use SQL with PostgreSQL so I would say a table here but it depends on implementation) * HTTP/2 reduces the cost of small requests so complex things like GraphQL aren't really necessary -- you can stay with REST without a penalty Is there complexity? Is it different? Does it challenge the conceptions of those used to fullstack? Yes. But there is real value and simplicity here too that you might find if you're willing to put aside your hard and fast rules and try something new.

timr 9y ago

"You missed that I'm working on SaaS and a web application" I didn't miss that. SaaS means "software as a service", and doesn't imply anything about the complexity of your UI. Plenty of SaaS companies use server-side rendering. Likewise, "web applications" were being written long before React was a thing. Also no, you don't have to do a full server round-trip for every click, any more than you have to send JSON back to your Reactionary UI for every click. So sure, if you can truly load all of your data in one big JSON blob and do everything else client side, then I guess you're in the 5% of people who can benefit from React. The other 95% should use a good server-side rendering framework and get things like low latency, URL routing, progressive enhancement and SEO-friendly pages for free, and build the few dynamic elements on their pages with a simpler, more robust technology. I never said that React isn't useful, just that it shouldn't be the default choice for most people.

mottomotto 9y ago
But I have zero use for SEO-friendly pages -- all my client-side pages are behind a login-wall. It isn't one big blob of JSON -- it's multiple endpoints. With HTTP/2, multiple small requests are fast. > build the few dynamic elements on their pages with a simpler, more robust technology This is a horrible idea that has worked poorly for so many projects. At one potential employer, they did this and their app had a message view with a read count. They didn't care the read count didn't update -- you had to reload the whole page for it to update. Those are the kind of inconsistencies that the above approach encourages because it's not cohesive. Can you do it? Yes. Should you? No, not in my book. > low latency, URL routing, progressive enhancement I've got low latency, I have client-side URL routing, I have no need for progressive enhancement -- it's just more complexity that neither I nor my customers need. These are all great ideas if you have a public website and need to cater to a wide range of visitors. I don't. I'm very happy to be able to only have to support the last couple major versions of each browse.
- deleted 9y ago
  [deleted]
- timr 9y ago
  "I've got low latency, I have client-side URL routing, I have no need for progressive enhancement" Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group. Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for the fact that you can't use URLs for their stated purpose. It's honestly sad that we've wandered so far from the norms of the web that URLs have lost their meaning.
  - mottomotto 9y ago
    It's not an ugly hack at all. It works well, the browser history works properly and the interaction is just as if the pages were being fetched from the server. At any point in time, the user can do a hard reload and the page will rerender as it did before. The URLs are the same as if I was doing server-side rendering. So I would ask you at this point to turn this all around. Look at it from my perspective. I've been doing fullstack for more than a decade (professionally, hobbyist for twice as long) so I've done plenty of server-side rendering in frameworks like Ruby on Rails, ASP.net MVC, etc. I've contributed (as lead) to open source gems that have over 800k downloads. So I have invested a lot of time into the server-side. But today, with client-side, there is a huge simplicity factor. You can only get to it after wading through the turbulent waters of "flavor of the week" client-side projects and noise. But when you do get through that and identify your pillars to build on, this is what you have: * all of your complexity is on the client-side for web * you can make a simple fairly clean REST or GraphQL backend that will work with multiple clients (web, mobile, etc) * for at least REST, you no longer really need things like an ORM on the server-side as all of the endpoints are simple and basically fetching a single data type (I use SQL with PostgreSQL so I would say a table here but it depends on implementation) * HTTP/2 reduces the cost of small requests so complex things like GraphQL aren't really necessary -- you can stay with REST without a penalty Is there complexity? Is it different? Does it challenge the conceptions of those used to fullstack? Yes. But there is real value and simplicity here too that you might find if you're willing to put aside your hard and fast rules and try something new.