Hacker News Reader

Hacker News

Comment by davnicwil | Hacker News Reader

Full thread

davnicwil

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

View on HN

> 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.

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.

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.

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.

> 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.

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-javascrip...

Components are not unique to react. Most template libraries have them.

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.

they simply output HTML without consideration for the life cycle of a site, if any.

If you don't mind, as someone who is not familiar with react can you elaborate on the difference? What do you mean by life cycle of a site? In the template I use, I can organize all parts of a site as functions and compose/reuse them freely.

I really feel like React and components in general, or almost any framework is probably overkill for most basic websites and even apps can make things harder to reason about than previous architecture styles. Especially so if there is a tendency to decouple at a very granular level.

I recently decided to, for the sake of practice, build some single page apps using Vanilla JS. It was such a pain. Maybe some of it is due to my relative lack of front-end JS experience, but I found it nearly impossible to avoid duplicate code. I’m interested to know how people architected apps like that before. I was under the impression that SPAs were not nearly as common before frameworks like React.

> nearly impossible to avoid duplicate code

Do you think duplicate code bad, no matter the case? I'd like to hear your thoughts.

Personally, I don't mind a bit of duplication and difficult coding if I can avoid a juggernaut like React, but I also don't mind simpler visual UIs. I actually prefer them over the complicated SPA that tries to look and feel like a native application, because it never works. There's this "uncanny valley" between native application UIs and SPA web apps which try.

I wasn't thinking necessarily about pure vanilla JS, though that's certainly an interesting experiment that would lead to a better understanding of what something like React actually does. I was thinking about choosing the right tool for the job or scale of the job. If what you're definitely doing is an SPA, then you should probably assess how the nature of the application relates to the tools you'll choose. For many smaller things though, I'd doubt the necessity for an SPA at all, and vanilla JS would likely suffice. Considering that React is largely just one piece of the puzzle, it can easily be replaced in most cases by vanilla JS I'd think.

Sure they were, you just organize the code in components in server side frameworks.

You get a way to organize your server side code, CSS, JavaScript and flavour of Web API of the month (SOAP, REST, gRPC, WebSocket, ...).

Naturally reusing components across frameworks isn't that easy, but the same problem also happens across React, Angular and what have you, unless you make use of WebComponents, but that only works if targeting the most recent browsers.

There where other toolkits before react, Dojo, MooTools, YUI each had their pros and cons. The problem was they where all fiefdoms similar to how Angular is. Where React really hit while the iron was how was that the whole JavaScript build and packaging system was moving to npm and react was one of the first sane component models available in that ecosystem. Unlike the previous attempts React did not try to be all things to all people, it was laser focused on being a component model and life-cycle. You got the rest via a plethora of options via npm install.

As a side not React also bucked what was the sage wisdom of the time which was, don't mix templates with code via the introduction of JSX. This came from the very real and sage pattern of separation of concerns but somewhere along the way we confused separations of technologies with separations of concerns. If a piece of CSS, a piece of HTML and a piece of JS are all dealing with the same black box concern and are not reusable outside of that black box, separation of technologies (i.e separate files for each) only serves to add complexity to the solution as it abstracts them away from each other, forces the need to resolve their interdependence and obfuscates the ability to quickly get an entire overview of the black box.

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

Depending on how "hydration" is done it can still waste cpu cycles and hurt time to interactive on mobile devices.

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.

sure, you can't separate it out if it didn't need to be separated in the first place

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

Reply on news.ycombinator.com