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

261–270 of 467 posts

Re: Second-Guessing the Modern Web

#261

Post by goatinaboat »

jakelazaroff wrote: post #223
dahfizz wrote: post #94

Earlier quoted context omitted.

I've often said that web development has a big culture problem. In any other field, 'modern' is the opposite of a selling point. People want tools that work, that are proven and have years of stability and momentum. But in web development, there is an obsession with the new and shiny. It's 100% about the developer's own experience in creating a program and 0% about the user's experience actually using the half baked…

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.

Re: Second-Guessing the Modern Web

#262

Post by compressedgas »

frank2 wrote: post #9
echelon wrote: post #6

HTML should never have grown into the mutated application runtime it is today. The presentational concerns for documents are different from application rendering. The javascript stack should have been something entirely separate. I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom…

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 alternative contents. The page shall under no case be left blank. This is graceful degradation.

Re: Second-Guessing the Modern Web

#263

Post by djrobstep »

MattGaiser wrote: post #156
userbinator wrote: post #113

Earlier quoted context omitted.

It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. As a user and developer myself, that's the sort of selfish attitude that really really angers your users. 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 answ…

> As a user and developer myself, that's the sort of selfish attitude that really really angers your users. A user is only unhappy if they withhold some money over it.

What an absolutely sociopathic attitude

Re: Second-Guessing the Modern Web

#264

Post by [deleted] »

TeMPOraL wrote: post #248
pvg wrote: post #174

Earlier quoted context omitted.

zero need of JS XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.

I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's…

[deleted]

Re: Second-Guessing the Modern Web

#265

Post by tsimionescu »

systemvoltage wrote: post #54
caribousoup wrote: post #34

Earlier quoted context omitted.

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least…

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…

> Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.

> Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.

I'm not sure if this was supposed to be a case of 'how it once was' or 'how it should be', but this was never a reality, at least after the 90s. Native apps have always tried to style themselves just so (my company has a C# B2B GUI that has a little bit of assembly somewhere calling a Windows interrupt directly because they couldn't figure out another way to change the color of some window element). Even the earliest web pages were often trying to look as different as possible.

Re: Second-Guessing the Modern Web

#266

Post by int_19h »

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…

We also had XSL-FO, allowing for very precise control over the rendering of that server-served XML.

Oh, and this all was more than 20 years ago, not 15. IE5 had XSLT support, and it shipped in 1999!

Re: Second-Guessing the Modern Web

#267

Post by worble »

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…

> 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

The fact that things like middle click and right click can be overridden in javascript is pretty much one of the biggest failings of modern browsers in my opinion. It's developers giving the middle finger to standards, and browsers accomodating those whims without considering the end user whatsoever. If your grand design doesn't include basic functionality that browsers provide then great, feel free to create a native application that fits that design. Otherwise, please leave the functionality that I rely on every day, and works in 99% of other sites, alone.

Re: Second-Guessing the Modern Web

#268

Post by alessioalex »

pier25 wrote: post #67
snazz wrote: post #31

Earlier quoted context omitted.

I quite like Turbolinks too, but it can have some unintended interactions with other JS code. If you're looking to make your non-SPA site faster another way, you can try https://instant.page/ as well. It preloads pages as you hover over them, which makes links feel like they load instantaneously. It's a pretty cool trick! You can try it out on their project website or on https://www.snazz.xyz .

Cool trick! Sapper (the Svelte framework) does the same if I'm not mistaken.

Indeed: https://hn.svelte.dev/

Re: Second-Guessing the Modern Web

#269

Post by int_19h »

jimbob45 wrote: post #247
int_19h wrote: post #243

Earlier quoted context omitted.

It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD. Every attempt so far produced many techn…

RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools. I could fully foresee VB making a comeback in the future.

RAD never really died, we just stopped calling it that.

But open Visual Studio today, and create a new Windows XAML app, then open the form designer. You can still drag a button from the toolbox, move it around, then double-click it to wire up an event handler - exactly like it was in VB6. In fact, it's quite possible to ignore all the modern stuff like data bindings entirely, and just manually read and update all widgets, as a typical VB/Delphi app did.

Re: Second-Guessing the Modern Web

#270

Post by pvg »

TeMPOraL wrote: post #248
pvg wrote: post #174

Earlier quoted context omitted.

zero need of JS XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.

I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's…

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.

Post reply on HN