5 ms·

Great resource, I've bookmarked it. You know where vanilla JS still has a legitimate usecase in the era of SPAs? Landing pages. - Mostly static HTML, time to

Great resource, I've bookmarked it. You know where vanilla JS still has a legitimate usecase in the era of SPAs? Landing pages. - Mostly static HTML, time to first render is critical, all you want is a little bit of (progressively added) flair - Can be inlined for instant loading/execution, no bundle download (or SSR) necessary - Code has low volume and scope so structure / spaghetti isn't a concern - You can separate it out from the rest of your SPA bundle(s), so shipping changes is completely decoupled from your SPA CI/CD process and can be done as frequently as you like and very quickly

Lammy 7y ago
- You can include a deferred reference to a resource you want to be cached for other pages, like web fonts
zemnmez 7y ago
you can get all these benefits by pre-rendering and hydrating using a system like react-snap. this means static rendered html is served and the react control is then re-added, or ‘hydrated’ into the DOM content
- gboss 7y ago
  Depending on how "hydration" is done it can still waste cpu cycles and hurt time to interactive on mobile devices.
- bryanrasmussen 7y ago
  are you sure you can get all these benefits? - You can separate it out from the rest of your SPA bundle(s), so shipping changes is completely decoupled from your SPA CI/CD process and can be done as frequently as you like and very quickly I mean sure I guess I could do a lot of extra work to separate it out, it's true. But the real benefit of a vanillajs landing page is stuff is simple, and getting all the benefits by pre-rendering and hydrating using a system like react-snap sounds difficult. If we follow the old saying Simple things (to say) should be simple (to do) it implies to me that Difficult things to say will be (relatively) difficult to do.
  - zemnmez 7y ago
    sure, you can't separate it out if it didn't need to be separated in the first place
satvikpendem 7y ago
Yes, landing pages are places where you can use static HTML, CSS, and JS. However, React (and similar frameworks) might still be better, especially with a landing page with multiple parts. This is because React combines two different paradigms, one of creation and one of distribution. In creation, React breaks up large parts into smaller components. In distribution, it renders them at runtime, not build time (with a standard create-react-app app). However, there is no reason to have both at once. Components make the page easy to reason about, and they can be used to compile a site at build time, as Svelte does. React also has its own libraries for this, like Gatsby and Next JS. You do say that the landing pages have low volume but they can certainly grow to encompass a larger amount of things, such as multiple feature pages or a blog, so I'd rather not rewrite everything later on. You could also use Web Components but they don't have as much support and are generally not as good as React (one can disagree of course), so I like to use React + Gatsby to build the pages at compile time and use them without any Javascript whatsoever [0] but still have the developer experience of creating a page via components. [0] https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascript/ https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascrip...
- Scarbutt 7y ago
  Components are not unique to react. Most template libraries have them.
  - satvikpendem 7y ago
    Not to the same extent though. Usually they're provided as mixins which can be useful but aren't as powerful because there is programmaticity to them, they simply output HTML without consideration for the life cycle of a site, if any. Again, useful if your site is simple, but anything more and it gets complicated, even for a landing page as these days landing pages have a lot more dynamic parts.
    - deleted 7y ago
      [deleted]
    - ithrow 7y ago
pjmlp 7y ago
> You know where vanilla JS still has a legitimate usecase in the era of SPAs? Landing pages. Well, for me my framework is vanilaJS, anything else only when there is customer demand. Then they get surprised how fast everything runs.
- hailk 7y ago
  Interesting. Can you elaborate on this. What do you use this vanillaJS framework for? How do you do DOM manipulation? How much traffic do you get from what you've built using this? I've heard doing document.getElement... and then modifying the DOM is costly.
  - pjmlp 7y ago
    It helps when one uses Java and .NET server side rendering frameworks, which offered component libraries before nodejs was even an idea, which also allow to package JavaScript and CSS. Then only use JavaScript where it makes sense. For example, using Angular, React, Vue to display text or encapsulate three.js is probably not the best use case of customers CPU and bandwidth.
  - Widdershin 7y ago
    The main performance gotcha to watch out for with hand rolled DOM manipulation is causing a reflow. Pretty much if you make changes to a DOM element and then read a computed value from it before a new frame renders (like dimensions etc), the browser has to recalculate the page layout before it can return an answer. Fast: Read -> Modify -> Paint Slow: Modify -> Read (reflow!) -> Paint This generally isn’t an issue but if you’re seeing hiccups it’s either GC run wild, synchronous code chewing up the frame budget or frequent reflows.
  - coffeefirst 7y ago
    > I've heard doing document.getElement... and then modifying the DOM is costly. So, manipulating the DOM uses more memory than, say, manipulating strings. But assuming you're going to change something on the DOM anyway, the framework has the exact same API's to manipulate the DOM that you do. And they have their own overhead to figure out what operations they want to run. Almost by definition, vanilla will always be faster. That doesn't mean it's always better. If you need the DOM to reflect changing states in complex ways (think Trello or Notion) I'll be the first to admit it's simpler to let someone else's algorithm morph the DOM. And that's okay.

