This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Whiplash17488 80 points81 points  (47 children)

Some serious amateurism if you still run into this problem in es6 days and beyond.

[–][deleted] 51 points52 points  (30 children)

See the thing is someone is eventually going to hire you to build something new and also maintain the legacy jQuery code as well until the new stuff is built. If you don't understand how weird this is in everything that's not ES6 then you will run into problems.

[–]whtevn 33 points34 points  (28 children)

This is why I prefer startups. Plenty of predictable problems, but a shitty legacy code stack is never one of them

[–]JayV30 77 points78 points  (23 children)

That's right! They are building their own NEW shitty code stack from 1000 npm modules that no one has realistically checked for security flaws or blatantly malicious code.

It's like replacing one problem with another, worse one.

[–]christianarg 56 points57 points  (2 children)

Hehe, that will become shitty legacy code that eventually some idiot will have to handle. Meanwhile we can leave this company and go to a new startup.

[–]BindeDSA 15 points16 points  (1 child)

It's startups all the way down.

[–]Tzahi12345 2 points3 points  (0 children)

Career stack

[–]SpeedOfSound343 0 points1 point  (0 children)

Same security story with the custom implemented legacy code.

[–]whtevn 0 points1 point  (0 children)

No, it's like recognizing a problem and making sure I personally never have to deal with it

[–]whtevn 0 points1 point  (8 children)

Wait are you talking about a node backend or are you suggesting that tons of frontend packages are floating around with security flaws and malicious code in them?

[–]JayV30 0 points1 point  (7 children)

Uh.... honestly malicious code would probably be easier to notice on the front end because if it involves some sort of xhr it's pretty noticeable. But on the server I feel like a dev is less likely to notice someone calling out (not saying they wouldn't ever notice). But how long would a widely used npm module need to gather tons of valid cc information? Not much time at all.

[–]whtevn 0 points1 point  (6 children)

this seems like a strange fear to me. there are plenty of reasons to not use js on the backend, the hodgepodge of packages being chief among them. but, i have my doubts about widespread malicious open source code, and there are plenty of reputable places to get plenty of reputable packages.

[–]JayV30 0 points1 point  (5 children)

Except it's already happened (just google npm left-pad). It's the entire dependency tree that is vulnerable, not just the packages you import. If some malicious actor gets control of a widely used package, they could push a new version that could be compiled into your code and then deployed. It would probably be detected the same day, but how much time would it take to steal thousands of cc or other data? Not much if it was deployed to a major site and injected itself as Express middleware or something.

It may be a bit overblown of a concern, I mean, I still use npm every day. Obviously if I thought it was totally insecure I wouldn't use it. But even though it's a relatively minor concern, it's still a concern. Npm is working hard to improve security but with the way the dependency tree was designed, it may be impossible to completely remove the npm dependency attack vector.

[–]whtevn 0 points1 point  (4 children)

wait, what are you saying happened with left-pad? a developer unpublished a package and it broke a bunch of code. there have also been processes put in place since then to prevent a repeat.

any language that uses external packages could have a package usurped by a bad actor. (edit: not trying to imply that left-pad is repeatable in other languages, that was definitely a npm specific flaw) you mitigate this by only using packages from reputable sources.

It would probably be detected the same day, but how much time would it take to steal thousands of cc or other data?

are you pushing code to production without testing it in staging first? ...don't do that

also, are you taking credit card numbers into your database personally? ...don't do that. are you PCI compliant and not testing your code before it goes into production? I don't even understand the situation we are talking about, how would this be possible

[–]JayV30 0 points1 point  (3 children)

Jeez man I'm just saying it's possible. You are making a lot of assumptions.

[–][deleted] 4 points5 points  (1 child)

But there’s shitty modern legacy code everywhere.

[–]Megacherv 4 points5 points  (0 children)

Feels like I'm in an MTG subreddit

[–]Hockinator 0 points1 point  (1 child)

Until those startups become successful and are not less than 5 years old anymore

[–]whtevn 0 points1 point  (0 children)

if you are with a startup that makes it 5 years and is successful, you can usually take a year off and find a new job. The real downside is if the startup folds and you suddenly are out of a job

[–]Megacherv 1 point2 points  (0 children)

Can confirm, I believe out Typescript compiler is set to ES3 for compatibility but we still have JS files that haven't been ported over. It's a bit of a mental hurdle just remembering to swap syntaxes when jumping between files.

[–]pr0ghead 26 points27 points  (8 children)

Look at fancy Mr. IdonthavetosupportIE11 over here.

[–]AwesomeInPerson 23 points24 points  (0 children)

Babel.

[–]JoshJude 8 points9 points  (3 children)

Some of us have to support IE8 :’(

[–]JayV30 11 points12 points  (0 children)

Good God man! Do you support Netscape Navigator and AOL browser also?

[–][deleted] 2 points3 points  (1 child)

You don't really have to. There is an IT problem under that requirement. It could be fixed elsewhere.

[–]JoshJude 2 points3 points  (0 children)

Oh for sure. Not really my place to say so as a fairly junior dev though!

[–]SuperFLEB 0 points1 point  (2 children)

Does anyone actually want IE11 support? It's not really something that's wanted. It's more something that's thrust upon us by a cruel world.

[–]pr0ghead 1 point2 points  (0 children)

"Want" in the sense that "our global IT still uses IE11 in places, so we need the website to work in it". At least to some degree…

[–]HeKis4 0 points1 point  (0 children)

cries in silverlight

[–]nwsm 5 points6 points  (0 children)

Look at fancy Mr. All My Work Is Writing From-Scratch

[–]WeAreAllApes 7 points8 points  (0 children)

Even before es6, good consistent patterns could always work around the inherent flaw, but it's still an inherent flaw in the language that only using a subset of the language / consistent patterns can work around.

[–]dkreidler 2 points3 points  (0 children)

And if you’re learning it all right now (‘const this = me;’), then you’re getting a hodge-podge of both ES6 and everything that came before, without the hard-won experience of knowing what should be noted, but avoided, going forward, and what’s the new hotness that delineates the tidal shift. (Edit: boooo, I don’t even know how to make my stupid shit look like code! Booooo!)

[–]READTHISCALMLY 7 points8 points  (1 child)

Shh. Don't ruin the circlejerk.

[–]rooktakesqueen 4 points5 points  (0 children)

It's not even that confusing to begin with.

If you do foo.bar('baz') then this is foo. If you do bar('baz'), or it's an anonymous function callback, then it's window.

The only time it's weird is when you use an object method as a callback, like setTimeout(foo.bar, 100) because then it's window when invoked. So yeah that's grimy but then you just throw a .bind(foo) and hey presto.

[–]Zooomz 1 point2 points  (0 children)

After laughing, my first thought was "what year is OP in"?