Comment by preg_match
15 hours ago
Kind of, but in practice not really. Sure, something like a photo editor would never be possible in Web 1.0.
But 99% of web applications are forms and displaying stuff. All JS accomplished is making it look prettier and enhanced tracking.
I mean, Facebook, my bank, Amazon… these can all be created with no client side code. It would be a lot of refreshes, but it can be done.
> I mean, Facebook, my bank, Amazon… these can all be created with no client side code. It would be a lot of refreshes, but it can be done.
HN could too - perhaps the biggest use on HN is not refreshing when up (or down) voting something. YouTube could do something similar - refreshing when 'liking' a video or getting more comments. But would you really find those to be a better experience for you? Even on actions that HN does refresh on, such as 'Next page', or submitting a comment, HN doesn't freeze sorts, so posts and/or comments you didn't see will often invisibly end up before the new location HN sent you to (or posts/comments you already saw earlier in the list now showing up "again" later in the list).
You can have the buttons in iframes and have that POST and refresh.
Not saying that's exactly what should be done, but an example that there may be another way than full-on generic code execution wrapping XHR.
Ah, so I guess the idea is that this page (with its ~200 comments) would have ~200 iframes added to it?
A declarative approach would go a long way. Like, I'm not evaluating restaurants on the basis of their website quality, so why not have a restaurant browser and they can all just expose data according to some common schema. Same this with banks. Same thing with most things.
If you want a wildly interactive art experience, just load the appropriate browser for that.
Because restaurants don't want businesses like DoorFash to scrape it.