5 ms·

Sometimes I don't understand this argument because theres nobody forcing you to always be on the latest version of a framework. You could have just stayed on th

Sometimes I don't understand this argument because theres nobody forcing you to always be on the latest version of a framework. You could have just stayed on the version of Vue you were using without issues. Unless theres some compelling reason you could use it into the end of time and be just fine. Thats not to say that maybe for your use case you could have not used it in the first place or that removing the dependency was a bad idea - just that if you do like Vue there doesn't seem to be anything forcing you to always be on the latest version.

WD-42 2y ago
What happens when old versions stop receiving security updates?
- Jcampuzano2 2y ago
  Rarely do security issues come from directly as a result of your choice of frontend/client framework which should really only be in charge of displaying your data. Almost all issues should be handled by your backend. Most cases where it becomes an issue is when people drop security best practices falsely believing their frontend/client validation is a security layer. Anybody thinking updating your frontend solves your security issues has deeper problems.
  - WD-42 2y ago
    > Rarely do security issues come from directly as a result of your choice of frontend/client framework Front end client frameworks now span the backend. Nextjs is the prime example. It has plenty of CVEs already.
    - Jcampuzano2 2y ago
      Well next is not a frontend framework and doesn't claim to be. Its very clearly a full stack framework. Vue by itself isn't.
      - regularfry 2y ago
        Can you server-side render Vue? If you answer "yes" then it has exactly the same type of back-end security concerns that Next has by way of it rendering React.
  - wavemode 2y ago
    Doesn't matter, a security update is a security update. So, especially when you work in a larger company, you end up having strict compliance requirements to keep things up to date. I'm as annoyed by it as the next guy. The supposed vulnerabilities are almost never actually relevant for frontend code, and rather assume that you are running Node as a web server. It's just one of those weird things that has resulted from how the JavaScript ecosystem has centralized around using node for everything (i.e. building frontend code as well as executing backend code - even though the two have kind of nothing to do with each other.)
    - jamesfinlayson 2y ago
      Yep, I've been in a big company with a dedicated security team and it was easier to just patch the dependency than to try and argue that we weren't vulnerable (otherwise it would probably go on some risk register and be re-raised again in a few months time).
  - zelphirkalt 2y ago
    About having other problems, I think you are right. However, often it is the frontend engineers pushing for using more frontend frameworks on the server side as well, and then implementing business logic there, not merely presentation, using arguments like "then we can have a mono repo for all the things and have type checks for frontend and backend" or "all in on language!" and suddenly you got into that situation.
- deleted 2y ago
  [deleted]
- ImHereToVote 2y ago
  May God have mercy on your soul if you rely on your frontend for security. You might as well duct tape a shotgun to your scull.
- pilif 2y ago
  And not just that - also dependencies of dependencies. You have $FRAMEWORK using $BUILD_SYSTEM and depending on $NODE_VERSION which is running on $OS_VERSION in $ARCHITECTURE. Eventually, there will be a security flaw in $OS_VERSION which will force you do update the OS (which eventually will be a major OS update) and on which $NODE_VERSION might not run any more at which point you find out that $BUILD_SYSTEM doesn't run on newer node any more because it relied on a package that shipped some binary do do its thing and the source code of that binary doesn't compile on later GCC versions any more. And now you're in deep-shit because of a very distant but yet super important security issue that brought your house of cards crumbling down. This is not a theoretical issue either. I've seen this happen to applications with a JS frontend that was only as little as 5 years old. It was impossible to build any more and needed some serious changes because of underlying OS updates cascading up the stack. The fewer dependencies you have and the smaller they are, the bigger is the chance that things keep running as you exchange parts of your stack when you're forced to and the bigger the chance that you will remember what you have to do to rebuild if disaster strikes. I'm aware that for many people 5 years is a huge time span though and that you either start a new thing every year or two at which point none of this matters, or you're at the other extreme and run RHEL and are able to back-port security patches manually if the need arises at which point none of this matters either. But if you're in the middle of the two extremes, then keeping up to date incrementally is super important and being able to do that quickly and easily is inversely proportional to the amount and size of dependencies.
  - zelphirkalt 2y ago
    One frequent situation is, that companies are not aware of how bad this can get and their frontend devs have a resume/hype driven thing going on, building it in the new tool, leaving after a few years for greener pastures, leaving behing a ticking time bomb for someone else to deal with. Not so many people stay at the same job 5y+ these days. Companies don't know how to keep their talent and engineers are forces to switch jobs every now and then to keep or improve their salaries.
