4 ms·

This is how I feel about front end frameworks. I understand the benefits for large projects, although I still wouldn't want to do that work myself. I have some

This is how I feel about front end frameworks. I understand the benefits for large projects, although I still wouldn't want to do that work myself. I have some small personal projects in vanilla JS, and they're a few hundred lines in 3-4 files. They will continue to function for the foreseeable future, with zero build process, no node_modules directory full of tens of thousands of garbage files, no transpiler or bundler version issues, and almost no overhead in understanding the code, even for a bug fix 5 years down the line. But, I still get funny looks if I tell my front-end friends all this. Sometimes I feel a little crazy.

deleted 7y ago
[deleted]
lazyjeff 7y ago
I'd love to get other peoples' thoughts on this, but I think we're at a tipping point back to vanilla html/css/js. There used to be a huge need to jquery, bootstrap, polyfills, and other tricks, but many of those features are now available in the built-in languages. If you ignore IE, then you can make elaborate websites just by writing it by hand, doing some plain css grid, svg, html5, etc. How much time is spent resolving npm dependencies and packaging scripts for simple libraries that used to just be adding a .js file to your repo? Obviously, web applications (that do more than show some content) will need more infrastructure, but I feel like we can safely stick with mostly vanilla languages for web pages that is content-focused. Let's go back to the days where you could learn a lot from View Source, and version control was dead simple.
- bleuarff 7y ago
  Dropping IE support is a luxury not everyone can afford. So you either write code like it's 2014, or you use modern js features and have to transpile your code. That may add some overhead, but I'm much happier using async/await and babel.
- marcus_holmes 7y ago
  I tried writing an interactive UI in vanilla, because I'm a huge fan of less is more. But I had to switch to Vue in the end. As the complexities of managing state mounted, it just got too difficult to handle without effectively writing a custom version of Vue/React to manage it. But I have just imported the Vue code as a script file - no node modules folder ;) Though without Webpack I can't do single-file components properly, which sucks.

deleted 7y ago

[deleted]

lazyjeff 7y ago

I'd love to get other peoples' thoughts on this, but I think we're at a tipping point back to vanilla html/css/js. There used to be a huge need to jquery, bootstrap, polyfills, and other tricks, but many of those features are now available in the built-in languages. If you ignore IE, then you can make elaborate websites just by writing it by hand, doing some plain css grid, svg, html5, etc. How much time is spent resolving npm dependencies and packaging scripts for simple libraries that used to just be adding a .js file to your repo? Obviously, web applications (that do more than show some content) will need more infrastructure, but I feel like we can safely stick with mostly vanilla languages for web pages that is content-focused. Let's go back to the days where you could learn a lot from View Source, and version control was dead simple.

bleuarff 7y ago
Dropping IE support is a luxury not everyone can afford. So you either write code like it's 2014, or you use modern js features and have to transpile your code. That may add some overhead, but I'm much happier using async/await and babel.
marcus_holmes 7y ago
I tried writing an interactive UI in vanilla, because I'm a huge fan of less is more. But I had to switch to Vue in the end. As the complexities of managing state mounted, it just got too difficult to handle without effectively writing a custom version of Vue/React to manage it. But I have just imported the Vue code as a script file - no node modules folder ;) Though without Webpack I can't do single-file components properly, which sucks.