7 ms·

It's just apples and oranges. Web pages should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you n

It's just apples and oranges. Web pages should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you need, and then server side rendering for the content. Building web applications on the other hand, has been revolutionized by the use of React. I would never seriously consider any other UI rendering library right now because of the sheer volume of support and active development around it and its' ecosystem. And hand rolling vanilla JS in a large scale web application quickly becomes a maintainability nightmare. The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend.

deleted 6y ago
[deleted]
gvjddbnvdrbv 6y ago
> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend. This depends on project size. If a single team is working fullstack then using server side templates gives seriously faster product development iteration. Once you get to more than 5-10 devs and you want separate frontend and backend teams then it slows down.
- ralls_ebfe 6y ago
  Why can't the server-side template rendering code consume an api as much as frontend JavaScript can? I don't see any reason for this to happen in the browser.
  - unethical_ban 6y ago
    The first time I got even close to a custom web page (internal request system for our team), the devs did this. They wrote it as two Bottle (python) applications: One was the API for the app, the other was the delivery of the Javascript to the client, which called the API.
  - bernawil 6y ago
    the template rendering lives side by side with the controllers, why would it make an api call? But something similar but not the same as that was the norm during the jquery era before the early js frameworks arised (backbone, ember et all). You had your full-stack server-side MVC framework render initial views and from there the js would pick up and all UI interactivity would be ajax calls to the restful(ish) api. It was pretty terrible.
    - piranha 6y ago
      > why would it make an api call Because this introduces clear separation of concerns? You don't need to make this API call via HTTP, you can just call a function. You don't even need to generate/parse JSON! I know that because this is what we are doing. Just calling a function called "httpapp". :)
      - bernawil 6y ago
        Well, but then it's not the same api call and that's the point: that in the old mvc frameworks it was painful having to support controllers that both rendered html and json for doing both SSR and Ajax. Around the time the first js FE frameworks came out, people finally became confident enough to have pure js clients and only json APIs. And finally gatsby, next.js, etc. brought a new twist to the SSR and Ajax api combo.
  - andrei_says_ 6y ago
    Check out Turbolinks which does load and replace the html body from the server and leaves the head content in place, thus preventing the re-evaluation of css and is at each pageload. It’s backend-agnostic. https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
  - deleted 6y ago
    [deleted]
  - hombre_fatal 6y ago
    Probably because of how awkward it is. You essentially have this weird html-emitting "client-server" moving part in a limbo where it's still a one-to-many server. And it has to duplicate client code you probably still need anyways in the Javascript that runs in the browser (and, don't you want to do take advantage of some client benefits like being able to work offline or cache locally?). And this bonus moving part is only for your web clients, not something you use for any other client (iOS, Android, etc). NextJS is something that folds over some of this, but it's not without its issues. Of course, no better way to find out than try it for yourself. When I have the question of "why don't people just do X?", trying X myself is a quick way to realize why, and unfortunately it's never because I'm the first genius to have thought of it.
RandoHolmes 6y ago
This all indicates that browsers and html/css are bad tools for creating UI. Long term I think we'll eventually see the ability to interact with the local system via the browser, and we'll start seeing more things like "QT for the web". Because if we don't, at some point it's all going to just fall over.
- sparks1970 6y ago
  Qooxdoo? https://qooxdoo.org/ https://qooxdoo.org/ ?
- heavyset_go 6y ago
  Qt for the web already exists within Qt.
  - RandoHolmes 6y ago
    That is not what I'm referring to, you're concentrating too hard on the specific example rather than the idea behind it.
- deergomoo 6y ago
  Yes. HTML is a terrible platform for applications. It provides basically nothing and I am continually surprised that it doesn’t seem to be a major focus for improvement like JS and CSS. I don’t need more types of semantic rectangle, I need actual real UI controls that are efficiently rendered and accessible by default, so I don’t have to build everything from scratch. The fact that there’s no built-in element for things like dropdown menus is mind boggling to me. That’s GUI component #0; menus have existed for as long as GUIs have! I feel that Houdini may eventually solve CSS’ shortcomings for application UI layout, but being stuck with HTML is like trying to build an aeroplane with sticks and mud.
  - pattycakes 6y ago
    >The fact that there’s no built-in element for things like dropdown menus is mind boggling to me. You mean the select tag?
