5 ms·
I think JS (well, ES6) has a ton of positive qualities, and I think it's a great fit for many of its current applications. However, this is a pretty good exampl
by chefandy 2y ago
I think JS (well, ES6) has a ton of positive qualities, and I think it's a great fit for many of its current applications. However, this is a pretty good example of what bothers me about the way many people use it. I see a lot of folks, in the name of pragmatism, adopt a ton of existing libraries and services so they don't have to think about more complex parts of the problem they're solving. Great! No need to reinvent the wheel. But, people also seem to falsely equate popularity with stability-- if there's a ton of people using it, SURELY someone has vetted it, and is keeping a close eye on it, no? Well, maybe no? It just seems that the bar for what people consider 'infrastructure' is simply too low. While I don't think that, alone, is SO different from other popular interpreted languages, the light weight of JS environments means you need to incorporate a LOT of that stuff to get functionality that might otherwise be part of a standard library or ubiquitous stalwart framework, which dramatically increases the exposure to events like this.
I think a lot of people conflate criticism of JS with criticism of the way it's been used for the past number of years, putting a nuanced topic into a black-and-white "for or against" sort of discussion. I've done a number of projects heavily using JS-- vanilla, with modern frameworks, server-side and in the browser-- and aside from some fundamental annoyances with it's approach to a few things, it's been a great tool. There's nothing fundamental about JS itself that makes applications vulnerable to this like a buffer overflow would, but the way it is used right now seems to make it a lot easier for inexperienced, under-resourced, or even just distracted developers to open up big holes using generally accepted techniques.
But I've never been a full-time front-end-web or node dev, so maybe I'm mistaken? Compared to the server-side stuff I've worked with, there's definitely a concerning wild west vibe moving into modern JS environments. I think there was a casual "well, it's all in client-side userspace" attitude about the way it was used before which effectively shifted most of the security concerns to the browser. We should probably push a little harder to shake that. Think about how much JS your bank uses in their website? I'll bet they didn't write all of their own interaction libraries.
- sandwitches 2y agoThis is the end-stage of having third-party packaging systems without maintainers. This happens vanishingly infrequently for things like apt repositories, because the people maintaining packages are not necessarily the people writing them, and there's a bit of a barrier to entry. Who knew yanking random code from random domains and executing it was a bad idea? Oh yeah, everyone.
- dr_kiszonka 2y agoI wonder if anyone would be willing to pay for a service that vets and hosts (a very small subset) of popular JS libraries.
- chefandy 2y agoMaybe! Add in package management that isn't a complete clusterfustrum and that could be pretty attractive. Cloudron basically does something similar with FOSS server apps.
- bob1029 2y agoI have been full stack for the last decade. Vanilla JS and server-side rendering is about all I can tolerate these days. I will reach for Ajax or websockets if needed, but 90%+ of all interactions I've ever had to deal with are aptly handled with a multipart form post. I do vendor my JS, but only for things like PDF processing, 3D graphics, and barcode scanning. I've been through the framework gauntlet. Angular, RiotJS, React, Blazor, AspNetCore MVC, you name it. There was a time where I really needed some kind of structure to get conceptually bootstrapped. After a while, these things begin to get in the way. Why can't I have the framework exactly my way? Just give me the goddamn HttpContext and get off my lawn. I don't need a babysitter to explain to me how to interpolate my business into an html document string anymore. I also now understand why a lot of shops insist on separation between frontend and backend. It seems to me that you have to be willing to dedicate much of your conscious existence to honing your skills if you want to be a competent full stack developer. It can't just be your 9-5 job unless you are already highly experienced and have a set of proven patterns to work with. Getting someone off the street to that level can be incredibly expensive and risky. Once you know how to do the whole thing, you could just quit and build for yourself.
- fragmede 2y agoBuild what? Sell to whom? What, write my own subscription/billing module, on top of full stack development which, as you said, takes a lot of time just to be competent at. on top of building it, do sales and marketing and accounting and all that other business stuff? I mean, I guess
- deleted 2y ago[deleted]
- treflop 2y agoI remember Google suggesting that everyone use common libraries hosted by a shared CDN and then suggesting de-ranking slow websites and I think that’s what led to widespread adoption of this pattern. The only reason I stopped using third-party hosted libraries was because it wasn’t worth the trouble. Using subresource integrity makes it safe but it was part of the trouble.
- chefandy 2y agoSure... Though while I hate to say it, I don't blame people for trusting Google's hosted copy of something. For better or worse, they are more trustworthy than some "as seen on a million janky tutorials" whatever.io. A very privacy-focused employer precluded that possibility during peak adoption, but with what many sites load up, that's the least of your worries.
- treflop 2y agoNo problem with Google hosting it (although I’d still use sub-resource integrity) but anyone else?
- chefandy 2y agoAmusing: https://news.ycombinator.com/item?id=10143620 https://news.ycombinator.com/item?id=10143620 The original author probably should have done everyone a favor and just killed the site altogether.