If you stay on the same version of the init script, you're still marginally better than rolling your own.
On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster.
We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress.
My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
Change happens.
"Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack.
But without any disagreement:
the churn is real.
Not upgrading is only an option if you
1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option.
2) don't need new packages to change your build setup that are significantly newer than your previous setup.
To repeat, I don't disagree and I prefer the spirit of your comment to my critique.
Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it.
Update costs can also vary a lot depending on the project.
In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions.
If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite).
This rings very true for me, bravo:
> My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
> Change happens.
> "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
ttfkam|2 years ago
If you stay on the same version of the init script, you're still marginally better than rolling your own.
On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster.
We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress.
My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
Change happens.
"Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
moritzwarhier|2 years ago
Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack.
But without any disagreement: the churn is real.
Not upgrading is only an option if you
1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option. 2) don't need new packages to change your build setup that are significantly newer than your previous setup.
To repeat, I don't disagree and I prefer the spirit of your comment to my critique.
Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it.
Update costs can also vary a lot depending on the project.
In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions.
If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite).
This rings very true for me, bravo:
> My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
> Change happens.
> "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"