Hacker News Reader

Comment by peterkelly | Hacker News Reader

WordPress relies on server-generated HTML and its admin interface is a fairly complex "app", especially once you factor in the plugin ecosystem. According to [1], it's used on 43.7% of all public websites.

[1] https://w3techs.com/technologies/details/cm-wordpress

View on HN

It’s been a while since I worked with WordPress, but isn’t their Gutenberg editor (which is the heart of their CMS) built on React? So while React may not be used on the user facing side, it is still powering the content side of WordPress and in a way, powering all of those sites.

If every user input causes a page refresh, that's not an "app" that's a "website". If you don't have any executable code (i.e. Javascript), but just form submits, yeah I agree that's what most of the web is, and as you pointed out most of the web is websites not web apps.

Have you explored cross-document view transitions? Would you classify something that uses those as an app or a site?

https://developer.chrome.com/docs/web-platform/view-transiti...

That's actually rather new so we shall see how frontend practice reacts. I've only seen a few instances of it out in the wild so far.

I'm not saying my own definition of "app" is the only correct definition, but in my opinion only if I do a click and something on the SAME page changes, then it's an app. Transitioning to different pages isn't an app, imo.

With this browser feature a navigation to a new page can look like only part of the page changes - without needing any JavaScript.

> can look like

Yeah, but it ain't. lol.

It's easy for developers to forget who the "app" is actually for.

Users don't care how it was implemented or how nice the code looks, they just want it to work.

Right. That's precisely why full page reloads/updates every time some action is done (mouse click for example) would be completely unacceptable for most apps I've worked on. I've worked mostly on apps not websites.

The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue.

By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?

I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.

SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.

Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.

> But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed

In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.

It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.

I know what you mean. The train went off the tracks in about 1995 when JS was invented to begin with. We never had to "Mix Apps with Documents" to begin with, but that's how the industry evolved and to this day every modern stack/framework is still just tools to compensate for that "original sin" lol.

I think you're failing to understand that there are hundreds to thousands of functional applications out there that are not SPAs that are doing all of those things just fine. An SPA is not a requirement to be able to update values in a form, transition between page states, etc. The two options are not only Static Site or SPA -- that is the absurdity.

Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.

Reply on news.ycombinator.com