how often do you take an open source React component and integrate it without any issues or unnecessary overhead. Very often, I don't know what you have been working with lately...
I really don't understand how this "downside" is leaned as a positive aspect in your article. too reliant on npm install ... that's, like, one of the most important upsides of modern web development: there are a lot of code out there that one can easily import and use it on its project.
Often building your own components, especially in Svelte, leads to less time spent overall. It would be really nice if you provided one real-life example of this, because that phrase doesn't make sense in my head for most of the web-development that I do (landing pages, ecommerce stores...), specially when using something like MaterialUI.
I don't like Svelte, I may take it for its allegedly perfomance benefits, but explaining why one needs to add a $ in the code when it "depends" on something seems way harder than explaining about renders and the hole component as a function. I still didn't grasp its "simplicity", but I value innovation and support Svelte, still not seeing why would anybody leave React as of now, it's a way different momentum than the AngularJS migration.
Thank you for taking the time to provide your feedback.
In a scenario where a web app's design is based on MaterialUI, I agree that using an existing component library is the best and most efficient approach. For Svelte, there's sveltematerialui.com/ as a starting point.
The use cases I encounter most often is where web apps are designed by an in-house design team and the web developers develop according to the design specifications. While there are many open source calendar components for example, they often provide features that are not needed. In my experience, this can add complexity, unnecessarily increase JS bundle and CSS file sizes and make it more complicated to add features that are unique to a business. On the flip side, developing custom components requires more testing (e.g. cross browser compatibility) so it is a bit of a balancing act on a case by case situation I'd say.
As for my comment on being too reliant on npm install: Imagine a situation with 15 frontend developers working in 3 teams. What I think tends to happen is that developers' first instinct is to search NPM for a component, install it and use it. Each component often comes with its own dependencies (both direct & transient) and sometimes developers on different teams add different npm packages to solve similar needs. This slows down the build pipeline & potentially increases the final bundle size. With good internal team communication and a share component library, this kind of duplication should be kept under control.
As with many things in tech, whether Svelte is the right decision or not depends on many factors. In my case, so far, I've had a good experience.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
how often do you take an open source React component and integrate it without any issues or unnecessary overhead. Very often, I don't know what you have been working with lately...I really don't understand how this "downside" is leaned as a positive aspect in your article.
too reliant on npm install ...that's, like, one of the most important upsides of modern web development: there are a lot of code out there that one can easily import and use it on its project.Often building your own components, especially in Svelte, leads to less time spent overall.It would be really nice if you provided one real-life example of this, because that phrase doesn't make sense in my head for most of the web-development that I do (landing pages, ecommerce stores...), specially when using something like MaterialUI.I don't like Svelte, I may take it for its allegedly perfomance benefits, but explaining why one needs to add a
$in the code when it "depends" on something seems way harder than explaining about renders and the hole component as a function. I still didn't grasp its "simplicity", but I value innovation and support Svelte, still not seeing why would anybody leave React as of now, it's a way different momentum than the AngularJS migration.Hi Luciano,
Thank you for taking the time to provide your feedback.
In a scenario where a web app's design is based on MaterialUI, I agree that using an existing component library is the best and most efficient approach. For Svelte, there's sveltematerialui.com/ as a starting point.
The use cases I encounter most often is where web apps are designed by an in-house design team and the web developers develop according to the design specifications. While there are many open source calendar components for example, they often provide features that are not needed. In my experience, this can add complexity, unnecessarily increase JS bundle and CSS file sizes and make it more complicated to add features that are unique to a business. On the flip side, developing custom components requires more testing (e.g. cross browser compatibility) so it is a bit of a balancing act on a case by case situation I'd say.
As for my comment on being too reliant on
npm install: Imagine a situation with 15 frontend developers working in 3 teams. What I think tends to happen is that developers' first instinct is to search NPM for a component, install it and use it. Each component often comes with its own dependencies (both direct & transient) and sometimes developers on different teams add different npm packages to solve similar needs. This slows down the build pipeline & potentially increases the final bundle size. With good internal team communication and a share component library, this kind of duplication should be kept under control.As with many things in tech, whether Svelte is the right decision or not depends on many factors. In my case, so far, I've had a good experience.