Lammy 7y ago

- You can include a deferred reference to a resource you want to be cached for other pages, like web fonts

zemnmez 7y ago

you can get all these benefits by pre-rendering and hydrating using a system like react-snap. this means static rendered html is served and the react control is then re-added, or ‘hydrated’ into the DOM content

gboss 7y ago
Depending on how "hydration" is done it can still waste cpu cycles and hurt time to interactive on mobile devices.
bryanrasmussen 7y ago
are you sure you can get all these benefits? - You can separate it out from the rest of your SPA bundle(s), so shipping changes is completely decoupled from your SPA CI/CD process and can be done as frequently as you like and very quickly I mean sure I guess I could do a lot of extra work to separate it out, it's true. But the real benefit of a vanillajs landing page is stuff is simple, and getting all the benefits by pre-rendering and hydrating using a system like react-snap sounds difficult. If we follow the old saying Simple things (to say) should be simple (to do) it implies to me that Difficult things to say will be (relatively) difficult to do.
- zemnmez 7y ago
  sure, you can't separate it out if it didn't need to be separated in the first place

satvikpendem 7y ago

Yes, landing pages are places where you can use static HTML, CSS, and JS. However, React (and similar frameworks) might still be better, especially with a landing page with multiple parts. This is because React combines two different paradigms, one of creation and one of distribution. In creation, React breaks up large parts into smaller components. In distribution, it renders them at runtime, not build time (with a standard create-react-app app). However, there is no reason to have both at once. Components make the page easy to reason about, and they can be used to compile a site at build time, as Svelte does. React also has its own libraries for this, like Gatsby and Next JS. You do say that the landing pages have low volume but they can certainly grow to encompass a larger amount of things, such as multiple feature pages or a blog, so I'd rather not rewrite everything later on. You could also use Web Components but they don't have as much support and are generally not as good as React (one can disagree of course), so I like to use React + Gatsby to build the pages at compile time and use them without any Javascript whatsoever [0] but still have the developer experience of creating a page via components. [0] https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascript/ https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascrip...

Scarbutt 7y ago
Components are not unique to react. Most template libraries have them.
- satvikpendem 7y ago
  Not to the same extent though. Usually they're provided as mixins which can be useful but aren't as powerful because there is programmaticity to them, they simply output HTML without consideration for the life cycle of a site, if any. Again, useful if your site is simple, but anything more and it gets complicated, even for a landing page as these days landing pages have a lot more dynamic parts.
  - deleted 7y ago
    [deleted]
  - ithrow 7y ago

pjmlp 7y ago

> You know where vanilla JS still has a legitimate usecase in the era of SPAs? Landing pages. Well, for me my framework is vanilaJS, anything else only when there is customer demand. Then they get surprised how fast everything runs.

hailk 7y ago
Interesting. Can you elaborate on this. What do you use this vanillaJS framework for? How do you do DOM manipulation? How much traffic do you get from what you've built using this? I've heard doing document.getElement... and then modifying the DOM is costly.
- pjmlp 7y ago
  It helps when one uses Java and .NET server side rendering frameworks, which offered component libraries before nodejs was even an idea, which also allow to package JavaScript and CSS. Then only use JavaScript where it makes sense. For example, using Angular, React, Vue to display text or encapsulate three.js is probably not the best use case of customers CPU and bandwidth.
- Widdershin 7y ago
  The main performance gotcha to watch out for with hand rolled DOM manipulation is causing a reflow. Pretty much if you make changes to a DOM element and then read a computed value from it before a new frame renders (like dimensions etc), the browser has to recalculate the page layout before it can return an answer. Fast: Read -> Modify -> Paint Slow: Modify -> Read (reflow!) -> Paint This generally isn’t an issue but if you’re seeing hiccups it’s either GC run wild, synchronous code chewing up the frame budget or frequent reflows.
- coffeefirst 7y ago
  > I've heard doing document.getElement... and then modifying the DOM is costly. So, manipulating the DOM uses more memory than, say, manipulating strings. But assuming you're going to change something on the DOM anyway, the framework has the exact same API's to manipulate the DOM that you do. And they have their own overhead to figure out what operations they want to run. Almost by definition, vanilla will always be faster. That doesn't mean it's always better. If you need the DOM to reflect changing states in complex ways (think Trello or Notion) I'll be the first to admit it's simpler to let someone else's algorithm morph the DOM. And that's okay.