Comment by rhapsodic | Hacker News Reader

Comment by rhapsodic | Hacker News Reader

Parent Full thread

>If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors.

I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here.

jQuery is library that provides DOM shorthand - it isn’t a true application framework.

Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the technical debt one incurs with them. (At least not to me. I'm not telling anyone what they should think or that they should design their applications like I do.)

My approach for me and the developers on my team is to develop a deep level of understanding of HTML, CSS and JS. Once you have that, the prospect of doing things for yourself that frameworks would otherwise provide does not seem all that daunting. To me, frameworks like React, Angular, etc. don't reduce complexity, they increase it.

And I hasten to note that I realize that many bright, capable people hold a different view , and I'm not saying they're wrong.

Something like React isn't even an application framework, though, it's a view library of compositional functions feeding into a tree diff.

How does functional, side-effect-free code increase complexity? What makes your side-effecting code more testable and verifiable than unambiguous in/out functional transforms?

Personally for me it's a trade off and it does increase complexity.

With jQuery and such you just include a script and back then there were no package management system, glup/grunt, webpack, yeoman/brunch, etc..

Also the client side rendering make SEO hard.

jQuery just get stuff done but at the same time the organization of your code is up to you and you do sacrifice some reusability but in general the trade off is complexity.

VueJS as much as I love learning this framework, it is complex with webpack, cli, browser plugin, and etc...

You realise there are SSR setups for React, and even better, isomorphic setups like Next.js?

So I'm gonna be honest: I don't have much time or patience for "but webpack is complex" complaints. Webpack is complex, sure. It has many moving parts. It is not complicated, and that means its complexity is more or less "remember a few nouns". Each of the parts those nouns encapsulate is simple and obvious with straightforward inputs and outputs. The interactions may not always be so straightforward--but, in practice, they are. I am comfortable asserting that you shouldn't be surprised by anything webpack or gulp or whatever does. If you are, you haven't internalized what you're working on to a sufficient degree. Because it is just. not. that. big. a. deal.

"Just get things done" when the way you're doing so is less clear, less testable, and less reliable is not, to me, the hallmark of a developer I would trust with anything I cared about.

I've heard about webpack and build tools a ton and I don't understand the issue.

If your project is simple, webpack setup is copy/paste (v3) or no config at all (v4). If your project is doing complex stuff, webpack is more in-depth, but a breeze compared to the make files and XML config of other languages. More importantly, webpack has a very clear tutorial and extensive documentation. You have to go incredibly far off the normal path to run into something that isn't covered. Off topic, but augmenting webpack dev server express instance made dev work many times easier on my current project.

Reply on news.ycombinator.com