3 ms·

Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify,

Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out (I know, I've done this before). As it stands your interactions ("New Data", "Run", "Step", "Reset") are completely separate from the rendered data. Once you start combining those it gets harder. It's still possible but you are reinventing the wheel. For a small demo like this vanilla JS might make sense but scaling this up does not work (once your rendered HTML reaches a certain size it's jarring when it re-renders, same deal if you have interactive UI that you are rendering out) and if you need to make 10x of these demo sites you are copy/pasting a bunch of code versus leveraging a framework that handles that stuff for you. Yes, frameworks raise your "floor" of code-size but they provide an excellent foundation to build on and skills you can reuse across projects instead of them all being one-off or having to copy/paste a bunch of code.

tgflynn 4y ago
> Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. Yes and no. What are those apps really doing that's fundamentally so much more complicated ? Obviously there's a lot more to their UI's and you'd need to be careful about doing full re-renders. I suspect anything that affects global page layout could become problematic. But I think it should be possible to predetermine the page layout (unless the viewport size changes, then you'd need to re-render everything, but that should be uncommon) and only re-render within div's of preset size. > I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out You mean like generating forms/controls ? I have some other code I'm working on that does that and also doesn't seem particularly hard. For example I'm working on a chrome extension with an options page that updates another page and the local storage as soon as a user changes an option setting.
- joshstrange 4y ago
  > Yes and no. What are those apps really doing that's fundamentally so much more complicated ? They have more views, more data, more data that needs to be kept in sync across multiple views. You cannot rerender (and inject/replace) every time the underlying data changes. It works up to a point but once you cross that rubicon it because very painful. I don't know how better to say this or explain it. I write webapps professionally and for side-projects, maintaining any of them in vanilla js would be a non-starter. I have even tried that for "smaller" webapps that "don't need a build step", it doesn't work. SCSS is vastly superior to CSS, TS is superior to JS, and templates that support things like `v-for="item of items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates with event handlers, loops spitting out html, and conditional rendering of blocks. > You mean like generating forms/controls ? Yes. Those things make this all more complicated. I've built exactly what you have in the past and at a certain point it falls down hard. There is a noticeable lag when you change data and go to re-render. If the user is focused on an input and you re-render they lose focus unless you make sure to reset the focus after the render. If you wanted to do something like "As the user types re-render an element to show what they typed" (think example/preview, or even something like putting the name you are typing into the UI as a header) it gets really gross really fast. So you might start having smaller render areas "I'll just re-render this 1 part" but that also gets complicated very quickly and at the end of the day you are just building a worse framework without the benefit of the community.
  - tgflynn 4y ago
    > You cannot rerender (and inject/replace) every time the underlying data changes. OK, so how do the frameworks do it then ?
    - Kiro 4y ago
      This is a good start: https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/reconciliation.html https://reactjs.org/docs/reconciliation.html
posterboy 4y ago
This is hilarious. Those web apps are single page applications, more application than page. The most of what face book does in the background has nothing to do with what the user can see, for example. A chat might require interactivity, but static designs with push and pull work well enough for many use cases, with sparse scripting. The bespoke tutorials might rather target a geocities homepage, admittedly. It's funny to see how responses in this thread jump immediately to reactivity or "skills you can reuse across projects" but without making the case: why?
- solardev 4y ago
  Why what? Facebook is pretty complicated already, once you factor in: * infinite scroll * different sorting algorithms (top vs new, do they even still have that?) * real-time commenting and post updates, with responses, reactions, edits, deletions * dynamic image uploads, resizes, rotations, captions, etc. * auth * multi-device sync * real-time customizable notifications * real-time sharing And then it gets even more complicated when you throw in other features like: * ad management, posting, analytics, event tracking * chat * marketplace * page management and all the permissions and delegations that involves There's nothing really "static" about Facebook. And even it was designed as a mix of PHP and clientside JS, probably due to its history... if they started from scratch today, who knows what architecture they'd use, but probably not vanilla JS and HTML... I think the "why" should be aimed more at vanilla, as in "why would you want to reinvent the wheel when there are so many battle-tested solutions to choose from, each made by a team hundreds of times more resourced than you"
  - paulryanrogers 4y ago
    Why go vanilla? Because it's less complex, often smaller over the wire, nearly SEO ready, etc. Of course if you can anticipate needing a lot of interactivity which cannot wait for separate page loads then consider the FE frameworks. Maybe even go hybrid if only one or two pages need app-like components. Right tool for the job is hard to know before you've done a similar job, so I can relate to wanting to start with the most robust hammer.
  - abareplace 4y ago

tgflynn 4y ago

> Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. Yes and no. What are those apps really doing that's fundamentally so much more complicated ? Obviously there's a lot more to their UI's and you'd need to be careful about doing full re-renders. I suspect anything that affects global page layout could become problematic. But I think it should be possible to predetermine the page layout (unless the viewport size changes, then you'd need to re-render everything, but that should be uncommon) and only re-render within div's of preset size. > I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out You mean like generating forms/controls ? I have some other code I'm working on that does that and also doesn't seem particularly hard. For example I'm working on a chrome extension with an options page that updates another page and the local storage as soon as a user changes an option setting.

joshstrange 4y ago
> Yes and no. What are those apps really doing that's fundamentally so much more complicated ? They have more views, more data, more data that needs to be kept in sync across multiple views. You cannot rerender (and inject/replace) every time the underlying data changes. It works up to a point but once you cross that rubicon it because very painful. I don't know how better to say this or explain it. I write webapps professionally and for side-projects, maintaining any of them in vanilla js would be a non-starter. I have even tried that for "smaller" webapps that "don't need a build step", it doesn't work. SCSS is vastly superior to CSS, TS is superior to JS, and templates that support things like `v-for="item of items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates with event handlers, loops spitting out html, and conditional rendering of blocks. > You mean like generating forms/controls ? Yes. Those things make this all more complicated. I've built exactly what you have in the past and at a certain point it falls down hard. There is a noticeable lag when you change data and go to re-render. If the user is focused on an input and you re-render they lose focus unless you make sure to reset the focus after the render. If you wanted to do something like "As the user types re-render an element to show what they typed" (think example/preview, or even something like putting the name you are typing into the UI as a header) it gets really gross really fast. So you might start having smaller render areas "I'll just re-render this 1 part" but that also gets complicated very quickly and at the end of the day you are just building a worse framework without the benefit of the community.
- tgflynn 4y ago
  > You cannot rerender (and inject/replace) every time the underlying data changes. OK, so how do the frameworks do it then ?
  - Kiro 4y ago
    This is a good start: https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/reconciliation.html https://reactjs.org/docs/reconciliation.html

posterboy 4y ago

This is hilarious. Those web apps are single page applications, more application than page. The most of what face book does in the background has nothing to do with what the user can see, for example. A chat might require interactivity, but static designs with push and pull work well enough for many use cases, with sparse scripting. The bespoke tutorials might rather target a geocities homepage, admittedly. It's funny to see how responses in this thread jump immediately to reactivity or "skills you can reuse across projects" but without making the case: why?

solardev 4y ago
Why what? Facebook is pretty complicated already, once you factor in: * infinite scroll * different sorting algorithms (top vs new, do they even still have that?) * real-time commenting and post updates, with responses, reactions, edits, deletions * dynamic image uploads, resizes, rotations, captions, etc. * auth * multi-device sync * real-time customizable notifications * real-time sharing And then it gets even more complicated when you throw in other features like: * ad management, posting, analytics, event tracking * chat * marketplace * page management and all the permissions and delegations that involves There's nothing really "static" about Facebook. And even it was designed as a mix of PHP and clientside JS, probably due to its history... if they started from scratch today, who knows what architecture they'd use, but probably not vanilla JS and HTML... I think the "why" should be aimed more at vanilla, as in "why would you want to reinvent the wheel when there are so many battle-tested solutions to choose from, each made by a team hundreds of times more resourced than you"
- paulryanrogers 4y ago
  Why go vanilla? Because it's less complex, often smaller over the wire, nearly SEO ready, etc. Of course if you can anticipate needing a lot of interactivity which cannot wait for separate page loads then consider the FE frameworks. Maybe even go hybrid if only one or two pages need app-like components. Right tool for the job is hard to know before you've done a similar job, so I can relate to wanting to start with the most robust hammer.
- abareplace 4y ago