Hacker News Reader

Webdevs don’t seem to have much of a user-centric view of the sites they develop. The vast majority of use cases on the web are “I want to see a list of options then fill in a form”. All the tech needed to shop online or bank or pay bills or book travel or whatever existed 20 years ago (SSL being the last piece of the puzzle, all the rest is just plain HTML).

Fully agree, plain old cached SSR with a little sprinkle of JavaScript when it really matters.

The thing is too, anyone can do that. HTML forms are easy, generating HTML is easy. There just doesn’t need to be any webdevs, the dedicated role doesn’t need to exist. No amount of trying to rebrand themselves as “full stack engineers” will save them when that realisation dawns on the people paying their over-inflated salaries!

As long as the web is a viable software distribution platform, the world will need "webdevs". 2019 is still a chaotic time for the platform, and winners and losers still haven't really shaken out, not even at a basic architectural level. There are profound questions about what computation gets done where, what side-effects happen where, which in turn influences everything about how software is built, tested, distributed, and run, and yet they aren't really answered so much as philosophized about.

If form controls like select lists and checkboxes were style-able and compose-able I think it would reduce the need for JS in many cases.

Multi select in particular feels like it's stuck in the 90's.

Also select's lack of consistent search capabilities is painful.

Sorry, I'm not convinced that UI elements need to be "style-able" by the site. Every site ends up being slightly different from others as a result, because it feels the need to reinvent its own custom UI controls with their own behaviour inconsistent from the OS or even the browser's UI. (I have the same gripe about "native" Electron apps.)

Yeah, good luck with that. Every company wants to stand out. There's no money to be made from conformity.

Searchable select is now a thing (for 90% of users at least).

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

Select elements are pretty decently style-able nowadays [0], though the options in the dropdown don't seem to be supported (at least in Firefox).

https://www.filamentgroup.com/lab/select-css.html

I'm certainly no CSS guru. And as you said, CSS doesn't cover everything. However, you can do quite a bit with CSS that most developers don't bother with:

https://bradleytaunt.com/dynamic-checkboxes/

https://bradleytaunt.com/easy-custom-radio-inputs/

https://normform.netlify.com/

> Yes, I know some things simply can't be done without a JS webapp, but not all and probably not even a majority, so if HTML and CSS will do the job fine, then so be it; and even if it needs to use JS, it likely doesn't need to be latest-browser-only JS either.

Sticking to HTML and CSS won't necessarily get rid of this - new stuff is being added to CSS all the time, in particular. And browser support is just as patchy.

How much new css do you actually use though w/ patchy browser support?

There are many essential css properties that Firefox doesn't support, e.g fit-content

https://caniuse.com/#search=fit-content

All browsers seem to have bugs with it. I also don't understand how it's essential.

But when a browser doesn't fully support a CSS feature most of the time is your site just looks a little wrong. Unless it's a major feature, the site will probably still be functional to the user.

The flip side of this is that many new JavaScript features can be either transpiled to ES5 syntax, or polyfilled. It will be great when we don’t need to anymore, but I’m always pleasantly surprised by just how much modern JS can be used in, say, IE11, just by having Babel be part of the build step.

CSS unfortunately doesn’t work that way, so apart from graceful degradation you’re out of luck.

> I'd say it starts with dialing back the "new feature/change fetish" that a lot of web developers have

I wonder whether this phenomenon is driven by HTML, CSS, and JavaScript being such lacklustre tools for building applications?

Many things that are completely reasonable to deal with in any “native” stack (animations, local storage, offline access, hardware access, accessibility just to name a few), while usually possible with a web stack, are often unnecessarily difficult or awkward.

Things are improving fairly rapidly because of the insistence that everything should be web based these days, and I could totally see that driving people to the bleeding edge.

I mean hell, I do it myself. I’m a web developer, and when reading about shiny new features I’m often eager to start using them ASAP — especially when it would replace a bunch of kludgy JavaScript I’d been relying on previously.

Yes, I think that they should do back all of that "new feature/change fetish" as you say. It also would improve compatibility, to not do such messy stuff, too.

Most web pages will not need any JavaScripts, although some might need it. And in some other cases, optional JavaScript might help, such as to auto-fill or validate a form, in which case the form will still work with JavaScript disabled. (Also note that, for example, Lynx does not implement JavaScript.)

For some of that, my idea of a <widget> element might help a bit. It would improve performance, allow better user customizations, allow enabling some functions that would previously require JavaScript even though JavaScript is disabled, and is compatible even with browsers that do not implement <widget>.

CSS is also overused, although even if you use it, you should try to also allow working without CSS in cases where such a thing makes sense (which it often does, although not always). (CSS styles often just make stuff worse in my opinion anyways; that is why I put in my own CSS codes for stuff.)

I think, the end user need to have enough ropes to hang yourself and also a few more just in case. The entire control of the interface should be controlled by the end user.

Also, these web pages and HTTP(S) are rather overused anyways. There are other protocols, such as Gopher and Telnet and SSH and NNTP and IRC, which are better for some things (and worse for some things, too, I suppose). (But multiple protocols and multiple interfaces can be offered if wanted, anyways, I suppose.)

The problem with this is that the web is competing with native apps. A vanilla HTML site might be good enough in some cases but often you really need to push the envelope of what’s possible the web and that’s hard to do and also support niche browsers on a tight development budget.

You can install a “progressive web app” as a native Android app now. There’s been a big push to develop PWAs on the heels of react and single page apps for a couple years now - google is doing a good job trying to support the web as users move so aggressively to mobile. Facebook basically has its own browser in-app(iOS and Android), i bet that browser has more traffic than Firefox.

Google is a bit schizophrenic though.

You can watch IO talks from Android, Chrome, Flutter where the presenter eventually throws some jabs at other competing stacks as if they aren't from the same employer.

All large companies are schizophrenic to some extent.

Where I work, departments bill each other. Sometimes, two departments develop competing tools that are third department could make use of. Instead the third department use an off the shelf tool because the "license" for the internal tools is too expensive.

At these scales, companies are almost like states. A group of entities with shared services but otherwise working independently.

The problem with this is that the web is competing with native apps.

Only for certain things. A lot of web browsing is still pure information-consumption. The "native apps" are also turning into effective webapps, thanks to Electron and the like.

Even this site, which is interactive, doesn't require JS to use (it provides some enhancements, but the site is still quite usable without.)

Google's practices pushing web non-standards haphazardly are so heinous that even Electron can't usually handle general web apps, like WhatsApp (especially) because it depends on Chrome-specific, not even Chromium, features. Many others are the same way.

Can you cite this? I'm collecting a laundry list of reasons Google has degraded the web, and this is certainly evidence.

If you go back in time far enough, Google has improved the web exponentially more than it has harmed it.

This is a bit hard to say, right? Google is also responsible for the normalization of aggressive user tracking and the creation of the ad-ridden tire fire that is the modern internet.

I wrote up one example that was particularly frustrating when I realized it [0].

[0]: https://www.reddit.com/r/programming/comments/ar1qj1/_/egl52...

> The problem with this is that the web is competing with native apps.

No it isn't. Competition with native apps is the completely wrong way to think of it. The web should complement native apps.

From my experience, JS is relatively portable, at least if you stay away from some corners. CSS (and some aspects of HTML) are a much more likely reason for strange differences between browsers. Another common culprit for browser-specific bugs is simply using browser-specific CSS extensions, because sometimes it is simpler than fiddling with standard CSS until it looks right.

As a web developer, I love using new features. 90% of the time though, the new features can easily be covered by a polyfill, and there is no excuse not to use poly fills.