alt Hacker NewsPeople also forget just how far you can get without using client side JavaScript at all today. HTML and CSS have a lot of features built in that used to require JavaScript.
Replies
The best approach is to use both. Which is why I never understood the pure server side or the pure "reactive" approach. Having to manage rendering in server side code is pure pain, and having to return DOM markup from inside a function is likewise just madness. They both break the separation of concerns.
The first framework I ever got to use was GTK with Glade and QT with designer shortly there after. These, I think, show the correct way to arrange your applications anywhere, but also it works great on the web.
Use HTML and CSS to create the basis of your page. Use the <template> and <slot> mechanisms to make reusable components or created widgets directly in your HTML. Anything that gets rendered should exist here. There should be very few places where you dynamically create and then add elements to your page.
Use javascript to add event handlers, receive them, and just run native functions on the DOM to manage the page. The dataset on all elements is very powerful and WeakMaps exist for when that's not sufficient. You have everything you need right in the standard environment.
If your application is API driven then you're effectively just doing Model-View-Controller in a modern way. It's exceptionally pleasant when approached like this. I have no idea why people torture themselves with weird opinionated wrappers around this functionality, or in the face of an explosion of choices, decide to regress all the way back to server side rendering.
New inputs types have been glacially slow to come out and often underwhelming. Every new HTML thing I've seen (modals, datetime inputs, datalist select, etc) had better JS versions out for years before they released. I understand that the HTML spec is setting a baseline of sorts but most of the UI is ugly and sometimes not themeable/styleable.