> Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue.
This makes me feel conflicted.
With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech.
With JS libraries it's the wild west once again and before you know it, your components will need 3 different mechanisms of being initialized, their internals will use different approaches, before long you'll have multiple versions of jQuery in there as well and it'll make you consider the downsides of that approach.
But maybe I only have that outlook because I've witnessed many such situations of poorly integrated JS libraries and have therefore gotten used to walled gardens.
> With React/Angular/Vue you're given a stable base upon which to build new components and logic
Oh you sweet summer child. Wait until you see the multilayered horror of devs insisting on styled components because they never spent the time to learn the specificity rules of CSS; their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves; suggesting that core concepts of the web are outdated because they came up in the Age of React.
React/Vue/Angular will not protect you from bloated, poorly written apps. I would argue they encourage bad practices.
> their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves
Yeah let's stop (re-)using open source software and write everything ourselves.
Who needs React when we can have cuddlecake's spontaenously written mini-framework (I lovingly call it anguvuesveact, because I got inspired) that definitely does not provide the required feature set or developer experience to support a productive professional development process, but it's mine.
Now that we have WebAssembly, couldn't we write applications in actual Assembly? It just takes confidence that we can build something lean with it, no other considerations necessary.
Well, uh, I just realized we don't need to rely on Firefox, if we just, uh, develop our own browser, uh, from first principles. A lean one, to be sure, only providing the features we need for our Web App. If we need new features we'll build them along the way.
Ah shit, my DIY lodash (I lovingly call it cuddledash, because I got inspired) has a bug but I'm focusing on the custom browser, so no time to fix that. :/
> React/Vue/Angular will not protect you from bloated, poorly written apps.
Only our self-written lodash lib will protect us, hear hear.
This is an extremely cringey, gatekeepy reply. It's just missing a "it's nothing personal, kiddo".
Good on you if you prefer writing everything from scratch. Some of us have shit to do and goals to meet and we'd rather spend our time on building actual functionality than reinvent the wheel for the nth time.
Your reply is the real cringe here. "I got shit to do" is no excuse to toss aside quality and craftsmanship. And you misread their argument they didn't say write everything from scratch, they said write a simple leaner version, but the argument is most people lack even basic problem solving skills. If you spend all your day glueing things together, you forget how to design and build them yourself. Sure you can stack the blocks in order, and make a really tall tower, but how soon until it falls over, or how will it withstand the first gust of air. That's the larger point. And this isn't "gatekeepy" this is reality. As software continues to eat the world, and most of us are forced increasingly to rely on these shitty apps and interfaces, it could do a little good to the world if Software engineering as a discipline took on a little more professionalism. So less of the "I got shit to do" and "move fast and break things" mentality, and more of the "lets do this right" mentality. Good engineers can write a little utility that solves a problem wonderfully for their context or scope, and still get their shit done and meet their goals.
It's kind of gatekeepy insisting on styled components being of lower quality than using pure CSS. Styled Components serves a specialized purpose of styling things on the web.
Maybe less elegant or performant in some respect than pure CSS, but with trade offs that some development teams will happily take.
I also hate the sentiment, that software development needs to adhere to some notion of purity or divine elegance. And yes, I'm using the word divine because people like the grandparent comment keep acting like CSS is the church. It may well be, for some, but there's a reason why CSS is getting new features continuously... Because it's not perfect for every purpose across every development department.
Maybe someone just didn't have the time confidence or interest to learn CSS. Maybe it's as simple as doing what you want, doing what you can afford to do, etc.
What I don't like is the negative framing of this choice. Bad things will be built, regardless of the underlying tools. Grandparent claimed that using Frameworks results in bad practices. I claim that shaming people and questioning their choices (whether they made them consciously or unconsciously) is a bad practice.
I dunno. Maybe. How about the practice of removing a test that fails? Literally, test fails, remove it, problem solved. Ship it. Sure there are build warnings, but CI isn't complaining, so..? Is that a valid use case? If your team member did that, you'd be cool-and-the-gang, easy-like-sunday-morning, shaming-is-the-real-shame?
Not trying to reframe anything. Just trying to understand the bounds of your ease with team members making these decisions.
I haven't been hostile to you or anyone who disagrees with me, by the way. Just trying to understand if and where I'm incorrect.
Furthermore, I said what I said in reaction to someone disliking the idea of Svelte being able to use any javascript library at all because of the chaos and bad practice that represents.
> You're talking about people going against quality standards of a development team.
That's what I've been taking about this whole time
I hear you. It's a balance. You grab a library or open-source project, boom! Done. Move on dot org.
Except later, maybe your project needs some custom functionality. Now you have to dig into docs to see if it's possible, then deeper into the source code to see if you can monkey patch using something undocumented. Maybe now it takes more time to cobble together what you need than wiring something lean from first principles. Understood the full import of the dependency from get.
The purpose of styled components (or CSS modules or what have you) isn't to deal with specificity. It's to deal with collisions between what are essentially global variables.
I don't think you and I disagree. Use the tool appropriate for the job. If the team doesn't have the discipline or will to use the cascade as intended, definitely, better to have a bloated CSS-in-JS that at least is usable, rather than a bloated cascade that people are afraid to use.
The number of times someone told me they prefer using Bootstrap classnames while using CSS when they bootstrap does not provide a classname for it... My front-end heart sinks!
Gah, at least it's not Salesforce. That year I spent in a Salesforce shop I earned gobs of money and nearly slit my wrists. I took the following year off. Learned to play ukulele. What a shitty platform. God bless the devs who thrive in it.
This is certainly not my experience. I’ve never had to touch a library with jQuery, and the vast majority of libraries with framework wrappers also have vanilla implementations. The difference being the wrappers need to be updated to keep up with the frameworks, and often have more ways to fail considering they’re often just vanilla libraries + wrapper code.
If a library is maintained, the existence of a framework wrapper doesn’t make it any more reliable in my experience.
This makes me feel conflicted.
With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech.
With JS libraries it's the wild west once again and before you know it, your components will need 3 different mechanisms of being initialized, their internals will use different approaches, before long you'll have multiple versions of jQuery in there as well and it'll make you consider the downsides of that approach.
But maybe I only have that outlook because I've witnessed many such situations of poorly integrated JS libraries and have therefore gotten used to walled gardens.