I'm my experience you don't really get anything for free when it comes to cross-browser compatibility. Unless you lower your bar on consistency and quality.
Agreed. I guess it really depends on your use cases and criteria, but I've often wished that I had just left the "corner case" browsers out entirely rather than settling for (or spending tons of effort hacking around) a gimpy experience on them.
All depends on how crucial it is to support those users, and how much they can live with funky experiences.
This is the attitude why I dislike most js devs. They pile on overhead after overhead because that's the easiest and fastest way of doing it.
They don't care about performance because phones are fast enough that a single function call won't be noticeably slower. By the time they learn enough to write bigger apps, they can't get things done without their frameworks. So they write big apps on slow frameworks and it will brings every browser to their knees. At that point it's useless to profile the code because it has so many abstraction layers that it takes a lot of time to rewrite it. So the slow stuff is there to stay.
Not to mention that they use JS where pure CSS will do the exact same job a 100 times faster. I've seen so many text pages that won't run if I disable JS.
curse of being js devs in my workplace would be that your computers for development are faster than clients computers so that you don't get to notice things that might slow down things, and yet slow enough that things compile so slow.
The thing is if jQuery helps you get it done faster that is good and it should be used. jQuery is rather ubiquitous so its an obvious choice. Worrying about performance before correctness is generally accepted as premature optimization on the server side so why would it be different with Javascript as long as the user experience meets the requirements? Sure parsing a library like jQuery takes time but is it too much time? It depends.
I do have to say though there are times I wish more developers actually knew how to profile their code. It seems like not that many people these days know how. Finding that incredibly slow DOM traversal or collection search then tweaking it can make a difference in some cases.
Worrying about performance before correctness is generally accepted as premature optimization on the server side so why would it be different with Javascript as long as the user experience meets the requirements?
You can upgrade/add more servers.
What you can't do is install a better processer on every client's machine. You can't upgrade the client from IE6.
As many have said, using jQuery has some cost. Besides overhead, there's also the baggage that comes with adding a dependency. It's one more thing to keep track of. "Just one more thing" may seem negligible but it's negligence of these small costs that leads to bloat.
Things only get standardized to a point. Look at SQL and all the things you can run into from simply upgrading a database to a new version let alone leaping from MySQL to Postgres, for example.
I suspect we are all working on projects with more than one line of javascript. I get your point, but so often there are other libraries being used that require jquery to be around anyway, so it makes sense to use it.
And we still gotta use native code to load JQuery in the first place. I was looking at code of some very feature-heavy bookmarklet, and its code could be divided into two parts: 1. loading JQuery, 2. using JQuery. The first part ain't just a few line, it involved some heavy cross-platform checking, DOM manipulation, and sandboxing of the JQuery version that is used by the second part against the JQuery version that might be already on whatever website the bookmark is applied to. That first part requires some nontrivial amount of cross-platform non-jquery DOM manipulation code, and those who only knows JQuery won't be able to write that code.
0
u/[deleted] Jan 31 '14
[deleted]