Joeri 2y ago
A particular framework version usually depends on a particular version of build tools, and those are written to a particular release of an OS. When apple updates Xcode the compiled npm packages often have to update support as well, and the old versions of those packages start breaking on new OS releases. You can’t ship a web app that you can’t build. An often used hack is containerizing the dev setup to decouple from OS versions, but that comes with its own set of downsides.

WD-42 2y ago

What happens when old versions stop receiving security updates?

Jcampuzano2 2y ago
Rarely do security issues come from directly as a result of your choice of frontend/client framework which should really only be in charge of displaying your data. Almost all issues should be handled by your backend. Most cases where it becomes an issue is when people drop security best practices falsely believing their frontend/client validation is a security layer. Anybody thinking updating your frontend solves your security issues has deeper problems.
- WD-42 2y ago
  > Rarely do security issues come from directly as a result of your choice of frontend/client framework Front end client frameworks now span the backend. Nextjs is the prime example. It has plenty of CVEs already.
  - Jcampuzano2 2y ago
    Well next is not a frontend framework and doesn't claim to be. Its very clearly a full stack framework. Vue by itself isn't.
    - regularfry 2y ago
      Can you server-side render Vue? If you answer "yes" then it has exactly the same type of back-end security concerns that Next has by way of it rendering React.
- wavemode 2y ago
  Doesn't matter, a security update is a security update. So, especially when you work in a larger company, you end up having strict compliance requirements to keep things up to date. I'm as annoyed by it as the next guy. The supposed vulnerabilities are almost never actually relevant for frontend code, and rather assume that you are running Node as a web server. It's just one of those weird things that has resulted from how the JavaScript ecosystem has centralized around using node for everything (i.e. building frontend code as well as executing backend code - even though the two have kind of nothing to do with each other.)
  - jamesfinlayson 2y ago
    Yep, I've been in a big company with a dedicated security team and it was easier to just patch the dependency than to try and argue that we weren't vulnerable (otherwise it would probably go on some risk register and be re-raised again in a few months time).
- zelphirkalt 2y ago
  About having other problems, I think you are right. However, often it is the frontend engineers pushing for using more frontend frameworks on the server side as well, and then implementing business logic there, not merely presentation, using arguments like "then we can have a mono repo for all the things and have type checks for frontend and backend" or "all in on language!" and suddenly you got into that situation.
deleted 2y ago
[deleted]
ImHereToVote 2y ago
May God have mercy on your soul if you rely on your frontend for security. You might as well duct tape a shotgun to your scull.
pilif 2y ago
And not just that - also dependencies of dependencies. You have $FRAMEWORK using $BUILD_SYSTEM and depending on $NODE_VERSION which is running on $OS_VERSION in $ARCHITECTURE. Eventually, there will be a security flaw in $OS_VERSION which will force you do update the OS (which eventually will be a major OS update) and on which $NODE_VERSION might not run any more at which point you find out that $BUILD_SYSTEM doesn't run on newer node any more because it relied on a package that shipped some binary do do its thing and the source code of that binary doesn't compile on later GCC versions any more. And now you're in deep-shit because of a very distant but yet super important security issue that brought your house of cards crumbling down. This is not a theoretical issue either. I've seen this happen to applications with a JS frontend that was only as little as 5 years old. It was impossible to build any more and needed some serious changes because of underlying OS updates cascading up the stack. The fewer dependencies you have and the smaller they are, the bigger is the chance that things keep running as you exchange parts of your stack when you're forced to and the bigger the chance that you will remember what you have to do to rebuild if disaster strikes. I'm aware that for many people 5 years is a huge time span though and that you either start a new thing every year or two at which point none of this matters, or you're at the other extreme and run RHEL and are able to back-port security patches manually if the need arises at which point none of this matters either. But if you're in the middle of the two extremes, then keeping up to date incrementally is super important and being able to do that quickly and easily is inversely proportional to the amount and size of dependencies.
- zelphirkalt 2y ago
  One frequent situation is, that companies are not aware of how bad this can get and their frontend devs have a resume/hype driven thing going on, building it in the new tool, leaving after a few years for greener pastures, leaving behing a ticking time bomb for someone else to deal with. Not so many people stay at the same job 5y+ these days. Companies don't know how to keep their talent and engineers are forces to switch jobs every now and then to keep or improve their salaries.

Joeri 2y ago

A particular framework version usually depends on a particular version of build tools, and those are written to a particular release of an OS. When apple updates Xcode the compiled npm packages often have to update support as well, and the old versions of those packages start breaking on new OS releases. You can’t ship a web app that you can’t build. An often used hack is containerizing the dev setup to decouple from OS versions, but that comes with its own set of downsides.