“A polyfill is code that implements a feature on web browsers that do not support the feature. Most often, it refers to a JavaScript library that implements an HTML5 web standard, either an established standard on older browsers, or a proposed standard on existing browsers.”
Footwear manufacturering/sourcing industry (meaning also targeting footwear brands). B2B with a global crowd; a significant chunk on old company computers (or phones). It's not many, but it's been quite steady at 1-2% of our user base. Since it's fairly easy to support IE11 (not pixel perfect) once everything has been setup, we have to keep it. We're thinking about doing a similar approach as Twitter, but it's not been prioritized yet.
We're a big eCommerce and we're still supporting IE11. We're close to dropping it but it still shows up at about 4% to 5% of our users. And it's not that hard to support IE11, just need the right Webpack configs and polyfills and etc.
It would be interesting to see if traffic drops by that much, or a significant number of those users keep using your site but with a different browser.
Yeah, that's one niche market (or not niche?). I don't know of any competitors. I am really interested about their customers and how much revenue they are pulling.
Microsoft has migrated nearly all non business users to Edge. Using IE gets big scary warnings to use Edge when using Bing and MSN and most consumer websites don’t support it any more. It is safe to assume that IE usage is forced usage by companies. Web developers should boycott companies that use IE.
B2B side has been moving slowly off IE11, but moving faster since the start of the year and with most of the rest of the customers targeting to be off of it originally by end of quarter. Currently sitting around 40% but if they go through with their plans to upgrade by end of quarter then will be around 5%
B2C side is much lower, the users who visit not very frequently or are newer that use IE is low single digits. On the other hand we have some long term continuous use users who use IE at a higher rate than the B2B side
Digital photography: news and testing, normal visitors are probably all on newer browsers, but during workdays, we get up to 3% IE11 visitors, this falls to under 1 on weekends.
I make a JavaScript/TypeScript library (https://gojs.net) which is used by many enterprise and governmental customers for their internal apps. I still support IE11 (and 10) because of that.
We’re an e-commerce site, and target ie10+ but lately have been relaxing that requirement. We will likely move to no IE support in the next year or two.
Our agency dropped support last week. Our metrics still show ~3% of all traffic comes from some version of IE (that's from the ~450 sites we currently host). It finally hit a point where it was holding us back design wise and adding too much time to be worth it. We're phasing out support so anything sold before the drop date is still entitled to it, but new projects and new features on those old sites will no longer support it going forward.
The sites range from small mom & pop stores to restaurant chains with dozens of locations worldwide to large scale CRMs for larger corporations. We're all over the place. The sites we host, which often do not include our bigger clients, are doing about 30 million unique visitors each week across them currently. Not a massive amount of traffic by any means, but it's still upwards about 400k users we're dropping support for (in addition to about 500k on older versions we already dropped).
Note: all of my metrics are coming from server access logs. Nothing complex any no front end validation of the browser versions (I don't have access to client-side Analytics for each site)
I still occasionally maintain a website for a school, with stats that'll horrify you.
Around 78% of browsers hitting the site are running IE8, and these will be parents making use of the portal to do stuff like check calendar dates, book appointments to see teachers, and check student grades.
We tried extremely hard to move the community onwards, including outreach to upgrade computers for families and so on. But in the end, they just don't want to move on from Windows XP because everything else is too confusing. Even if you make it look the same.
As for how often they're using the site... It's somewhere around 1/3rd of the parents hit it at least once a day using an outdated browser.
... Whilst their kids are using school-provided Thinkpads all running on Windows 10, or recent-ish school-provided iPads. (The school does all the maintenance on them as well).
If Google and Mozilla aren't going to step up their "managed browser" game then we're going to continue seeing MS and Apple dominate education. It's not like school IT depts like running IE, but it's basically the only browser you can lock down.
"But you shouldn't lock down kids' browsers, and let them have blah blah..."
Okay look, I don't actually give two shits if little Marcus wants to browse Pornhub on his school laptop, we're honestly not paid enough to care. But we do have administration breathing down our necks, school policies to enforce, and angry detached parents to appease.
The only way I think this could happen is if everyone is still on Windows XP. Probably because pirated winxp was still being circulated when the parents installed.
Still hard for me to believe the figures though. 78%??? Wonder which country they live in.
I've seen things like that here in Mexico but not winxp, and not in 2020. And not to younger parents with kids who can use computers. Maybe they're in China or something where pirated winxp still apparently flourishes.
Are number of these same parents complained rather loudly when programming was added to the curriculum, because if they didn't understand "the technology", they didn't want it in their home.
Think... The sort of people who print and mail pictures someone found on the internet, because they never touch email.
A recent project I worked on b2c, online insurance quotes, the audience is 25-50 ish. Previous analytics were indicating only a small single-digits percentage, but the customer wanted it anyway.
The customer was happy for us to only cover "core functionality" and not visual and minor issues in IE 11.
I maintain the priamry website for a winterguard association in south texas. (Colorguard: choreographed waving of flags, usually alongside a marching band or performed to recorded music.)
Because it's an educational organization, we must assume that members are operating on outdated solutions behind weirdly restrictive firewalls. I don't bother to fully support Internet Explorer for all features, but I do need to make sure the critical path at least functions on a basic level, and I'm careful not to rely on any dependencies (analytics, etc) that I cannot self host.
Of course, it's the directors who insist on doing everything on their iPad that give me more trouble, as I don't actually own one to test. :)
Not really. :) This organization operates on a shoestring budget, and I volunteer my time to maintain their backend. On the odd occasion that the layout breaks specifically on an iOS device and resists local troubleshooting, I just borrow my Dad's iPad and check it there. I've had much fewer troubles since switching to Semantic UI's media breakpoints though; simply resizing my browser window to "tablet" size catches the vast majority of issues.
I suppose we don't! Presuming these aren't bots, here's a count of every hit claiming to be trident (IE 8 - 11) just this month:
#zgrep -i trident access.log*.gz | wc -l
580
It's not a huge number of visits to be sure, but we're also a rather small organization and in our off season, so we're not receiving a whole ton of traffic to begin with.
In the Healthcare world, computers frequently lag behind the state-of-the-art. Writing Healthcare IT webapps, we had to support IE6 up until ~2013. If your nation-wide pharmacy chain customer is primarily running IE10 on outdated Windows PCs they refuse to upgrade, your app had better be very well tested on that browser.
Gamers tend to be pretty technically inclined, so the audience mostly uses pretty modern browsers.
I support down to ES3 (Safari 5, IE9) mostly because I can (I learned web dev back in the old days and still remember all the tricks), although it's nice to see fans talk about playing on obscure platforms like the Nintendo 3DS browser or a Samsung smart refrigerator.
Animations are implemented in jQuery animations, and the networking is provided by SockJS (which can fall back to JSONP long-polling and even iframes if the browser doesn't support WebSocket).
GitLab employee here. We just have dropped browser support for IE11 in May with our major 13.0. Nobody complained about us removing it despite us announcing it in January. [0]
Already removed some polyfills, biggest win will be transpiling just for modern browsers [1]. This all ties in nicely with general performance initiatives.
I really don't understand the hate that Safari gets for this. What's even the point of having different browsers if people get mad at any differences between them? Chrome, but made by four different companies is kinda the illusion of choice and competition.
The standard just says if you're going to have $feature, this is what it has to look like. A web browser on a platform with no concept of notifications can still be standards compliant.
A browser with no support for DRM can still be standards compliant too.
This is literally how all standards in browsers are being initially created. Someone has an idea, implements it eventually in a browser, thinks it´s so good, they want other browsers to support it too so they make a proposal. If others like it, they´ll support it and try to find faults. Eventually it gets either rejected, or approved and others follow suit (most of the times).
Although, some browser teams, like Google Chrome, has apparently the ability of just shoving Google people in the standards process so they can fast-track stuff.
But in the end, it's _supposed_ to work in the fashion where one browser starts implementing something, then others.
I’m wasn’t complaining about Chrome testing something first. I agree, that’s how it is supposed to happen.
I’m complaining about the armies of web developers who seem to think Chrome IS the standard and anything Chrome has that other browsers don’t mean the other browser is ‘The new IE’ and ‘holding the web back’ even if it just came out last week.
A standard designed by people from Google, discussed exclusively by people from Google, fast tracked into Chrome by people from Google and then released in Chrome with utter disregard to any issues raised by other browser vendors does not a standard make.
Unfortunately, since most web devs develop under Chrome (and rarely if ever test under other browsers) this perpetuates the myth that "Safari is holding the web back" or "Firefox is slow and doesn't implement standards fast enough".
Here's total Web Apis counts in different web browsers: [1]
- Chrome: 7106
- Firefox: 6376
- Safari: 6130
Of them: browser-specific APIs that developers cannot reasonably assume are a part of the web platform:
- Chrome: 949
- Firefox: 507
- Safari: 546
And in 2017-2018 Chrome removed over a thousand APIs that were only implemented in Chrome, but were assumed to be standards"
[1]
And if you look at the omissions tab, you'll see that Firefox and Safari and not too far behind Chrome. But they are very wary of implementing quite a few standards just because Chrome fast tracked them (Constructible Stylesheets? Safari flat out refused to implement them. Signed HTTP exchanges? Mozilla considers them harmful and will not implement etc. etc.)
For most of its history IE auto-updated but was never considered evergreen because its update cycle was tied to the much slower OS update cycle and the cost gating of OS upgrade purchases. Evergreen tends to also imply "shorter update cycle" (at least regular six-month intervals seems to be the general case now) and little to no gating.
A site whose only purpose is to display short pieces of text, some images, and occasionally video somehow needs the very latest in software (which often also means hardware...) to do that, when those capabilities have been around for over a decade?
Fuck the users if they're using anything older, force them to buy new hardware and create more e-waste, because we just want the latest crap regardless. That sums up the sad state of "modern" web development.
I'd love to see some stats on page load times etc.
There's a lot of repetitive debate on HN about JS web apps slowing things down and I'd like to know if the effects would be as bad if you could use the latest browser tools unpolyfilled.
It used to be terrible due to long parsing time but over the past 5 years or so, things have really improved, even more so in v8 recently [1]. Nowadays it's safe to just focus on the overall package size. And once it goes over a certain size budget (that's over 150KB gzipped as my personal preference) split it up and ideally use the PRPL pattern.
I added support for ES2017 bundles for compatible browsers for Instagram.com a couple of years ago - we saw a 5.7% reduction in the size of our core consumer JavaScript bundles when we removed all ES2017 transpiling plugins from our build. In testing we found that the end-to-end load times for the feed page improved by 3% for users who were served the ES2017 bundle compared with those who were not (more info here https://instagram-engineering.com/making-instagram-com-faste...)
I'm actually kinda curious about this in regards to browser finger printing.
This isn't like statistics in a political poll where there is an expected margin or error, when it comes to logging sites you absolutely know everything about your users in regards to browser, operating system, and even the hardware (sometimes).
3% of a million is 30,000, 3% of 500,000,000 is 1,5000,000. An absolutely real chunk of users that can produce real value (for Instagram, ad dollars).
Why would there be a margin error at all? How would it be introduce? A large portion of crawlers masking themselves? I mean it's possible, but I do not know if that's enough to throw off proper logging.
Why do you think its in the margin of error? I never mentioned the error bars on the statistic - We did an extensive AB test and it was a 3% stat-sig improvement
A 3% improvement on a 3 second page load means it loads in 2.91 seconds. So even if it were statistically significant, it's not practically significant?
Unless your initial page load is taking like 10 seconds, a human wouldn't even notice. And if it is taking 10 seconds, well, then you've got better things to fix.
That's not an actual improvement. That's just noise.
I worked at a big web site and we could demonstrate lots of incremental revenue (many millions of dollars) from a change like this. Even though it doesn’t seem noticeable to an individual, it adds up. If you draw a graph with page load time on one axis, and usage on the other, it’s a smooth curve, not a step function. Out of all your customers, some fraction of them are going to get distracted and disengage after 3 seconds but not after 2.9 seconds.
Imagine you lower the grip on everyone’s tires by 3%. Most people wouldn’t notice, but for a few people it will prevent them from being T-boned when they wait too long to brake for a red light. That improvement would be measurable if your data was good enough. I’m not saying optimizing your website is important like preventing car crashes, but it’s an illustration of how a small change can lead to a measurable improvement.
Thats why you should also track other metrics when AB testing performance changes. During my time at IG, even small perf improvements almost always corresponded to stat-sig improvements in engagement metrics. 100ms is a pretty significant performance win, definitely not noise - the other thing is that those wins often scale by the quality of device & connection. So a 100ms win for a high end desktop on fiber internet could be multiple seconds for a low end mobile on 3G.
Glad to see at least something happening on the web side of Twitter. Because frankly their website is a hot mess of invalid, incorrect or messed up UX states and interactions.
Hopefully that will be the next step after reducing the bundle size.
The polyfills, not their own code. Effectively all they did was update their browser support baseline, dropping support for very old browsers, with the result that about 14KB of code that made it work on those old browsers can now disappear, because more recent browsers don’t need it.
Anyone elses scrolling still messed up with ad blocker?
And hope this change makes it easier to block trends from explore tab. I love topics, but I don’t wanna see all the celebrity and politics crap every day...
Twitter is unusable if you want to avoid Politics. I unfriended almost everyone but all it takes is a single Like from anyone and it's Politics galore.
I really wish they'd add "harmony mode" or something that would get you away from the shrill toxicity of standard Twitter. People can't help themselves but click "like" on the most extreme statements possible, so users are incentivized to make the most extreme statements to maximize likes.
The only success I've had is by starting a private list of knowingly healthy users that's aggressively curated to make it stay that way, and never looking at the home timeline.
>The tweet box is not even a <textarea>, it's a <div> stuffed full of <span> elements.
ah yes, because webdevs love reimplementing widgets from scratch. that's no a problem in and of itself, but they also implement it half-assed, so you end up with gems like what OP described, or links being implemented as <a href="#"> with an onclick.
I think you'd find most front-end developers don't love reimplementing widgets from scratch but instead are required to because designers, product owners and customers expect this sort of experience. I just don't think Twitter would remain competitive if it had the interface of Hacker News.
Or because their requirement aren't just plain text. Browser's builtin controls isn't really customizable, for example you can't change a color of a specific word in a textarea.
Twitter likely uses content-editables over input elements because there are certain features which require more complicated, dynamic rendering than just plaintext (hashtags, mentions, links). They probably even have a team of frontend developers dedicated to this one thing. Rich text editing on the web is something everyone, not just Twitter, has trouble with, specifically when dealing with mobile, with IME, or copy-paste edge cases. I get your frustration, but know that this is one of hardest problems remaining in modern web dev, and it’s a feature which is expected by the majority of users, who don’t spend their days editing plain-text files. I do think it’s funny that you opened a web inspector, saw the divs and spans, and decided to get mad about that.
Rich text editing is one of the harder problems I’ve worked on in software, which seems strange to type but... Absolutely, it’s a hard problem. I think I’ve done other things people would (I know I did) assume were much more difficult, but in recent memories that was definitely one of the biggest pains in the ass I encountered.
Come to think of it, I was basically hired to do that one thing because the existing team was struggling with it and it was blocking a launch.
That's because you're using Firefox on Linux. I have literally no fucking idea how they managed, but all these bugs are only present in Firefox on Linux. Chrome works everywhere, Firefox on Windows works, it's just Firefox on Linux that has that problem. Skype's web client in Firefox on Linux also used to have the crash-on-paste problem. I suspect there is some framework somewhere in there that both of those used and it was crashing, but Microsoft updated to a newer version while Twitter have not, for whatever reason.
I hate that this is an issue, but I am happy to learn I'm not the only one who has every single one of these issues dozens of times over the last year.
Has anyone else noticed that as of a few days ago, middle-clicking a tweet that's embedded in another tweet (like a retweet with comment) causes the new tab to steal focus? It's worse than scroll jacking IMO.
That's awesome! Man, things on the front-end side are shaping up pretty nicely these days.
Also Twitter is such an incredible product. I love it. It's one of the few curate-by-default (along with Instagram, another masterpiece) feeds one can have. If your feed sucks, only you are to blame. Beautiful.
After looking at my networks tab[1], I had misunderstood this. It's only the size of the polyfill that has been reduced. The page is still downloading 800KB of javascript.
We tried doing this at Facebook few years ago but decided not to bother due to an insignificant effect on user metrics like TTI (time to interaction), FCP (first content paint), etc.
14KB is nothing when you're shipping 1MB+ of JS and all the other assets.
141 comments
[ 4.2 ms ] story [ 94.8 ms ] threadhttps://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
update: thanks for disambiguating the title, OP!
Edit: For context, previous title was "Twitter web app gzip size dropped from 16.6 KB to 2.7 KB by removing polyfills"
modern: ES6+, less polyfill
legacy: ES5, more polyfill
The appropriate variation is served by detecting browser’s version from the User-Agent string
https://angular.io/guide/deployment#differential-loading
https://twitter.com/charliecroom/status/1291478104016289799
https://twitter.com/i/release_notes
I'm glad the company I work at also dropped IE in new projects and have plans to upgrade older projects too.
However the apps developed for clients are for Chrome
B2B side has been moving slowly off IE11, but moving faster since the start of the year and with most of the rest of the customers targeting to be off of it originally by end of quarter. Currently sitting around 40% but if they go through with their plans to upgrade by end of quarter then will be around 5%
B2C side is much lower, the users who visit not very frequently or are newer that use IE is low single digits. On the other hand we have some long term continuous use users who use IE at a higher rate than the B2B side
Interesting - like what?
The sites range from small mom & pop stores to restaurant chains with dozens of locations worldwide to large scale CRMs for larger corporations. We're all over the place. The sites we host, which often do not include our bigger clients, are doing about 30 million unique visitors each week across them currently. Not a massive amount of traffic by any means, but it's still upwards about 400k users we're dropping support for (in addition to about 500k on older versions we already dropped).
Note: all of my metrics are coming from server access logs. Nothing complex any no front end validation of the browser versions (I don't have access to client-side Analytics for each site)
Around 78% of browsers hitting the site are running IE8, and these will be parents making use of the portal to do stuff like check calendar dates, book appointments to see teachers, and check student grades.
We tried extremely hard to move the community onwards, including outreach to upgrade computers for families and so on. But in the end, they just don't want to move on from Windows XP because everything else is too confusing. Even if you make it look the same.
As for how often they're using the site... It's somewhere around 1/3rd of the parents hit it at least once a day using an outdated browser.
... Whilst their kids are using school-provided Thinkpads all running on Windows 10, or recent-ish school-provided iPads. (The school does all the maintenance on them as well).
Windows xp + IE + elicipse + office 2003 or 2007 I think.
If Google and Mozilla aren't going to step up their "managed browser" game then we're going to continue seeing MS and Apple dominate education. It's not like school IT depts like running IE, but it's basically the only browser you can lock down.
"But you shouldn't lock down kids' browsers, and let them have blah blah..."
Okay look, I don't actually give two shits if little Marcus wants to browse Pornhub on his school laptop, we're honestly not paid enough to care. But we do have administration breathing down our necks, school policies to enforce, and angry detached parents to appease.
It was the parents who refused to move beyond XP.
https://support.mozilla.org/en-US/products/firefox-enterpris...
Still hard for me to believe the figures though. 78%??? Wonder which country they live in.
I've seen things like that here in Mexico but not winxp, and not in 2020. And not to younger parents with kids who can use computers. Maybe they're in China or something where pirated winxp still apparently flourishes.
Most of the parents I dealt with treated technology like it might be infectious, and they didn't want to get sick. Most didn't even have email.
Think... The sort of people who print and mail pictures someone found on the internet, because they never touch email.
They don't actually want to visit any website.
The customer was happy for us to only cover "core functionality" and not visual and minor issues in IE 11.
I think one of the main drivers of IE support is clients who will test in IE because it's their default browser or only allowed browser at work.
Because it's an educational organization, we must assume that members are operating on outdated solutions behind weirdly restrictive firewalls. I don't bother to fully support Internet Explorer for all features, but I do need to make sure the critical path at least functions on a basic level, and I'm careful not to rely on any dependencies (analytics, etc) that I cannot self host.
Of course, it's the directors who insist on doing everything on their iPad that give me more trouble, as I don't actually own one to test. :)
Shouldn't they give you one for testing?
Still too high of a % to ignore.
Gamers tend to be pretty technically inclined, so the audience mostly uses pretty modern browsers.
I support down to ES3 (Safari 5, IE9) mostly because I can (I learned web dev back in the old days and still remember all the tricks), although it's nice to see fans talk about playing on obscure platforms like the Nintendo 3DS browser or a Samsung smart refrigerator.
Animations are implemented in jQuery animations, and the networking is provided by SockJS (which can fall back to JSONP long-polling and even iframes if the browser doesn't support WebSocket).
Already removed some polyfills, biggest win will be transpiling just for modern browsers [1]. This all ties in nicely with general performance initiatives.
[0]: https://gitlab.com/gitlab-org/gitlab/-/issues/197987
[1]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36840
https://twitter.com/wongmjane/status/1291405828843421696
* of the modern browsers.
edit: I'd like to clarify the reason I don't regard Safari as evergreen is it's tied to iOS versions. Enough users still use iOS 12 and 11
A browser with no support for DRM can still be standards compliant too.
Although, some browser teams, like Google Chrome, has apparently the ability of just shoving Google people in the standards process so they can fast-track stuff.
But in the end, it's _supposed_ to work in the fashion where one browser starts implementing something, then others.
I’m complaining about the armies of web developers who seem to think Chrome IS the standard and anything Chrome has that other browsers don’t mean the other browser is ‘The new IE’ and ‘holding the web back’ even if it just came out last week.
Unfortunately, since most web devs develop under Chrome (and rarely if ever test under other browsers) this perpetuates the myth that "Safari is holding the web back" or "Firefox is slow and doesn't implement standards fast enough".
Here's total Web Apis counts in different web browsers: [1]
- Chrome: 7106
- Firefox: 6376
- Safari: 6130
Of them: browser-specific APIs that developers cannot reasonably assume are a part of the web platform:
- Chrome: 949
- Firefox: 507
- Safari: 546
And in 2017-2018 Chrome removed over a thousand APIs that were only implemented in Chrome, but were assumed to be standards" [1]
And if you look at the omissions tab, you'll see that Firefox and Safari and not too far behind Chrome. But they are very wary of implementing quite a few standards just because Chrome fast tracked them (Constructible Stylesheets? Safari flat out refused to implement them. Signed HTTP exchanges? Mozilla considers them harmful and will not implement etc. etc.)
[1] https://web-confluence.appspot.com/#!/confluence
If IE 11 auto-updated to Edge, then it would be considered Evergreen under this definition.
I am not sure how good of an adjective evergreen is in this case, if it is being used how I imagine it is being used.
Fuck the users if they're using anything older, force them to buy new hardware and create more e-waste, because we just want the latest crap regardless. That sums up the sad state of "modern" web development.
There's a lot of repetitive debate on HN about JS web apps slowing things down and I'd like to know if the effects would be as bad if you could use the latest browser tools unpolyfilled.
[1]: https://v8.dev/blog/cost-of-javascript-2019
Feels like you should make that the start of the blog post and cut it down massively, so people know it's not worth bothering with?
This isn't like statistics in a political poll where there is an expected margin or error, when it comes to logging sites you absolutely know everything about your users in regards to browser, operating system, and even the hardware (sometimes).
3% of a million is 30,000, 3% of 500,000,000 is 1,5000,000. An absolutely real chunk of users that can produce real value (for Instagram, ad dollars).
Why would there be a margin error at all? How would it be introduce? A large portion of crawlers masking themselves? I mean it's possible, but I do not know if that's enough to throw off proper logging.
Unless your initial page load is taking like 10 seconds, a human wouldn't even notice. And if it is taking 10 seconds, well, then you've got better things to fix.
That's not an actual improvement. That's just noise.
Imagine you lower the grip on everyone’s tires by 3%. Most people wouldn’t notice, but for a few people it will prevent them from being T-boned when they wait too long to brake for a red light. That improvement would be measurable if your data was good enough. I’m not saying optimizing your website is important like preventing car crashes, but it’s an illustration of how a small change can lead to a measurable improvement.
Hopefully that will be the next step after reducing the bundle size.
Alternatively, for reading only, there is https://nitter.net/
This is code, so after it’s downloaded it needs to be parsed and executed… needlessly.
What are you complaining about exactly?
A couple orders of magnitude are missing from these sizes if my browser dev console is any indication. What are they even talking about.
As far as I remember, Twitter PWA was a React app, and React comes at about 30k minified gzipped.
And hope this change makes it easier to block trends from explore tab. I love topics, but I don’t wanna see all the celebrity and politics crap every day...
The only success I've had is by starting a private list of knowingly healthy users that's aggressively curated to make it stay that way, and never looking at the home timeline.
I use Firefox with uBlock (standard lists) and uMatrix (all Twitter-related requests permitted) and it's still buggy as hell.
If I try to paste anything into the "compose tweet" dialog it just completely crashes with a very helpful "something went wrong" message.
If I try to cut and re-arrange parts of my tweet, it duplicates all the text and puts it out of order.
The tweet box is not even a <textarea>, it's a <div> stuffed full of <span> elements.
Additionally, the tweet box <div> is nested over 40 layers deep in a massive pile of divs.
As always, they're trying to be way too clever for their own good.
I'm not at all surprised they need polyfills for that trash.
ah yes, because webdevs love reimplementing widgets from scratch. that's no a problem in and of itself, but they also implement it half-assed, so you end up with gems like what OP described, or links being implemented as <a href="#"> with an onclick.
Details: https://news.ycombinator.com/item?id=24076601
A <richtextarea> that yielded HTML or even RTF seems like it was an obvious need by time of the end of the Netscape/IE browser wars.
Come to think of it, I was basically hired to do that one thing because the existing team was struggling with it and it was blocking a launch.
I've had these issues nonstop for the past year.
Also Twitter is such an incredible product. I love it. It's one of the few curate-by-default (along with Instagram, another masterpiece) feeds one can have. If your feed sucks, only you are to blame. Beautiful.
Every reduction is good in my view.
[1]:https://imgur.com/a/01LfeiW
14KB is nothing when you're shipping 1MB+ of JS and all the other assets.