I’m deliberately using the past tense there.
My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.
#Multibrowser websafer code
Write code once, run it in any browser - confidently. Browser enemy library friend.įor example: jQuery did wonders to normalize working across browsers. Years of fighting browser deficiencies where libraries filled the gaps. We distrust the browser because we’ve been trained to. Jim Nielsen responds with the same message in his post Trusting Browsers: So again, it’s browser incompatibilities that made libraries attractive. Things are looking good in 2022 but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.īrowser compatibility is one of the underlying promises that libraries-especially the big ones that Jeremy references, like React and Bootstrap-make to developers. I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. That’s a library success story!Ĭharles Harries takes on my question in his post Libraries over browser features: But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. jQuery was created to smooth over cross-browser JavaScript problems. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. I can’t speak for the industry, but I have a guess. I would love it if someone could explain why they avoid native browser features but use third-party code.
I’ve already had some thoughtful responses to yesterday’s post about trust.
0 kommentar(er)
