Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Most of JS tooling stems from 1. different browsers

Do people struggle a lot with cross-browser issues these days? It isn't like it was back in the day, when basic stuff like the box model worked wildly differently in IE. And almost everyone's on a rolling-release, auto-updated browser, so you don't have to worry about testing on old versions; even big websites like Stack Overflow only support the last couple releases of the most popular browsers: https://meta.stackexchange.com/questions/56161/which-browser...

I still test on multiple browsers, and every once in a while I'll need to fix a bug that only shows up in one browser. But JavaScript frameworks and build tooling don't really help with that, do they? (Am I missing out?)



Yes. If you're a front-end developer at some capacity, developing anything of use for > 0 users, you'll have hell of a lot of browser compatibility issues.

People will browse your app from ancient mobile phones. Weird smart TVs. play consoles. Chinese browsers you've never heard of but come bundled with some we-something, they will browse your app from PoS, from a DJI smart RC, from a fridge. And from IE6.

And you know what's the best way to mitigate all that mental load? You just start upfront with a framework that was already battle-tested on all these weird browsers.


What framework do you recommend for wide browser support? React certainly doesn't claim to support anything like feature-phones or IE 6; the lowest they go is IE 9, and that's only if you load additional polyfills: https://reactjs.org/docs/react-dom.html#browser-support


Oh you'd be surprised.

Safari never fails to make you question why, and Firefox and Chrome still have enough differences to catch you off-guard from time to time.


A lot of features are still wildly different between browsers. SVG being one particular pain point for me. And Safari is the browser that I have the most issues with recently.


It's not about struggling so much as about avoiding a situation where one small problem makes a site either look visually 'broken' or (worse) fail to function correctly.

There are way too many small bugs and incompatibilities like these, and way, way too many browser versions still seeing use by at least a small percentage of users, to worry about them individually, unless you want that to eat up all your time.

So your choice is between "be okay with a broken experience for some users", or "use build tools to compile to a common-ancestor target of near-universally-supported CSS and JS".


What build tools do you use that ensure your site works consistently across different browser versions without needing any browser-version-specific testing/fixes on your part?

I've worked on web pages that use what seems to be a pretty standard Webpack/Babel/PostCSS/etc setup, and they still ran into some issues where layout or behavior was different between browsers. Either because they used a CSS property value or JavaScript API (or API parameter/option) that wasn't available everywhere, or because of more subtle disagreements between browsers about things like where an inline element's containing block is.


You're right, it's not possible to eliminate the need for testing/fixes. I didn't say it was. It's a tradeoff; compiling to a stable older set of features reduces bugs but doesn't eliminate them.

Part of the work has to be on the developer. There are certain properties that will screw up positioning when used with flex elements in IE, for example, and knowing what those are and how to avoid those combinations is part of the cost of skillfully using flexbox. The compiler can't always do the work, but we should let it do as much as it can.


No idea why you're getting downvoted. I'm wondering the same thing. I've even stopped prefixing anything and haven't seen any issues in any browser.


two points

1. the most of JS tooling stemming from browser compatibility issues does not mean that the issues still need to exist at the point that the tooling was established - it can take a while for established stuff to be moved out.

2. I think for most sites it isn't a problem, but for me the last 3 years has been work on big SPAs that need to generally also handle IE9 (degrade gracefully). And there is always stuff going on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: