Comment by paulddraper

15 hours ago

Bad take.

HTML is abysmally lacking for any interactive (which is what this article is about).

Decades later, even something as common as a combobox is unsupported.

EDIT: Downvotes but no argument.

6 comments

paulddraper

Reply
Spivak  12 hours ago

It comes down the web browser being used for two different use cases and two camps arguing past one another.

Documents vs Programs

The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser.

Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.

  • locknitpicker  11 hours ago

    > The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity.

    Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.

    • Spivak  10 hours ago

      Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once.

      But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.

      1 reply →