Second-Guessing the Modern Web • Hacker News Board

Re: Second-Guessing the Modern Web

#301

Post by tannhaeuser » Mon, May 11, 2020, 10:15 AM UTC

giantrobot wrote: post #136

I think deep down people writing SPAs really just Flash apps or Applets would come back. They want to ignore everything about the web except the ability to deliver content over a network. I'd go so far as to say they hate the web as a concept. Most problems stem from that disdain for the web. Many of those problems are then exacerbated by "opinionated" frameworks being en vogue. None of them are helped by the shit pl…

No reason to be bitter about XML having failed on the web; some important vocabularies, like SVG and MathML, have been incorporated into HTML, and some other parts of the XHTML effort, like XForms, really didn't work out. The web wasn't created on XML but on HTML which is an SGML not XML vocabulary, so there's no point in appealing to a glorious past that never existed (and yes, I actually developed -based sites in the early/mid 2000's).

If you like XML, maybe you like SGML, XML's big sister, as well. Since XML is per definition just a subset of SGML, everything that applies to XML equally applies to SGML as well. Only that SGML has additional concepts and much more power as an actual text authoring, document composition, and templating format, and, unlike XML, SGML can parse regular HTML, including HTML5.

Re: Second-Guessing the Modern Web

#302

Post by kostarelo » Mon, May 11, 2020, 10:20 AM UTC

> I can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site.

Gatsby produces static HTML which I guess is the same with the authors' website.

How can we compare two static HTML websites and conclude on what's faster? Just by saying so is not the answer.

Re: Second-Guessing the Modern Web

#303

Post by icebr9 » Mon, May 11, 2020, 10:21 AM UTC

conorh wrote: post #81

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.…

I disagree. Do you remember the days when J2EE was the hot stuff? Popularity comes and goes and is not necessarily correlated with whether something is a good idea or not. Over the last 15-20 years or so as a web development shop we've gone through Prototype, Jquery, Backbone, Angular, Vue and now React for JS frameworks. We've mostly settled on React lately. Our experience is however that it is wildly overused where…

I really like Svelte because of what you are describing. It feels almost like writing normal JS/CSS/Html but you get access to some QoL features that make writing JS easier

Re: Second-Guessing the Modern Web

#304

Post by bryanrasmussen » Mon, May 11, 2020, 10:24 AM UTC

richthegeek wrote: post #284

bryanrasmussen wrote: post #210

Earlier quoted context omitted.

Currently the site I'm building is a pretty static site of about 30-50 pages that is just brochureware for a non-profit scientific organization, on one hand I feel sort of embarrassed because it feels like I'm back in 2004 and I have a hard time justifying my salary for something like this, on the other hand I'm really super embarrassed at making the wrong solution because a React SPA with a service worker has been o…

Gatsby (static-site generator powered by React) was a massive timesaver for me. Sure, you spend a bit longer setting up some basic components, but the trivial ability to share those components between pages more than makes up for it...

Yes of course I want Gatsby, but that is one of the things I'm not being allowed to do. I think I may have gotten overly sensitive these years to not getting my way on architecture.

Re: Second-Guessing the Modern Web

#305

Post by [deleted] » Mon, May 11, 2020, 10:37 AM UTC

eitland wrote: post #283

pvg wrote: post #270

Earlier quoted context omitted.

I'd like to know which users desired a web-based e-mail client 20 years ago. Millions of them, by then. https://en.wikipedia.org/wiki/Outlook.com#History See also Rocketmail. 20 years ago, the market for web-based email was well-established, not some push experiment.

Many of us only used it because it was free/available for everyone and we were students or stuck in another situation were it was the only option. If there was both a webmail interface and imap we chose imap. Some of us still to this day prefer imap/jmap/exchange if the server support it in a meaningful way.

[deleted]

Re: Second-Guessing the Modern Web

#306

Post by rikroots » Mon, May 11, 2020, 10:37 AM UTC

worble wrote: post #253

unclebucknasty wrote: post #231

Earlier quoted context omitted.

