Feed
Still a very great article, as a French student I was wondering about Vanilla JavaScript vs jQuery... VanillaJS is sometime harder to learn and write but im kind of crazy about optimization and VanillaJS should be the way to go before to get lazy as many developers. And right now more than 50% of website are viewed on mobile, jQuery was clearly not made for it.
If only wannabe Architects would read this!... I always push for Vanilla JS and always end up in a mess of React or Angular that is completely un-maintainable once it is scaled.
The explosion in JS frameworks over the past few years actually makes me feel a bit sad. I see more job adverts that require developers know all sorts of random skills (I saw one the other day that listed 42 separate skills). In spite of this, I see a great lack of websites that actually use any of this tech. The sites I have found using it have all been appalling in terms of optimisation, accessibility, and progressive enhancement, and I have to wonder if 'vanilla' developers are losing out to developers who use all of these new frameworks to produce more bloated, slower, less accessible sites for their clients.
This is the First long article, I read top to bottom in one go in my lifetime, very clear and helpful, Marco you are really great....
Thanks
Very interesting article. thanks Marco...
Two words ... cruel true. This article was very interesting to read, I agree with most of things you said, from the perspective of somebody who has that problem.
Great article, thanks a lot.
Where did you find your header image? :-) Somewhere where I can find a bunch of those? I like this art.
That's some nice, much needed article! Thanks for your time to write it up.
I believe in re-using code, and thus, less LoC. In fact, for the same autocomplete solution, year ago, I took some plugin, stripped all unwanted stuff and made it much better and faster, also to suit my needs. But again, starting from scratch would have set me back by another couple of weeks and going by that route, I actually saved those 2 weeks.
But as a matter of fact, while stripping down the code, I get to learn a lot of new ways to use Vanilla JS and that was a big deal, and that opened up my eyes. Now, whenever I stuck with little hurdles, I try to solve them myself before I start looking for 2rd party plugins. And this for me, is great!
Very correct take on the JS landscape - thanks.
I began with vanilla JS before there were any "popular" libraries or frameworks, i.e., 1999. As a result, I became a JS guru in order to accomplish the neat-o-nifty stuff that people think of as standard today. With experience in both Functional Programming and OOP languages, I could optimize "the weight' of my JS solutions. When I later worked in shops that had already adopted libraries, I was usually the only one who could debug the craptastic code produced by developers who relied on JS libraries without a solid foundation in vanilla JS.
Too many companies have "drunk the Kool-Aid" about reduced development time and shared understanding as motives to employ libraries (or frameworks). This foolishness is not restricted to JS - it is entirely general to all language environments. I see sloppy programming practices, ignorance of DOM and JS (and just plain, old programming) principles, and laziness as the primary "benefits" of using JS libraries. Too often, these "benefits" come at an additional cost of bloated bandwidth, e.g., using 1% of jQuery's functionality to avoid writing a 10-line function in vanilla JS. If your shop uses a library to solve problems the developers can't solve with vanilla JS, you likely retard your programmers' professional competence and are constantly at risk for catastrophe.
The developers' time is entirely the most expensive part of the IT pie. Reducing those costs is a perfectly laudable goal. Libraries MAY reduce that expense during development (if ever). Long term, during evolution and maintenance phases, where the main expense happens in an app's lifecycle, not so much. However, project managers want FAST development and usually have no direct responsibility for later support costs.
That said, try getting a job with ONLY vanilla JS. Without a raft of library (and frameworks) to list as elements of your toolkit, your chances of finding work are slim. Managers, human resource agents, and recruiters are usually gullible ignoramuses when it comes to hype about "new-&-improved" software tools.
Again - thanks for the very accurate article.