> If all that stuff works for everyone, why did we invent new stuff? Just because? Or perhaps it wasn't really as amazing as well all remember.
To better track people and push ads. It's really mostly just it. Modern web has very little to do with providing value to the end-user; any utility that's provided is mostly a side effect, and/or a vector to lure people into situations where they can be monetized.
Text browsers aren't holding the web down, they're anchoring it in the port of productivity, even as the winds of commerce desperately try to blow it onto the open seas of exploitation.
Creating sophisticated web pages is massively easier than 10 or 20 years ago. Yes, HTML of plain simple text-only pages is still pretty much the same, but most users actually prefer visually fancier content with pictures and colors.
Yes, companies presenting themselvses online profit of more capabilities. And yes, presenting ads is probably easier too. But if you think those changes were just made because of monetary greed, you could say the same about almost any technological advancement, like color photography, or electric cars, because all of these had a commercial side to them too.
By far.
Is there any evidence that web apps of today are faster in achieving what equivalent non appy web pages of the past managed? Despite the fact that those older "apps" were running on computers which were orders of magnitude slower than our cell phones today.
I've worked with 2 companies now where their users (and both these companies have users who pay 4 digit annual fees per user) have refused to migrate to the new Web 2.0 apps these companies have tried to foist on them.
The difference in these cases is that the users, by virtue of paying, actually have a say and so have required the companies to provide parity with the older and newer applications, and usage continues to not just be higher, but grow faster on the older versions (despite having a larger base).
Regular users have no such option. Google changes GMail, but its users still insist on using the older versions of the app, which is why they provide HTML mode, etc. However, it's users do not pay Google, and are forced to go with whatever Google wants to do, which is constantly hiding the older version and making it progressively worse to use.
It's not evident to me at all that regular users "want" to use these new web 2.0 apps, as much as they don't have a choice.
Its literally 20 times faster, and importantly, cuts across the human visual perception boundary, which is at ~200ms. So the old HTML version is human perceptible, while the new version renders in ~1 frame.
(Also, FWIW, loading delay of HTML pages on said beefy desktop, as tested right now, are consistently about 750-1500ms for me.)
More on-topic, these times apply only when the pages are hot in the browser cache. On my desktop, the first-time switch between "drafts", "sent" and "inbox" takes around 3 seconds each, and only then it is instantaneous. So regular users are likely to experience these long Ajax delays more often than not.
Even basic UIs like filtering can be bad if you want to change multiple filters, and you have to wait for a whole page load in between each change (page load times for pages with filters are often slow as they're performing complex queries).
It's a case of different things being appropriate for different use cases I think. There definitely are still times when plain HTML is best, but it's also not always faster.
I've built a React app that's under 300kb (cached with a service worker for subsequent page loads) that loads almost instantly and works offline. On the other hand, plenty of plain HTML sites include heavy CSS frameworks, or 5mb images, gifs, etc and load pretty slowly, especially on poor connections.
Bloat because of inefficient design isn't delivering any value to regular people that a developer is oblivious to. It's just bad engineering. Similarly for distractions, abandoning all UI features provided by default for the sake of making a control have rounded corners, setting the proficiency ceiling so low that no user can improve their skill in using a product over time, etc.
As an example, I tried standardizing on <input type="date" /> across our product (hundreds of fields). Within 24 hours we logged >1,000 tickets with users saying they disliked the change. They preferred the fancy datepicker because it let them see a full calendar and that enabled a more fluid conversation with the customer (like "next Wednesday").
Yes, Chrome does offer a calendar for this field type, but Safari for desktop does not (just off the top of my head).
I'm a vim-writing, tmux-ing, bash-loving developer. If it were up to me, I'd do everything in the terminal and never open a browser.
I recognize that the world doesn't revolve around me and my skills, interests and tastes. If a large cohort of my customers tell me they don't want to improve their computer skills and want a fancy UI, who am I to tell them they're wrong? They're paying me. They get what they want.
Two, I'll grant you that you sometimes have to use a custom control, because web moves forward faster than browsers, and so you can't count on a browser-level or OS-level calendar widget being available. But then the issue is, how do you do it. Can the user type in the date directly into your custom field? Is the calendar widget operable by keyboard? Such functionality doesn't interfere with first-time use, but is important to enable users to develop mastery.
A lot of my dissatisfaction with modern UI/UX trends comes from that last point: very low ceiling for mastery. Power users aren't born, they're made. And they aren't made in school, but through repeated use that makes them seek out ways to alleviate their frustrations. A lot of software is being used hours a day, day in, day out by people in offices. Users of such software will be naturally driven towards improving efficiency of their work (if only to have more time to burn watching cat photos). If an application doesn't provide for such improvements, it wastes the time of everyone who's forced to interact with it regularly.
Better forms inputs could very well be useful, I agree.
The recent MSFT + GOOG snogfest announcing major improvements to HTML by ... improving form and input fields in their (GUI-only) browsers strikes me, in light of rather ominous icebergs looming on the HTML horizon, of rather gratuitious deckchair-rearanging. No matter how fine those arrangements might be.
Hold up, your position is that users that prefer something 'easy to use' as opposed to something 'powerful' are immoral? What am I missing here?
If I choose to offer predatory loans which I would never accept for my friends or family to a community that is not financially savvy, and someone calls me out on it, it doesn't fly to say "hey, what do you have against these people taking advantage of my easy to use service?".
Sometimes it feels like the web of yore was so simple to use and free of unnecessary bloat simply because that was as far as the technology had progressed at that point. React didn't exist and the browser was limited from a technical perspective so the best people could manage was some clever CSS hacks to cobble together something mildly attractive. It might have taken a while to render even those simple pages on computers of the time, so back then those pages might have hit a performance ceiling of some kind.
Maybe as more and more features get added to a piece of technology, there's some kind of default instinct that some people have to always fully exercise all of it even if it's not at all necessary. Simply because you can do more with it that you couldn't do years ago, there's some assumption that it's just better for some vague reason. It's easier to overcomplicate when everyone else is doing it also, so as to not get left behind.
Then everyone who doesn't have knowledge about web technologies in the like get used to it, and people's expectations change so this "new Web" becomes the new standard for them and start enjoying it in some Stockholm syndrome manner - or not, and the product managers mistakenly come to this conclusion from useless KPIs like "time spent on our website" which will obviously increase dramatically if it takes orders of magnitude more CPU cycles just to render the first few words of an article's headline.
I'm only speculating though.
Personally, as someone with a headless server running Docker, it pains me to no end I can't browse Docker Hub with elinks.
I suspect this is very true. It seems true in my experience. I think the reason may be just that our field is so young and dynamic, that everyone learns everything on the job. If you want to stay up to date, you have to gain experience with the new tools, and the best way to do it is to find a way to make using them a part of your job. It saves you time after work, and you even get paid for it.
It takes good judgement to experiment with new technologies on the job without compromising the product one's working on. I feel that for most developers, the concerns of end-users rarely enter the picture when making these calls.
Or: when seeking driving advice, would you reject a priori the opinions of professional drivers, just because they're not representative of the general population? You would be justified in rejecting their views when considering your marketing strategy. Which kind of makes me think that a lot of reasons for pushing the "devs are not representative users" thought aren't about how to best serve users.
Your technical insight doesn’t make your user experience any more or less valuable or important.
User interfaces are an acquired taste. A shiny-looking app built on newest design trends may look appealing at first. But once you're couple hours into using it, your outlook changes. It suddenly starts to matter whether the application is able to handle reasonable-sized workloads without slowing to a crawl (many web applications can't). It matters whether you can use the keyboard instead of clicking on everything. It matters whether the application is fast and responsive, and doesn't. lag. on. you. every. click.
What long experience with software - both as a creator and as a consumer - gives me is the language and ability to look past the shiny facade, and spot the issues that will matter long-term.
> I never said that technical expertise makes my experience more (or less) important.
But then immediately dive into a long winded explanation of why your own personal opinions are superior. If you have some deeply academic reason for not likening something, but millions of user just absolutely love how shiny it is, then you can’t prove they’re wrong for doing so, nor that your opinion is in any way better or more valuable than theirs.
What I've seen though is that users almost never have any say in the matter. Software is generally forced upon users - mandated by their employers, being the only way to access a particular service or a social network, etc. Users have little say in how the software works.
People value privacy when made aware of the issue, but very few people are aware of how websites track (and manipulate) them.
All of the studies I'm aware of that ask people to choose between different price points based on privacy end up showing minimal valuing of privacy.
Most people, however, are not enthusiasts or activists who are wholly invested in these topics. Even being aware of the issue, most act based on their immediate needs. Immediacy is an extremely important factor in decision-making.
If we were to give this a utilitarian assessment formula:
[severity of problem] * [immediacy of problem] <||> [importance of need] * [immediacy of need]
Many people using social media to communicate with their family may evaluate that as:
[100] * [1] < [100] * [100]
Why is it that people working in the field tend to be paranoid about privacy, and people outside are not? It can't be that we are just on average more paranoid. It's more likely that we know exactly how this data can be aggregated, stored forever, analysed in the future with capabilities that don't exist yet, etc. I think most people don't understand privacy in those terms.
You have to factor in the fact that people know they are tracked whether they are paying or not. Given that fact I'd prefer not paying as well.
However, the way the poster you're replying to sees this issue is not as a candy salesman; but, as a public engineer. There's a problem, like "what should web be", "how should web work", which is akin to "how to build a railway over this valley", "how to minimally disturb the ecosystem", etc. That's not a realm of likes and dislikes, but of practicality.
One of the realities of today is that the average user is extremely distanced from the technicalities of Web, whether that's desirable or not. That puts a lot of burden on the informed and on the developers, which are often the same people. The few are obligated to make decisions for the many.
Do you deliver a box-shadow, but increase technical debt? Do you migrate to a more energy efficient platform, but alienate some users? Do you broaden the scope of your system, in turn increasing system complexity, or do you delegate to a dedicated third-party system, having the user possibly learn to use that third-party system?
It's a question of which compromise best serves the user. It shouldn't be a question of likes and dislikes. This is a complex situation rife with miscommunication, ignorance, conflict of interests, and inertia. Any simple solution, such as disregarding the opinions of developers, should be regarded with great suspicion.
Though it wasn't patently insulting, you have gone ad hominem - "to the man" - rather than the idea. Whether one is a developer or not, doesn't have any bearing on whether economy and efficiency are worthwhile values in a computer application. Although it so happens that developers tend to also be users. If they ARE users, then they represent users. Also in the sense of acting as an advocate of sorts for the user, developers represent users.
"Average" users having never been offered the thing being proposed here (faster and ad-free versions of the same apps, with the same network effects etc.), I don't see how you can state with any confidence that they wouldn't have chosen them, were they available.
What are you seeing that leads you to think this? The ads and engagement drivers (autoplaying videos of other content on the site) on sites that need eyeballs to keep the lights on, or the articles showing how to download the minimum usable assets so you don't waste the user's bandwidth, battery, and disk space[1]? The latter is what I tend to see when I'm looking at pages describing "best practice".
1: https://alistapart.com/article/request-with-intent-caching-s...
Some "best practices" articles discourage all this, but in my experience, that's ignored. The trend is in ever decreasing density.
It all makes sense if you consider apps following the practices I mention as sales drivers and ad delivery vectors. Putting aside the ethical issues of building such things, my issue is that people take practices developed for marketing material, and reapply them to tools they build, without giving it any second thought.
The world is bigger and more interesting than screens and screens of uninterrupted plaintext.
Fortunately, good dynamic HTML also exists.
And I wouldn't write off rounded rectangles as superfluous fluff. They're fairly ubiquitous in user interface design because round cornered structures are fairly common in nature. They make a UI look more "real". And decreasing the artificiality of a user interface isn't superfluous; it lets more users interoperate with the interface without feeling like they've strapped an alien abstraction onto themselves. A lot of people in the computer engineering space have no trouble working with alien abstractions for hours at a time, but it's an extremely self-selecting group. We are often at risk of believing that what is normal for us should feel normal for everybody.
https://bgr.com/2016/05/17/iphone-design-rounded-squares-exp...
You're aware that pure HTML and CSS alone can produce visually fancy content with pictures and colors, right? It honestly seems like a lot of web developers are starting to forget this, but it's true, I swear. My personal web site (https://coyotetracks.org/) is minimalist by design, but it has accent colors, custom fonts, Retina-ready images, and that silly little fade in and out when you hover over links, all without any JavaScript whatsoever. Also: turns out it works pretty well on Lynx!
I think JS gets a bit of a bad rap these days and am willing to leap to its defense even though I don't like it much as a language, but a huge chunk of the reason it has a bad rap is because people do bad things with it, by which I mean either malicious things or just unnecessary things. An awful lot of modern web sites could run just fine with far, far fewer scripts than they're deploying.
(And, yes, I can even do web analytics without JavaScript, because there are these things called "server logs" I can analyze with utilities like GoAccess.)
Sophisticated web pages are not necessary to disseminate text-only context. 90's HTML is perfectly capable of doing that.
I have no problem with loading 30MB of JS libraries into the browser for an application that actually does something. I have a problem with loading 30MB of shit to read 10kB worth of news.
Html did. It was hyper text, and rendering was done for document flow.
Then we could script a bit, and soon after we wanted "webapplications". Now, we lost probably 15 years trying to fit in an application-ui and lifecycle model in a document-flow model.
Html, or rather xml, or rather trees, are a good way to represent a user interface. Unfortunately back then, the only languages available were C++ and Java for any proper work oh yeah, and visual basic!).
Javascript, php, and perl were a godsend in terms of productivity. Just like the 80s home computers and basic. It just worked. Type and run. This is also why bad badsoftware gets popular btw..
Coming back to the post.. Lynx renders HTML how it was intended: as a document.
Most application UIs are not complicated. Most applications are just interactive documents. There is nothing special about 90% of the apps I use on my native computer that means they couldn't be rendered as HTML. The document model is fine for applications. Preferable, even.
Heck, a reasonable portion of the native applications on my computer have optional pure-terminal interfaces. If your application can work in a terminal, it can work with HTML -- and embracing a document model for your application UI would be a better user experience than whatever the heck pixel-perfect framework that everyone is chasing nowadays. That's true on the web, and it's true on native.
The problem with the web is not that HTML is incapable of being used as an application platform; it's not that we're trying to fit a square peg into a round hole. It's that both web and native developers overestimate the interface requirements of their applications, and bring in unnecessary cruft to achieve pixel-perfect layouts that are worse for end-users.
We have a square peg, and a square hole, but we like to go to conferences and pretend that our peg is actually some convoluted, recursive star shape.
And still average people aren't taking advantage of this and creating their own websites because despite it being massively easier, the way the web is now has pushed it still beyond the average person's reach. If these 'sophisticated' stacks and technologies weren't the norm and instead the web was more focused on being s place where.the average person can easily put up their own fancy looking simple webpage maybe we wouldn't be so dominated by these massive companies that have become the gatekeepers by providing limited platforms for people to do what did used to be a relatively easy thing even back in the day.
There's a reason these companies fund and push these technology stacks, it gives them huge control over the internet and in the end, they don't really do anything fundamentally different than what good old fashioned HTML and CSS can do. Hell especially the HTML of today.
Are you sure this is the case? Because I think it may be a shiny object trap, where on first view a visually fancy site is great and appealing but in the long run a simple, fast-loading site is preferable.
That is really the fault of "modern web", that web pages are more "sophisticated" than they really need to be to present the information they contain in a visually pleasing and usable manner. There are so many round-about approaches to the problem that people don't concern themselves with the most straight forward one. I can't say that it's somehow massively easier to create a simple list of links with some excerpt in a way that it doesn't work on a 15 year old browser than it is to create one that doesn't. You really have to go out of your way to break something as simple and fundamental as linking.
Well if talking progress, we can also compare, say, energy efficiency of information transmission, or the number of well maintained Web clients. That doesn't look so good, does it? The question is what problem are we solving, or, in your words, what is "sophistication"? According to some measures we did achieve impressive things. But a lot of us experience heartache, because we think we didn't do all that well.
There is no way that the percentage of developers doing that isn't vanishingly small. Like 0.1% or less. I always chuckle when 1 person chimes in on a show hn post to complain that the site doesn't work well in lynx... Ya, I'll get right on that, top priority!
> Regarding 'L', Lynx sometimes "hides" links if the anchor is around a div. Maybe it is just that simple. IIRC, <a href=...><div>...</div></a> will trigger a similar behaviour.
I'm generally against unnecessary web complexity, but I don't understand how anyone can paint Lynx a hero for randomly ignoring anchor tags.
I embrace progressive enhancement where possible, all of my blogs/sites will load and function without Javascript. I'm not going to serve alternative HTML in a scenario like this. There has to be a give and take towards Lynx supporting objectively valid pure HTML content.
It wouldn't violate any of Lynx's pure-text principles to parse modern HTML correctly.
I disagree strongly with this. The web has moved a lot in the direction of developer experience (ES6, modules) and new capabilities (WebSockets, WebRTC, WebAudio, SVG, canvas...). Yes, most of this happened because it's a side-effect of big surveillance capitalism companies wanting make that sweet sweet digital pollen to be even sweeter, but that doesn't make it any less sweet just because it was made in bad faith.
I can tell, because I order pizza quite frequently from a variety of sites.
They would be correct replies!
In addition there is this concept called "graceful degradation", where if the browser has more advanced features, you support them, otherwise you work anyway. It's not like supporting Lynx means you can't have a map in the search results when using Chrome. Certainly not for a company with the resources of Google.
Also they should probably send something like a Lynx-version of Google down to people with a poor internet connection.
As I recall it, we weren't mad about IE "holding back the Internet", we were mad about IE encouraging web designers to stick a bunch of dynamic clutter such as ActiveX controls into their webpages. Largely because they created this lock-in where sites only worked well on one browser.
It turns out that JavaScript has been co-opted into being the new ActiveX, and Chrome is the new IE. But since JavaScript is nominally an open standard, and Chrome runs on the big 3 OSes, nobody seems to get mad that alternative browser projects are dying because they can't keep up with all the stuff that needs to be implemented in order to work well with sites that were only tested on Chrome and WebKit.
Anyone who has heard of the phrase "embrace, extend, extinguish" should be at least a little bit uncomfortable with this situation. For example, it implies that any potential alternative OS needs to be able to compile Chromium (or, as what can only be seen as a second-class substitute nowadays, Gecko) before it can really be viable. If you're the kind of person who likes a free, open and competitive software landscape, that's a looming threat.
- 1. you need a beefy device to render in a reasonable timeframe
and
- 2. you need The One Blessed Renderer to even see anything
I do recall the situation 20 years ago, when I could use about 2/3 of the relevant Net, with the rest going "meh, chronic complainer, just use IE. What? Yeah, that's your own fault for not choosing Windows." The second part is far more worrying, as it is not resolvable locally, either by optimization, or by horsepower.
OTOH I don't worry too much, accessibility-enforcing laws will provide plenty of job opportunities for future developers... So yeah, good move, I guess.
Not sure that's the case, if so, I'd expect a comment that shows a little deeper understanding of the issues involved.
"HTML from 1999" isn't the issue. Lynx did fine on that... and HTML from 5 years ago, just like a whole host of non-visual or semi-visual user agents.
brow.sh is... OK, I guess, nice to have around in a pinch, but like most other schemes that rely on a headless full-fledged browser in order to work with applications that have become dependent on JS to merely render content it introduces a glorified screen-scraping layer to something that can easily be much simpler, assuming web application developers can be bothered to think about it.
We don't need to freeze the web at 1999, and some applications fit poorly in a non-visual context. But a little bit of reflection on how the merits of progressive enhancement and moving forward without losing the benefits we had at that stage would be nice. The stage where people cared about such things was pretty amazing in terms of the breadth of devices web applications would in fact work on pretty well.
Also, if you're not thinking about pretty plain HTML version of your app, chances are half decent you're missing an opportunity to engineer your application better whether or not you care about UA interop.
But, you know, if you're pretty sure the browser should be "thought" about as nothing more than The VM That Lived™, by all means, carry on.
AFAIK most of us don't complain when a dynamic website doesn't work. We just use a modern browser.
Yeah, web standards such as images and video and audio. Not keeping up with those standards is kind of the point.
Does headless Firefox (what brow.sh is at it's core) even launch if there's no X11 available? Is it that headless?
If you can make something without JS you should. cryptomarketplot.com has an accessible mode FOR CRYPTO!! If crypto sites can, everybody can.
I think you may be blind to the harshest criticisms, though. It was a common view that the web was built for static content (or server-side dynamic content) and code execution by the client is mostly a nuisance at best. And there is some validity to that. When JS was developed, roughly contemporaneous with worse ideas like java applets and ActiveX on the web, it was thought by proponents that untrusted code execution is OK to good. 20 years later, it was still assumed that if JS is sandboxed, memory safe, has a different page table from the rest of user mode, untrusted code execution is safe. Then spectre and meltdown happened.
And tangentially, I was pointing out more recently that the grumpy position from older times actually would have prevented some real world problems. (Spectre and meltdown go from being local privilege escalation bugs to "holy shit you can own my machine if I visit a web page")
https://www.brow.sh/ is a console-based browser that claims to support modern standards. Perhaps that is what we should be using.
(I am now prepared for 6 comments replying to me saying that anything that can be implemented with HTML from 1999 should be, and a list of search results can be. I guess. If all that stuff works for everyone, why did we invent new stuff? Just because? Or perhaps it wasn't really as amazing as well all remember.)