Second-Guessing the Modern Web • Hacker News Board

Re: Second-Guessing the Modern Web

#311

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

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 people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time.

Not exactly making a value judgement about this, but imagine for a moment any other engineering discipline saying this:

Yeah, I kinda made this road 20x less efficient that I could have, but I didn't want to bother with the nitty gritty details.

Yeah I'm using trash materials to make this building, but I just didn't want the headache of thinking too much about it.

Re: Second-Guessing the Modern Web

#312

Post by amw-zero » Mon, May 11, 2020, 10:53 AM UTC

dexen wrote: post #91

amw-zero wrote: post #52

Earlier quoted context omitted.

I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an app…

>it's simply not possible to avoid re-rendering the entire page without using XHR Wrong on two separate levels. First up, technologies like iframes , frames , and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever. Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+…

You can’t compare the UI of a web page built in this way to an SPA or a native client. Re-rendering an entire page on every interaction is strategically never going to get you the same experience. I understand wanting to be a browser purist, but web applications have had pretty laughable UX compared to native apps of even 20 years ago.

I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”

Re: Second-Guessing the Modern Web

#313

Post by gimboland » Mon, May 11, 2020, 10:56 AM UTC

commandlinefan wrote: post #119

conorh wrote: post #81

Earlier quoted context omitted.

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…

> J2EE was the hot stuff Whenever everybody except me seems to love something and I just don’t get it, I remember CORBA...

Ah, the heady days back when everybody bought books written by Don Box which only Don Box could understand!

(Edit: yeah, of course, that was DCOM not CORBA, but anyway, that's where I flashed back to. :-) )

Re: Second-Guessing the Modern Web

#314

Post by amw-zero » Mon, May 11, 2020, 10:57 AM UTC

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…

“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 semantic HTML at all.

Re: Second-Guessing the Modern Web

#315

Post by joeberon » Mon, May 11, 2020, 10:58 AM UTC

runawaybottle wrote: post #139

I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it. If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people. Modern product development is essentially a polishing job on every com…

Isn't this the same in almost any industry? For example, in engineering this kind of "reinventing the wheel ad infinitum" you are describing is incredibly common. How many times to you think engineers have separately designed and tested clips to hold capacitors in place in the ECU of a motor? Many thousands of times, while being paid competitive salaries. Maybe you should argue there should be some "book of capacitor clip designs" but actually this doesn't work in practise because every capacitor clip design needs to fulfil very slightly different requirements. Often it is just easier and faster to redesign from scratch.

Taking existing components and redesigning them in some small way to fit your specific requirements is common in almost every industry I can think of.

Re: Second-Guessing the Modern Web

#316

Post by amw-zero » Mon, May 11, 2020, 11:01 AM UTC

asalahli wrote: post #70

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. My experience is quite the opposite. I still use Gmail's "Basic HTML" UI, and it takes less time for me to click a link and load a new page on that UI than any interaction on the default UI.

That’s ok. You should have the option to use that UX.

I can tell you that any non-programmer on the planet would ever choose that UX over the “app-like” feel. I think we forget that most users are not programmers way too often.

Re: Second-Guessing the Modern Web

#317

Post by granshaw » Mon, May 11, 2020, 11:03 AM UTC

_bxg1 wrote: post #172

I've barely used Next.js, so take this with a grain of salt, but to me the whole "hybrid" approach where you statically-render-and-hydrate has always felt like one big heaping pile of hack. The amount of grotesque complexity that's required to achieve this "best of both worlds" solution, and the number of asterisks that have to be added to that title, have never sat right with me. I'm a believer that you simply need…

The good thing about starting with just server rendering is that you can sprinkle in react if you just have one section with heavy interactivity and build from there, whereas it’s harder to go the other way around

Re: Second-Guessing the Modern Web

#318

Post by amw-zero » Mon, May 11, 2020, 11:03 AM UTC

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…

Well UX is of course subjective. I don’t agree with you at all. I use Gmail every day and I would call its user interface very successful.

Re: Second-Guessing the Modern Web

#319

Post by emerongi » Mon, May 11, 2020, 11:05 AM UTC

fergie wrote: post #310

burlesona wrote: post #72

Earlier quoted context omitted.

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

> Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.

Of course. Most devshops don't have the manpower that FB/Google/MS have. You don't really have months to tinker around and create some new framework and then another 2x months to fix bugs and add new features to cover some edge cases. So you pick whatever is backed by a lot of manpower as it has the highest chance of being usable even 3 years from now.

Re: Second-Guessing the Modern Web

#320

Post by danjac » Mon, May 11, 2020, 11:09 AM UTC

1337shadow wrote: post #297

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 me the real subject would be "the death of templates in favor of decorator based objects", which could have been predicted by the GoF that recommended the decorator pattern for GUIs, and makes great sense for the tag-based language that HTML is. Template languages often impose language limitations to make easier for HTML/CSS coders to work with, without breaking the backend code, isolating their codebase from the…

Seems we are going full circle: the Python ecosystem had component-based template languages such as ZPT (Zope Page Templates) and Genshi. The former I think is still used with the Pyramid framework, but mostly these approaches have been replaced by Django/Jinja2 text-based templates. So in Jinja2 or Django you would have something like:

    {{ page_title }}

But in ZPT:

    Sample Page Title

If you squint hard enough this doesn't look a million miles different from React or Vue.

This approach largely fell out of favor, but I don't know whether that was just due to Django's popularity vs other Python frameworks or Django template language just being more flexible and approachable, especially for front-end developers (and you could use it for any kind of text based content, such as emails).