Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

Post reply on HN
Print view View original

381–390 of 467 posts

Re: Second-Guessing the Modern Web

#381

Post by nyanpasu64 »

flukus wrote: post #212
amw-zero wrote: post #45

We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application. Some applications r…

> Maybe Gmail is the best example of using the SPA experience to drive a rich UX. Gmail is is the perfect example of an app that loses more functionality than it gains by being an SPA. Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free. This is more important functionality to me than saving a page refresh. Same goes for JIRA, middle click at least wor…

New Twitter also broke the ability to middle-click embedded tweets to open in a new tab.

Re: Second-Guessing the Modern Web

#382

Post by ComputerGuru »

kitd wrote: post #298
pjmlp wrote: post #213

Earlier quoted context omitted.

I have been developing all sorts of native and Web applications for a couple of decades now, and SPAs is something I avoid as much as possible. And yes, I also implemented interactive desktop like applications as Web applications. Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customer…

Server-side rendering + Turbolinks [1] + jQuery-or-equivalent gives you an SPA experience anyway, without the client-side bloat. With judicious use of markup, it can be massively more responsive. [1] - https://github.com/turbolinks/turbolinks

See also unpoly and intercooler, which are more powerful and intended for more fine-grained usage.

https://unpoly.com/

https://intercoolerjs.org/

Re: Second-Guessing the Modern Web

#383

Post by frank2 »

compressedgas wrote: post #262
frank2 wrote: post #9

Earlier quoted context omitted.

Creating it is the easy part, IMO. The hard part is to get people to publish on it. I fear that most authors (and most creators of images and links) are not knowledgeable enough to see the web's shortcomings and that it will be very hard to explain the shortcoming to them -- with the result that most authors will continue to consider their job to be done once they have put their writings (and images and links) on the…

It already exists and it is called HTML. It is how JS is used to load page contents that can not be tolerated. Follow progressive enhancement. No JS should be required to load the contents of a page. If JS is included it should be to replace what would otherwise require a full page reload. If it is not possible to load the contents of a page without JS or the JS fails to complete, then the page should show its altern…

>Follow progressive enhancement. . . .

This is advice for a web site owner, and I don't see giving advice to web site owners to be an effective way to help internet users who are very annoyed with the web like I am. Web site owners are embedded in an ecosystem controlled by entities such as Google and Mozilla who either don't know or don't care about the dissatisfaction I and people like me have with the web. I have come to believe that the best way to help internet users who are sufficiently like me is not to try to improve or change the web, but rather to start a new internet service outside of the control of Google, Mozilla, etc. Great grandparent seems to have come to a similar conclusion.

Modern web browsers are designed to satisfy goals X, Y Z, U and W. You are pointing out that browsers can be used to do X. I (along with great grandparent IIUC) are replying, yes, it can, but a new service designed to do X alone will probably do it better with fewer bugs and glitches. And all the web site owners with goals Y, Z, U and W are really getting in our way when we pursue X; our moving to the new service would give us a way to separate ourselves a little from those site owners, saving us a lot of time and annoyance.

Re: Second-Guessing the Modern Web

#384

Post by robertoandred »

userbinator wrote: post #107
systemvoltage wrote: post #54

Earlier quoted context omitted.

Please write more about this because I feel the exact same. Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today…

Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable eleme…

Not sure why you think SPAs can't have unique URLs or real links.

Re: Second-Guessing the Modern Web

#385

Post by ComputerGuru »

luxphl wrote: post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

> client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

As a developer that started off with client applications going on two decades, this is the attitude I despise most about the modern web, the frameworks that power it, and the developers building on it.

Developers serve the user. The user must always be the primary beneficiary. Forgetting that is why we have this bloat, terribly frustration UIs, inconsistent UX, poor accessibility, and everything else that plagues software development today.

Re: Second-Guessing the Modern Web

#386

Post by vmchale »

luxphl wrote: post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

> It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

What a user-hostile attitude

Re: Second-Guessing the Modern Web

#387

Post by ComputerGuru »

searchableguy wrote: post #235
TeMPOraL wrote: post #232

Earlier quoted context omitted.

> the process has a tendency to self correct over time - creative destruction and all that I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.

Just look around your government systems. They have had decades to fix themselves but are they fixed yet? Are they faster, less bloatier, less user hostile and privacy invasive?

Let’s hope the public sector isn’t the model that the software industry is following.

Re: Second-Guessing the Modern Web

#388

Post by nojvek »

I get the SPA movement. I’m a big proponent of it. If a user is navigating between many similar pages or wants high interactivity without a page load then you want to cache the views as js scripts via cdn and only download the data via REST calls to an api. It works well with mobile apps too. Both web app and mobile app talk to the same api.

What I don’t get is the server hydration kungfu. If you’re rendering the template on the server then don’t do the same thing again with js and download the data twice. Just render html serverside and call it a day. Either app or a site.

A tiny bit of jquery like JS snippets for banners and image galleries make sense but that shouldn’t be render blocking nor be in megabytes.

I’m a big proponent of Preact over React. Same API but much smaller library. The difference is noticeable when browsing on 3G networks and low powered devices.

Re: Second-Guessing the Modern Web

#389

Post by boomlinde »

dbbk wrote: post #368
boomlinde wrote: post #366

Earlier quoted context omitted.

> Yes, that's what I'm equating it with. I think it's a fair analogy. That you think it's a fair analogy doesn't help me in the slightest to understand what your reasoning is. > Disabling Javascript isn't enough to 'protect your privacy', In the same sense as wearing a face shield while operating a chainsaw is not enough to save your life. It goes a long way. > I haven't heard of any tangible impact that would have o…

Okay, taking Facebook as an example. Let's say you visit a random website and get tracked by a Facebook Pixel (which happens to be an image, not JavaScript), what happens then? You see behaviourally-targeted advertisements on Facebook and partner destinations, instead of generically-targeted advertisements. I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a wh…

> I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a whole.

I haven't asserted that it has any negative impact. To say that it has no tangible impact (as you have) is decidedly wrong. Either the manipulation is working at a grand scale (which is scary in its own right), or people that invest that much money in targeted ads are idiots buying snake oil. Regardless, Facebook and Google now command huge social and political influence, and they're entirely in the business of using my private information to sell ads.

I guess wanting to be the constant target of increasingly direct attempts at manipulation is a matter of personal preference, but the fact that it has an obvious material impact on the world is not.

Re: Second-Guessing the Modern Web

#390

Post by acemarke »

tomduncalf wrote: post #343
withinboredom wrote: post #239

Earlier quoted context omitted.

It literally does, unless you have the form POST or GET to an API directly + a redirect from the API. You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because…

You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever. You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled ( https://reactjs.org/docs/uncontrolled-components.html ) and access their value via a ref. You could even give them IDs and access their value directly…

Note that we specifically recommend that people _not_ put most form state in Redux:

https://redux.js.org/faq/organizing-state#should-i-put-form-...

Also, per the form libraries question: Formik and React Final Form are the two standard packages I suggest folks look at. React Hook Form seems to be gaining some popularity. Also, I recently ran across https://github.com/wsmd/react-use-form-state and tried it in one of my own projects, and was pretty impressed with it as a lightweight option.

Post reply on HN