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

351–360 of 467 posts

Re: Second-Guessing the Modern Web

#351

Post by nyanpasu64 »

dbbk wrote: post #346
boomlinde wrote: post #344

Earlier quoted context omitted.

> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general. I have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now p…

Do you also wear tinfoil hats?

I spent several months with JS off by default. I relented after one too many broken sites. Since then, I've suffered from sites with HTML popups, autoplaying videos, and not one, but two "subscribe to my newsletter" prompts which trigger when you move your mouse to the address bar.

Disabling JS by default severely reduces the ability of websites to pull user-hostile tricks (though it breaks web apps). No website (presenting static information to be consumed) should ever break with JS off, and any site that does is defective. I won't extend this to web apps (interactive dynamic functionality like Google Docs) though.

Re: Second-Guessing the Modern Web

#352

Post by boomlinde »

dbbk wrote: post #346
boomlinde wrote: post #344

Earlier quoted context omitted.

> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general. I have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now p…

Do you also wear tinfoil hats?

If you mean to equate wearing tinfoil hats with employing a blacklist-by-default Javascript policy I'd gladly hear your reasoning. I'm sure it would help others not confuse your point with vapid shitposting, as well.

Re: Second-Guessing the Modern Web

#353

Post by dbbk »

mellow2020 wrote: post #60
saagarjha wrote: post #27

Earlier quoted context omitted.

I mean, what did you think he was going to say? React is bad, we're dropping it?

"React is bad in your case, drop it." I know it's far out idea in tech, to flat out tell someone "you don't need this, you just save time and money and get a better result of you don't use what we made", but it shouldn't be. React is fine per se, the problem is throwing these "simple, magic" solutions onto everything , without even caring what mountains of code end up running as a result. The minimum for a Discourse…

I've always felt like the vast majority of apps do not need to be on React. It's too low-level. Surely it makes more sense to just use a framework like Next or Ember, where you can focus on developing your product functionality (what sets you apart) rather than bikeshedding on routers, build configs, developer tooling, etc.

Re: Second-Guessing the Modern Web

#354

Post by dbbk »

cageface wrote: post #75

Use the right tool for the job. Why is this so controversial? Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.

Honestly, I think it's controversial because a lot of frontend developers lack critical thinking. There isn't a nuanced technical assessment, they just go "Oh React is the industry standard let's use that", with no regard for whether or not it fits their use case.

I also see this a lot within the React community with things like Hooks, you have Dan Abramov giving one presentation and a lot of the immediate reaction is "this is a panacea, the future of web development, it's perfect".

Re: Second-Guessing the Modern Web

#355

Post by dbbk »

pier25 wrote: post #101
tomaszs wrote: post #89

Earlier quoted context omitted.

Swelte has exactly the same problems author mentions about React.

Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but: > The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK. Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework. Oth…

> There is no runtime and practically no framework.

Why is this a good thing? Surely most developers want a framework?

Re: Second-Guessing the Modern Web

#356

Post by nyanpasu64 »

I generally agree with this article, but:

> And then there’s the authentication story. If you do SSR on any pages that are custom to the user, then you need to forward any cookies or authentication-relevant information to your API backend and make sure that you never cache the server-rendered result.

Isn't this also a problem in conventional server-side-rendering (eg. PHP) websites? And Steam once had a caching bug and accidentally showed people others' profiles?

Re: Second-Guessing the Modern Web

#357

Post by mavhc »

TeMPOraL wrote: post #333
mavhc wrote: post #286

Earlier quoted context omitted.

those crazy users, not wanting to install, configure and update software, download their emails and make sure their backups work, and just get on with actually reading their emails on whatever computer they wanted

Those crazy users who then cry, "what do you mean I've lost 10 years of e-mails forever, becuase my daugher commented with an emoji on a YouTube livestream, and Google decided to go nuclear everything associated with that account?". Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.

That happens less often than people's computers dying.

Which emoji did she use?

Re: Second-Guessing the Modern Web

#358

Post by dbbk »

boomlinde wrote: post #352
dbbk wrote: post #346

Earlier quoted context omitted.

Do you also wear tinfoil hats?

If you mean to equate wearing tinfoil hats with employing a blacklist-by-default Javascript policy I'd gladly hear your reasoning. I'm sure it would help others not confuse your point with vapid shitposting, as well.

Yes, that's what I'm equating it with. I think it's a fair analogy. Disabling Javascript isn't enough to 'protect your privacy', and even if it was, I haven't heard of any tangible impact that would have on anyone's life.

Re: Second-Guessing the Modern Web

#359

Post by amw-zero »

slfnflctd wrote: post #347
amw-zero wrote: post #314

Earlier quoted context omitted.

“Let the page refresh” translates to a terrible UX. It devalues the application. It’s equivalent to buying a physical product, say a car, but the car jerks up and down whenever you hit the gas, and you hit your head on the roof every time. Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using sem…

I'm pretty sure blind people don't even notice this 'terrible UX' problem you describe, and that sighted folks aren't quite as jarred by it as you think. This 'taste' issue probably matters more in some organizations than others. Hopefully they don't involve blind people in their business, because SPAs are notorious for being unusable to them. You can design an SPA with accessibility in mind ( https://www.deque.com/b…

Yes, people who don't have the ability to see won't care about flickering on the screen and the better user experience that a single page app affords to users who can see. Not even sure why you're making that point other than to try and imply that people who write single page apps automatically don't care about blind people, which is self-righteous and rude.

We have a single page app and we regularly run it through screen readers to see what the experience is like. Since an SPA is not some magical entity and it does produce a real DOM tree, we can achieve a great degree of accessibility (not perfect) by simply focusing on the markup that's produced. That doesn't help with things like loading screens, but again, since we actually check applications on screen readers, the experience for pages that take a long time to render is not much better with pure HTML either.

I read the link you posted and it's a good resource. The #1 takeaway I got from it is:

> Make sure that client-side view changes are known to screen reader users by announcing the change in page title, using ARIA live regions and/or focus management.

That's a good idea and one we'll incorporate into our application.

Some other comments in the article are not helpful, such as:

> Consider whether a single-page app is really necessary, and if you even need to use a JavaScript framework at all.

This is a moot point. Using a JavaScript framework to create an application is not only acceptable, but extremely popular. So instead of trying to politically smash the idea of building an application using JavaScript, we should be focusing on how to improve accessibility in that landscape. We can and should figure things out.

Re: Second-Guessing the Modern Web

#360

Post by jakelazaroff »

goatinaboat wrote: post #261
jakelazaroff wrote: post #223

Earlier quoted context omitted.

Is that really true? On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year ! Since React was released, we’ve gone through through at least two new ways of deploying a server — containers and serverless, replete with their own huge abstraction layers like Kubernetes — and we’ve moved from monoliths to microservices and back again. And in native land, the “Rewrite It in R…

On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year! This is only true in shops where webdevs dabble in back end, same as node.js. In most places you will find recent versions of things that may be decades old - Python, Postgres, Apache, even Linux itself.

Anecdotally, that is not the case — I know many non–web developers who are excited about new, trendy technologies like like Go.
Post reply on HN