I'll take it a step further and say we shouldn't be using the Web paradigm at all. We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc. But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense. So, w…

I'm personally curious how far we could go with using just canvas and wasm. If we focused on making a browser that was just incredibly efficient and focused at using wasm and webgl, and had no other concerns, a lot of the cruft could be cut. Then any given "page" would essentially just expose the canvas for wasm to draw to, and GUI frameworks like Qt (which already can compile to wasm I believe) could just target thi…

> I'm personally curious how far we could go with using just canvas and wasm

In a word: accessibility. HTML is inherently accessible - you can curl a webpage and read the contents of any (static) web page. If you curl an entirely based web page, you'll walk away knowing only that the web page has a element in it.

You mentioned Qt. I've never programmed a Qt app, but I went hunting for its accessibility features in the docs[1]. I'm encouraged that Qt takes accessibility and Assistive Technologies seriously. However, if you're coding a web page in canvas/wasm/Qt you're going to need to make sure all the content, links and additional accessibility/AT requirements get ported from the into the surrounding DOM to make it accessible.

That's a huge amount of work!

[1] - https://doc.qt.io/qt-5/accessible.html

Re: Second-Guessing the Modern Web

#307

Post by pistoriusp » Mon, May 11, 2020, 10:42 AM UTC

burlesona wrote: post #72

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.…

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…

> If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most.

It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters."

They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.

Re: Second-Guessing the Modern Web

#308

Post by babaganoosh89 » Mon, May 11, 2020, 10:44 AM UTC

ssijak wrote: post #233

babaganoosh89 wrote: post #39

Earlier quoted context omitted.

I think a lot of the problem is React's syntax and ecosystem is too complicated for the majority of sites out there. IMO using React to make static sites and regular CMS / document type sites is way overkill no matter how performance optimized it is. I've been experimenting with Vue and I'm liking it more and more just for the simplicity.

Ract syntax is functions + jsx. Jsx has just a smal set of additional rules compared to ordinary html, so I would not call it complex. In Vue 2 you have directives and wierd object model where you store data, getteres, watchers, etc. Each library has its own set of things which needs to be learned, and for me both basic vue and react are easy.

Jsx is not complex but it adds additional cognitive load keeping in mind everything is still JS and the small differences between Html. Also the common libraries that people use in a React app tend to be overkill. Things like Flux/redux add way too much boilerplate for small-medium projects yet everyone uses it.

Re: Second-Guessing the Modern Web

#309

Post by cecja » Mon, May 11, 2020, 10:49 AM UTC

fastball wrote: post #295

mellow2020 wrote: post #84

Earlier quoted context omitted.

Fine, but that kinda falls under "without even caring what mountains of code end up running as a result". You use 10 GB instead of a few MB, and get an easy installation vs. an easy installation. It's like driving a huge truck everywhere, even to get the mail from our mailbox, because it starts up real fast and we don't have it far to the garage from our living rooms, and then later on because we haven't walked in so…

Discourse and software like it was not as easy to install. This was literally one-click. Installing wordpress and such in the past required installing PHP, MySQL, yada yada on your server to get everything running.

Every distribution in the early 90s/2000s came with a ready to go lamp stack. If you have to setup the whole environment for docker yourself it is basically the same work as setting up a lamp stack.

Re: Second-Guessing the Modern Web

#310

Post by fergie » Mon, May 11, 2020, 10:52 AM UTC

burlesona wrote: post #72

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.…

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…

> I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting.

Yes. And its important to remember that React is heavily marketed to developers by Facebook, just as MS does with Typescript, and Google does with Angular. The point of this marketing is to create a feeling that these technologies are "safe" and "standard". Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.

That said, there are a few major functionality gaps in native JS that leave the door open for front end libs. The biggest one is some kind of sane support for templating, and the second big one is that async is too complicated (people who actually understand callbacks and Promises often dont realize how many devs dont understand them). Facebook, via React, provides solutions to these problems, and leverages them to get users to buy into the React ecosystem.

If somebody could show how to make a component in JS that could be included in a page as an HTML tag, and could talk to other components on the page then the need for React would just evaporate.