Shorel 6y ago
And who decides which is which? You?
- svachalek 6y ago
  These days nothing is purely static and very little is purely interactive/dynamic. However most sites lean clearly to one side or the other, no judgment call or personal defensiveness required.
  - ClumsyPilot 6y ago
    Most sites straddle the muddy line in-between, or start off as webpages and mutate into web-apps over time as more functionality gets added on.
tomc1985 6y ago
> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend. Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a lot of functionality you can implement that doesn't need JS at all
- PretzelFisch 6y ago
  At this point, I think we'll start to see an electron shell that you can install apps/extensions into. The main thing that will prevent this from gaining traction is ios.
- mawise 6y ago
  +1 to this. I wanted to build a private blogging app/site with a big focus on speed and performance, it might not be popular anymore but I went with Rails. Server-side rendering lets the browser do what it's good at. The only thing that would make pages load faster would be to stick them behind a CDN (which doesn't play nice with the privacy aspect). If anyone is interested I put up a page talking about the project: https://simpleblogs.org https://simpleblogs.org
  - nawgz 6y ago
    See but the parent comment is about "web applications" not "web pages". You are describing a web page - there is limited or no interactivity, what is there can be reasonably handled by forms. No one doubts that React isn't the tool for this area
    - learc83 6y ago
      Take a look at the hey email client. It's built by basecamp--the guys who created rails. As for web app vs web page--it's a very blurry line, and it's rare that I end up building something where the entire site could be considered a web app. Usually only some small pieces of it demand enough interactivity to bother with the complexities of using a UI framework, and for that I wrap a small React or a Svelte app in a div and throw it on a page within the larger site.
bromuro 6y ago
You don’t need even build always a SPA with React. For interactive widgets, Resct works better to me than jQuery.
bmarkovic 6y ago
It is also a frustrating experience to endure reloads on every click if what the user is using feels like a web application and you're essentially placing that burden of reducing the interaction roundtrip time on your infrastructure which gets expensive really really fast. Most web-thingies are neither 100% plain websites nor 100% plain webapps, most are in the middle, some are heavily leaning on one side or the other.

deleted 6y ago

[deleted]

gvjddbnvdrbv 6y ago

> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend. This depends on project size. If a single team is working fullstack then using server side templates gives seriously faster product development iteration. Once you get to more than 5-10 devs and you want separate frontend and backend teams then it slows down.

ralls_ebfe 6y ago
Why can't the server-side template rendering code consume an api as much as frontend JavaScript can? I don't see any reason for this to happen in the browser.
- unethical_ban 6y ago
  The first time I got even close to a custom web page (internal request system for our team), the devs did this. They wrote it as two Bottle (python) applications: One was the API for the app, the other was the delivery of the Javascript to the client, which called the API.
- bernawil 6y ago
  the template rendering lives side by side with the controllers, why would it make an api call? But something similar but not the same as that was the norm during the jquery era before the early js frameworks arised (backbone, ember et all). You had your full-stack server-side MVC framework render initial views and from there the js would pick up and all UI interactivity would be ajax calls to the restful(ish) api. It was pretty terrible.
  - piranha 6y ago
    > why would it make an api call Because this introduces clear separation of concerns? You don't need to make this API call via HTTP, you can just call a function. You don't even need to generate/parse JSON! I know that because this is what we are doing. Just calling a function called "httpapp". :)
    - bernawil 6y ago
      Well, but then it's not the same api call and that's the point: that in the old mvc frameworks it was painful having to support controllers that both rendered html and json for doing both SSR and Ajax. Around the time the first js FE frameworks came out, people finally became confident enough to have pure js clients and only json APIs. And finally gatsby, next.js, etc. brought a new twist to the SSR and Ajax api combo.
- andrei_says_ 6y ago
  Check out Turbolinks which does load and replace the html body from the server and leaves the head content in place, thus preventing the re-evaluation of css and is at each pageload. It’s backend-agnostic. https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
