40
Replies
I would not advise using a Bootstrap accordion in a predominately non-bootstrap website if that is the idea as you'll only be leveraging about 3% of the javascript, leaving 97% bloat...........gulp!!!!......not to mention the 1000's of lines of redundant css!!!!
By @osgood_
There may be bloat in the website, but certainly not caused by the Bootstrap framework:
It is great to see that HTTP/2 is being delpoyed for the site; even better that HTTP/3 is deployed for the Bootstrap framework.
Talking Bootstrap bloat is so much of a previous (read: jQuery) era.
Code bloat isn't an issue for me, either.
It might be if I used other 3rd party code, but I don't.
By @Nancy OShea
It's never an issue if you use that approach because it then becomes an issue that you would rather not consider.
Talking Bootstrap bloat is so much of a previous (read: jQuery) era.
By @BenPleysier
It's unprofessional to deploy code that is NOT strictly required but l don't expect an amateur to understand that..............wheat from the chaff.
Bootstrap will always be bloated because thats the nature of it - cheap and cheerful rather than bespoke, regardless of HTTP/?
I acknowledge we are in an era where developers are very poor in terms of skill, practices, common sense as a result of their almost exclusive reliance on 3rd party frameworks and libraries. Throwing the kitchen sink at the problem these days is just a by-product of the state development is in today. In reality the majority don't really like it if truth be known but they have no choice but to join the lemmings.
I would not advise using a Bootstrap accordion in a predominately non-bootstrap website if that is the idea as you'll only be leveraging about 3% of the javascript, leaving 97% bloat...........gulp!!!!......not to mention the 1000's of lines of redundant css!!!!
By @osgood_
There may be bloat in the website, but certainly not caused by the Bootstrap framework:
By @BenPleysier
28kb and 23kb of Bootstrap css/scripts just for an accordion.............that's the bloat right there, hence I provided advice to consider not deploying Bootstrap for a single component use in a predominately non-bootstrap website.
The OP Originally Wrote: "yes I know I need to redo my website to make it responsive..."
Modern Bootstrap takes care of that and a lot more, with very minimal overhead.
The OP Originally Wrote: "yes I know I need to redo my website to make it responsive..."
Modern Bootstrap takes care of that and a lot more, with very minimal overhead.
By @Nancy OShea
Keep on fooling yourself, why deploy code you don't need, it's senseless, at least make the effort to make it more streamlined. I've a hundred sandbags loaded in the boot of my car I dont need, the car is very slow, so instead of removing the sand bags I had a more powerful engine fitted..............lack of common sense is no excuse for someone to provide a solution which makes a bad solution faster or more convienient.
I've a hundred sandbags loaded in the boot of my car I dont need, the car is very slow, so instead of removing the sand bags I had a more powerful engine fitted
By @osgood_
I have a spare wheel in the boot of my car, that has never been used. It does not affect performance because it's relatively small in weight.
Getting back on topic, modern web development negates the effect of so-called bloat, as this example shows:
Furthermore, because my sites deploy NodeJS/Express, the file gets loaded once for the whole website. A small price to pay for a standardised stylesheet that is understood by millions of developers around the globe, making site maintenance a cinch for anyone. This is in stark contrast to your bespoke stylesheets.
And because I am using an HTTP/2 server, the files are simultaneously loaded, thus time is not a factor.
Professionalism in web development isn't just about minimizing code—it’s about making informed decisions that balance efficiency, maintainability, and scalability. Bootstrap, like any tool, has its place when used appropriately. In modern development, concerns about 'bloat' are largely mitigated by optimized delivery methods such as HTTP/2 and caching strategies.
By @BenPleysier
Http/2/3 etc wasn't deployed so that developers could include redundant code bloat it was deployed because websites and apps became more complex requiring more complex code which was integral and used by the website/app. You and many other developers are abusing a solution which was never intended to be used to mitigate code bloat.
Rather than focusing on rigid absolutes, the goal should be to choose solutions that best serve the project’s needs while ensuring long-term maintainability. If a standardized framework improves collaboration and future-proofing, that’s a valid consideration—just as bespoke solutions have their own merits in specific cases.
By @BenPleysier
If only. Unfortunately these days much of the initial thought process is lacking in favour of a one size fits all approach.
Regarding the off-topic remarks, yes, I have recently had to redo a Vue framework-based website. I managed to make significant improvements by translating it into the Wappler front-end framework called App Connect.
By @BenPleysier
Why didn't you just redo it in Vue. There's nothing Vue can't do that App Connect can do. I think the reasoning here is you know App Connect better than Vue, rather than any significant improvements being made.
Let's be honest here, no developer wants to inherit some other developers project built in a workflow which is foreign to them and maintain it, they would rather start from scratch using the workflow they know.
Http/2/3 etc wasn't deployed so that developers could include redundant code bloat it was deployed because websites and apps became more complex requiring more complex code which was integral and used by the website/app. You and many other developers are abusing a solution which was never intended to be used to mitigate code bloat.
By @osgood_
The purpose of HTTP/2 and HTTP/3 is to optimize resource loading and improve web performance, which naturally includes handling larger codebases more efficiently. While they weren’t designed specifically to 'justify' unnecessary code, they do mitigate performance concerns that were more pressing in earlier web development eras.
Regarding the off-topic remark, Vue vs. Wappler, the decision to transition was based on workflow efficiency and maintainability, not just familiarity. Every framework has its strengths, and the choice depends on the specific needs of the project. Standardization and ease of collaboration are key considerations, especially when working on projects that may be maintained by multiple developers over time.
Ultimately, professionalism in development is about making informed choices that balance efficiency, scalability, and maintainability—not adhering to rigid absolutes."*
Http/2/3 etc wasn't deployed so that developers could include redundant code bloat it was deployed because websites and apps became more complex requiring more complex code which was integral and used by the website/app. You and many other developers are abusing a solution which was never intended to be used to mitigate code bloat.
By @osgood_
The purpose of HTTP/2 and HTTP/3 is to optimize resource loading and improve web performance, which naturally includes handling larger codebases more efficiently. While they weren’t designed specifically to 'justify' unnecessary code, they do mitigate performance concerns that were more pressing in earlier web development
By @BenPleysier
Well you seem to be agreeing, taking advantage (l view it as abusing) a solution to justify deployment of unecessary redundant code.....that in my opinion is not a very professional approach.
Regarding the off-topic remark, Vue vs. Wappler, the decision to transition was based on workflow efficiency and maintainability, not just familiarity. Every framework has its strengths, and the choice depends on the specific needs of the project. Standardization and ease of collaboration are key considerations, especially when working on projects that may be maintained by multiple developers.
By @BenPleysier
Ease of collaboration......Wappler? On the one hand you promote Bootstrap because its a popular choice amongst developers and brings uniformity in your opinion and on the other hand you promote Wappler workflow that very few developers use or have even heard of..........that's quite confusing as to what it is you really believe. Just be honest and cut the nonesense, you use something if it happens to suit your purpose to do so, regardless if it's a popular choice amongst developers or not.
Consistency in development choices isn’t about adhering to popularity alone—it’s about selecting tools that best serve the project’s needs while ensuring maintainability and efficiency. Bootstrap is widely adopted, making it a practical choice for standardized styling and layout. Wappler, on the other hand, provides a structured workflow that aligns with my development approach, particularly in cases where flexibility and efficiency are prioritized.
Vue and Wappler share several similarities, particularly in their component-based approach and reactive data binding. Wappler’s App Connect framework offers a structured workflow that aligns with modern development practices, much like Vue. The key difference is that Wappler provides a visual development environment while still allowing custom coding, making it a practical choice for certain workflows.
The decision to use Wappler was based on workflow efficiency and maintainability, not just familiarity. Every framework has its strengths, and the choice depends on the specific needs of the project. Standardization and ease of collaboration remain key considerations, regardless of the tool used. Every framework has its strengths, and the choice depends on the specific needs of the project. Standardization and ease of collaboration remain key considerations, regardless of the tool used.
The key is making informed decisions based on project requirements rather than rigid absolutes. Professionalism in development is about understanding trade-offs and making educated choices—not dismissing methodologies outright simply because they differ from conventional workflows.
By @BenPleysier
I don't disagree with much of what you are saying it just comes across as a bit of a contradiction that you regard Bootstrap and use it because it's a popular choice, because of familiarity, amongst other developers, who may need to collaborate or maintain the code you produce and yet you use a product and workflow which is not very familar amongst other developers..........that's all.
The essence of the story is I don't think we really give a crap about other developers. It would be more honest to stop using that argument when you don't adhere to it .
AdChoices