This post is emblematic of why I hate modern front-end development practices so much. Designers only really care how it looks, and don't really grasp the full functionality of the web browser. As...
This post is emblematic of why I hate modern front-end development practices so much. Designers only really care how it looks, and don't really grasp the full functionality of the web browser. As a result it's not uncommon to see common elements that don't behave properly.
I have lost track of all the major websites I have been to that have broken built-in browser functionality in some way or another. The most commonly broken elements are usually centered around forms. It's very common for tabbing between fields to not work on every elements. Some elements, such as dropdown menus, are actually partial reimplementation - you can click to expand the menu, but you can't start typing to find the entry you are looking for. It's especially irritating to me because it violates a basic rule of software development - you don't overwrite a class without replacing all of it's methods! It's like they are trying to reinvent the wheels and instead of drawing circles, they are drawing octagons.
It's always irritating to talk about it to the web development community. It seems that there is this pervasive mindset that the browser is some kind of bad faith actor or something. I see so many people who try to make things in these new ways without ever questioning why they were made the way they were in the first place. And as a result they are making the web less and less accessable.
That might depend on the community. Smashing Magazine for instance often covers accessibility topics, and strongly encourages aria attributes and such. Using new semantic tags has also helped in...
It's always irritating to talk about it to the web development community.
That might depend on the community. Smashing Magazine for instance often covers accessibility topics, and strongly encourages aria attributes and such. Using new semantic tags has also helped in adding context for screen readers.
What really gets my goat is those who reimplement scroll bars, but do so in non-standard ways. Removing the up/down arrows, making it thinner, or removing the snap feature which allows you to return to your original scroll location.
This is why I'm glad there is new support for styling the scroll bar without affecting those features. People are less likely to screw it up that way.
Absolutely, this is something I feel really strongly about as well, but I don't think I'd put the fault specifically on designers. A lot of it comes from this recent inclination to do everything...
Absolutely, this is something I feel really strongly about as well, but I don't think I'd put the fault specifically on designers. A lot of it comes from this recent inclination to do everything as a single-page app and "flip the web pyramid", where everything is being done in Javascript. Like you said, instead of using standard HTML form elements that have a whole bunch of inherent capabilities, people reimplement everything from scratch as a <div> (and being able to have full control of the appearance is definitely an aspect of it).
I notice it happening a ton with links/buttons too, where they just use a <div> with some on-click behavior, but that tends to miss out on a lot of behavior that should be there—being able to right-click and copy the link, ctrl-clicking to be able to open in a new tab, etc. Then the developers have to reimplement all of these behaviors from scratch, and they usually still don't quite get it right.
I think it's a really bad aspect of modern web development, and has a ton of side effects with browser compatibility, accessibility, and so on. It seems simpler for people to do it that way at first, but when they have to go back and reimplement all the extra capabilities, fix the edge cases, etc., it ends up being far more work in the end than if they had just used the standardized element in the first place.
I think this recent post did a really good job of talking about some of the factors that have led to this: Big ol' Ball o' Javascript.
I'll admit designers were just the easy target when I wrote that; there are clearly more people to blame for this kind of thing happening. I think your article probably hits the nail on the head...
I'll admit designers were just the easy target when I wrote that; there are clearly more people to blame for this kind of thing happening. I think your article probably hits the nail on the head as to why this is happening; the people upstairs don't know anything about software development and they choose to hire "full stack" developers who are currently being pushed into being glorified JavaScript developers. When that's your professional environment, JS becomes the hammer you use for everything.
The thing that drives me crazy about all of this is how obvious the problems with this approach are to me. SPAs rarely perform as well as simple web pages and they are massively more complex to implement than if you simply allowed the page to refresh. For example, some large scale web applications are so complex that they require a renderer for both the frontend and backend. This is, of course, because the application is so slow that it would take to long if the customer attempted to directly access or refresh the page.
SPAs are bloated pieces of shit. I'm honestly fine with JS frameworks--MVVM is a godsend--but you still need to have distinct, separate pages so you don't drag everything to an infuriating crawl....
SPAs are bloated pieces of shit. I'm honestly fine with JS frameworks--MVVM is a godsend--but you still need to have distinct, separate pages so you don't drag everything to an infuriating crawl. Whenever I work with Vue.js, I only use the core library and keep distinct pages separate from one another. Load times are snappy, bandwidth usage is minimal, and the page isn't bogged down by several MBs of assets and garbage JS filled with a bunch of "clever" hacks that pile on technical debt with wild abandon.
Why the fuck people want to deal with bundlers, transpilers, polyfills, multiple package managers, and all of that other bullshit just to get the simplest of projects up and running will forever be a mystery to me.
As a web developer I feel your pain but on the website I work on almost all of the built in browser form elements have been overridden because most of the users are on fucking IE which is missing...
As a web developer I feel your pain but on the website I work on almost all of the built in browser form elements have been overridden because most of the users are on fucking IE which is missing even the most basic of things like a date picker and then you get people complaining the buttons look like shit but its just because their system theme looks like shit and the browser uses the same UI theme as the OS. I'm doing everything in my power just to keep the website supported on firefox because management doesn't care at all about it (understandable when there are actually 0 customers using the website with firefox)
It's strange you have 0 Firefox customers and an overwhelming number of IE customers, since most data points to there being more Firefox users than IE, with Chrome eclipsing both of them combined....
It's strange you have 0 Firefox customers and an overwhelming number of IE customers, since most data points to there being more Firefox users than IE, with Chrome eclipsing both of them combined. Are you working on an enterprise or intranet application?
This post is emblematic of why I hate modern front-end development practices so much. Designers only really care how it looks, and don't really grasp the full functionality of the web browser. As a result it's not uncommon to see common elements that don't behave properly.
I have lost track of all the major websites I have been to that have broken built-in browser functionality in some way or another. The most commonly broken elements are usually centered around forms. It's very common for tabbing between fields to not work on every elements. Some elements, such as dropdown menus, are actually partial reimplementation - you can click to expand the menu, but you can't start typing to find the entry you are looking for. It's especially irritating to me because it violates a basic rule of software development - you don't overwrite a class without replacing all of it's methods! It's like they are trying to reinvent the wheels and instead of drawing circles, they are drawing octagons.
It's always irritating to talk about it to the web development community. It seems that there is this pervasive mindset that the browser is some kind of bad faith actor or something. I see so many people who try to make things in these new ways without ever questioning why they were made the way they were in the first place. And as a result they are making the web less and less accessable.
That might depend on the community. Smashing Magazine for instance often covers accessibility topics, and strongly encourages aria attributes and such. Using new semantic tags has also helped in adding context for screen readers.
What really gets my goat is those who reimplement scroll bars, but do so in non-standard ways. Removing the up/down arrows, making it thinner, or removing the snap feature which allows you to return to your original scroll location.
This is why I'm glad there is new support for styling the scroll bar without affecting those features. People are less likely to screw it up that way.
Absolutely, this is something I feel really strongly about as well, but I don't think I'd put the fault specifically on designers. A lot of it comes from this recent inclination to do everything as a single-page app and "flip the web pyramid", where everything is being done in Javascript. Like you said, instead of using standard HTML form elements that have a whole bunch of inherent capabilities, people reimplement everything from scratch as a
<div>(and being able to have full control of the appearance is definitely an aspect of it).I notice it happening a ton with links/buttons too, where they just use a
<div>with some on-click behavior, but that tends to miss out on a lot of behavior that should be there—being able to right-click and copy the link, ctrl-clicking to be able to open in a new tab, etc. Then the developers have to reimplement all of these behaviors from scratch, and they usually still don't quite get it right.I think it's a really bad aspect of modern web development, and has a ton of side effects with browser compatibility, accessibility, and so on. It seems simpler for people to do it that way at first, but when they have to go back and reimplement all the extra capabilities, fix the edge cases, etc., it ends up being far more work in the end than if they had just used the standardized element in the first place.
I think this recent post did a really good job of talking about some of the factors that have led to this: Big ol' Ball o' Javascript.
I'll admit designers were just the easy target when I wrote that; there are clearly more people to blame for this kind of thing happening. I think your article probably hits the nail on the head as to why this is happening; the people upstairs don't know anything about software development and they choose to hire "full stack" developers who are currently being pushed into being glorified JavaScript developers. When that's your professional environment, JS becomes the hammer you use for everything.
The thing that drives me crazy about all of this is how obvious the problems with this approach are to me. SPAs rarely perform as well as simple web pages and they are massively more complex to implement than if you simply allowed the page to refresh. For example, some large scale web applications are so complex that they require a renderer for both the frontend and backend. This is, of course, because the application is so slow that it would take to long if the customer attempted to directly access or refresh the page.
SPAs are bloated pieces of shit. I'm honestly fine with JS frameworks--MVVM is a godsend--but you still need to have distinct, separate pages so you don't drag everything to an infuriating crawl. Whenever I work with Vue.js, I only use the core library and keep distinct pages separate from one another. Load times are snappy, bandwidth usage is minimal, and the page isn't bogged down by several MBs of assets and garbage JS filled with a bunch of "clever" hacks that pile on technical debt with wild abandon.
Why the fuck people want to deal with bundlers, transpilers, polyfills, multiple package managers, and all of that other bullshit just to get the simplest of projects up and running will forever be a mystery to me.
As a web developer I feel your pain but on the website I work on almost all of the built in browser form elements have been overridden because most of the users are on fucking IE which is missing even the most basic of things like a date picker and then you get people complaining the buttons look like shit but its just because their system theme looks like shit and the browser uses the same UI theme as the OS. I'm doing everything in my power just to keep the website supported on firefox because management doesn't care at all about it (understandable when there are actually 0 customers using the website with firefox)
It's strange you have 0 Firefox customers and an overwhelming number of IE customers, since most data points to there being more Firefox users than IE, with Chrome eclipsing both of them combined. Are you working on an enterprise or intranet application?
Not intranet but very enterprise