- deleted 6y ago
  [deleted]
- hombre_fatal 6y ago
  Probably because of how awkward it is. You essentially have this weird html-emitting "client-server" moving part in a limbo where it's still a one-to-many server. And it has to duplicate client code you probably still need anyways in the Javascript that runs in the browser (and, don't you want to do take advantage of some client benefits like being able to work offline or cache locally?). And this bonus moving part is only for your web clients, not something you use for any other client (iOS, Android, etc). NextJS is something that folds over some of this, but it's not without its issues. Of course, no better way to find out than try it for yourself. When I have the question of "why don't people just do X?", trying X myself is a quick way to realize why, and unfortunately it's never because I'm the first genius to have thought of it.

RandoHolmes 6y ago

This all indicates that browsers and html/css are bad tools for creating UI. Long term I think we'll eventually see the ability to interact with the local system via the browser, and we'll start seeing more things like "QT for the web". Because if we don't, at some point it's all going to just fall over.

sparks1970 6y ago
Qooxdoo? https://qooxdoo.org/ https://qooxdoo.org/ ?
heavyset_go 6y ago
Qt for the web already exists within Qt.
- RandoHolmes 6y ago
  That is not what I'm referring to, you're concentrating too hard on the specific example rather than the idea behind it.
deergomoo 6y ago
Yes. HTML is a terrible platform for applications. It provides basically nothing and I am continually surprised that it doesn’t seem to be a major focus for improvement like JS and CSS. I don’t need more types of semantic rectangle, I need actual real UI controls that are efficiently rendered and accessible by default, so I don’t have to build everything from scratch. The fact that there’s no built-in element for things like dropdown menus is mind boggling to me. That’s GUI component #0; menus have existed for as long as GUIs have! I feel that Houdini may eventually solve CSS’ shortcomings for application UI layout, but being stuck with HTML is like trying to build an aeroplane with sticks and mud.
- pattycakes 6y ago
  >The fact that there’s no built-in element for things like dropdown menus is mind boggling to me. You mean the select tag?

Shorel 6y ago

And who decides which is which? You?

svachalek 6y ago
These days nothing is purely static and very little is purely interactive/dynamic. However most sites lean clearly to one side or the other, no judgment call or personal defensiveness required.
- ClumsyPilot 6y ago
  Most sites straddle the muddy line in-between, or start off as webpages and mutate into web-apps over time as more functionality gets added on.

tomc1985 6y ago

> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend. Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a lot of functionality you can implement that doesn't need JS at all

PretzelFisch 6y ago
At this point, I think we'll start to see an electron shell that you can install apps/extensions into. The main thing that will prevent this from gaining traction is ios.
mawise 6y ago
+1 to this. I wanted to build a private blogging app/site with a big focus on speed and performance, it might not be popular anymore but I went with Rails. Server-side rendering lets the browser do what it's good at. The only thing that would make pages load faster would be to stick them behind a CDN (which doesn't play nice with the privacy aspect). If anyone is interested I put up a page talking about the project: https://simpleblogs.org https://simpleblogs.org
- nawgz 6y ago
  See but the parent comment is about "web applications" not "web pages". You are describing a web page - there is limited or no interactivity, what is there can be reasonably handled by forms. No one doubts that React isn't the tool for this area
  - learc83 6y ago
    Take a look at the hey email client. It's built by basecamp--the guys who created rails. As for web app vs web page--it's a very blurry line, and it's rare that I end up building something where the entire site could be considered a web app. Usually only some small pieces of it demand enough interactivity to bother with the complexities of using a UI framework, and for that I wrap a small React or a Svelte app in a div and throw it on a page within the larger site.

bromuro 6y ago

You don’t need even build always a SPA with React. For interactive widgets, Resct works better to me than jQuery.

bmarkovic 6y ago

It is also a frustrating experience to endure reloads on every click if what the user is using feels like a web application and you're essentially placing that burden of reducing the interaction roundtrip time on your infrastructure which gets expensive really really fast. Most web-thingies are neither 100% plain websites nor 100% plain webapps, most are in the middle, some are heavily leaning on one side or the other.