I know I am going to be downvoted so hard, but really it's very easy to build you own css these days, css frameworks look an easy solution for beginning your project but they become a burden gradually as your project grows
Really it's very easy to build your own web application framework these days, existing web application frameworks look an easy solution for beginning your project but they become a burden gradually as your project grows.
Really it's very easy to build your own database software these days, database servers look an easy solution for beginning your project but they become a burden gradually as your project grows.
Really it's very easy to build your own car these days, pre-made cars look an easy solution for beginning your project but they become a burden gradually as your project grows.
...
All of these cases may be true if you are the 0.01% that wants to do it to learn or have some very special business need that calls for it. For the other 99.99% of the time, it just keeps you from focusing on the stuff you actually need or want to accomplish.
I don't think so, and depending on your familiarity with the topic, your opinion might be different too.
Creating a web application framework that handles your needs can be incredibly easy. I can, and have multiple time, done so in Perl for a quick project in the distant past. It takes about 20-30 lines or so on top of loading the modules you would probably already want available for a system like that. Pull in HTTP::Daemon, pull in the HTTP modules, tie them together with a little regex foo for route parsing, done. In the very simple case, it's easier to do this than pull in a framework. In the very complex case where you need intricate control over odd parts of the process that frameworks don't usually give you, it's easier if you had written your own from scratch. In all the other cases, which I feel I was being generous in saying was only 99.99% of the time, you're better off having offloaded the concern to someone else.
Creating a database is also very easy. In the simplest case, you choose a record structure and write to disk opportunistically or on every change. Again, for the very simplest case, that's actually easier than even pulling in SQLite. In the very complex case, you can do interesting preprocessing and specialized storage techniques to store your data in ways that aren't amenable to anything except for a custom format.[1] Again, the vast majority of the time, you just use SQLite, Redis, or a RDBMS and it does a passable job at dealing with all your data integrity and warehousing needs. If you're a company trying to manipulate a dataset in a heretofore unseen way (either much faster or much more detailed that before), you might actually need to do it from scratch.
Creating a car is also fairly easy, if you have the prior experience (about as much or less as expected above). Like above, you're largely throwing existing parts together and the hard work is knowing what goes where and shaving off the pointy bits that prevent it from fitting really well. If you need to race something (because why else do you create a car?), in the simplest case you might just grab some cheap broken down beater and put a little work into it where needed and you have something that goes in a circle and you won't care too much if it barely finishes. If you have the money, you can buy a pre-built race-ready car and compete as am amateur. If you're an F1 team, you build the whole thing from the ground up to exact specifications.
This is, of course, all presupposing that the people involved actually have the knowledge and ability to do the really simple or advanced things. Often, they don't, or at least don't have enough to make it even feasible. For example, I know how to read and write CSS, but I'm not very good at it. Similarly, I know how to write HTML and apply CSS fairly in an amateur manner. I'm not a UI or UX designer. Does it really behoove me to learn the intricacies of design layout instead of using Bootstrap? I either don't care about how it looks at all, in which case I'll make it text/plain or at the most a couple of header tags, or I care enough that to make it somewhat passable visually I'll use Bootstrap. In what situation am I better off using CSS? In what way does that apply to more than 0.01% of the people out there?
Come back after you've built a database system used by tons of users and a car that someone is actually driving.
No one will take your argument seriously when you say ignorant stuff like "Creating a database is also very easy", or "Creating a car is also fairly easy".
No matter how you spin it, it is FAR from easy to build any of those, and the only people who think it's easy are those who don't have real experience.
> No one will take your argument seriously when you say ignorant stuff like "Creating a database is also very easy", or "Creating a car is also fairly easy".
Holy shit, did nobody read the last sentence of the original comment? I'll spell it out. The first three things were meant to be similar statements to the comment I was replying to, and the final sentence was explaining how they, plus the version in the comment I was replying to, were bullshit.
I then went into excruciating detail in the next comment on why, for each specific case, and capped it with a paragraph summarizing my point.
> No matter how you spin it, it is FAR from easy to build any of those, and the only people who think it's easy are those who don't have real experience.
Which is fully in line with exactly what I was saying.
It's much easier to build something that's suitable for your one specific use case than it is to build a general-purpose framework. Database systems, cars, and Bootstrap are all general-purpose. But if you need to store a collection of name/value pairs, carry a load from fixed-point-A to fixed-point-B, or create a web-page with a specific and custom style, building something from scratch can be the right way to go, and it can be easier than forcing a general-purpose solution to fit what you need.
But we're not talking about something with tons of users.
We're talking about a bespoke just-for-my-project sort of thing. That you think it's not even worth it unless you can get tons of users is part of the point. It's just a distraction just like your bespoke CSS framework.
Honest question: why? Why would you roll your own buttons, headers, footers, modals, panels, grid system, and alerts, which all respond responsively, when you could just take a framework off the shelf and start being productive immediately?
It depends on what you're doing. Kitchen-sink frameworks like Bootstrap are great for building tools that don't require a lot of customization of the UI, generally things like internal tools.
But for user-facing stuff, designers and PMs want to tweak everything about the interface, and by the time you're done, you've rewritten most of the CSS and you actually spent more effort doing so than had you just written the CSS yourself the first time.
Also, the way you wrote it ends up being a frankenstein-esque collection of style overrides. Zurb foundation is notorious for requiring hyper-specific CSS rules to override their default styles.
Bootstrap has made some progress towards making it more tweakable, but if you're maintaining/customizing an app long-term, you're better off writing your own css for the most part.
Edit: to add to that, the biggest problem that bootstrap solves IMO is a standard grid system, of which there are now many, more composable grid systems to choose from. Grid systems are so basic that its probably fine to pull one from the shelf, but with flexbox its really not that hard to write your own anyway.
Just wanted to point out that when Bootstrap first hit the scene this wasn't true:
> to add to that, the biggest problem that bootstrap solves IMO is a standard grid system, of which there are now many, more composable grid systems to choose from. Grid systems are so basic that its probably fine to pull one from the shelf, but with flexbox its really not that hard to write your own anyway.
Bootstrap was sort of a pioneer in the generalized responsive framework space. I recall Zurb Foundation close behind and Skeleton a short time after that...although my time line might be a bit screwed up.
Now with flex box it is certainly easier to roll your own...and that reduces the value (somewhat) of using a framework like Bootstrap or Foundation or (insert other responsive framework here), but it doesn't make it 0 (IMO).
Not really since most browser have their opinion on how to actually flex the box in corner cases (like: an image that has height 100% and not a defined width will cause all kind of fun in a row flexy)
I just had to fix that in a project today. Looked great in Firefox, but Chrome made the images huge and every time the page changed they just got bigger. Seemed completely broken to me.
I think the origin point would have been better expressed with that nuance: if you have the budget, staff (design, dev, QA), and need to customize everything, rolling your own is probably best.
Frameworks are for the 99% of projects where not all of those are true. I’ve had good results limiting gratuitous changes that way: “do we want to pay to change this and test all of our supported browsers/accessibility/RTL?” is a lot better than “No”.
BS4 includes Flexbox and it has been designed to be much easier to customize with SASS. They have also added a bunch of utilities for spacing, colors, etc which makes customization at the CSS level easier as well. For a practical example, I only had to write a few lines of SASS to give some components (e.g. modal) a material design look. I think your criticism is valid for BS3 but not BS4 unless you are building a website that is drastically different than 95% of websites.
I use bootstrap as default reset without the grid. All the modern standard widget premade and none of the grid spacing coercion is a good compromise to my need.
For the projects Bootstrap was designed for, the choice isn't between Bootstrap and a professionally designed custom theme; the choice is between Bootstrap and a white background with all text in Times New Roman 16 pt.
What changed are browsers. The original advantage of bootstrap et al where grids and standardisation. These initial use cases have been subsumed by browsers, and bootstrap offers little more than a useless level of redirection.
Then, bootstrap added what I want to call widgets: small functional units that can easily be reused. Here, as well, browsers have changed dramatically. At the time bootstrap came out, these widgets required browser-specific, inscrutable hacks like negative margins, spacer pixels, and other crimes against htmlanity. Relative to 10 years ago, all of today's browser engines are identical, and CSS has added all these typical use cases.
What remains is more or less a skin changing html's defaults to something that may be prettier, or just not weighed down by the stigma of being the default.
At least. I’ve seen lots and lots of internal tools, product admin dashboards, and the occasional single-page product marketing sites, like the one the overworked intern, Todd, threw together in the 24 hours between the time the virtually-without-requirements demand was dropped on his tiny, cramped, mid-bullpen loaner desk and when he launched it into production to zero thanks.
It depends if it's a project that is going to grow. For so many things Bootstrap does so much for so little effort. I use it any time I need to spin something up quickly, prototype an idea, put an internal page together. Bootstrap is a tool for making a page where you don't care how it looks look good.
It also depends on how the project is going to grow. If I'm the only lead dev on a team that's only going to see a revolving door of junior devs and interns, it's much easier for me to point to Bootstrap's documentation page and say "just copy the example from here" than it would be to get junior devs quickly up to speed on any custom CSS framework. There's even a chance a junior dev is already going to be familiar with Bootstrap from a previous project.
Except for all the edge cases which is a big reason why CSS frameworks are a thing. If you need to support lots of browsers it is certainly not easy to build your own.
You are correct in that css frameworks become a burden but I disagree that building your own is “very easy”. A css framework that works well on most devices and most browsers for a non trivial app is quite a lot of work.
If I'm making a content-website (where the "killer app" is the content and not presentation) I use bootstrap - its definitely cheaper than a web designer.
You aren't wrong. I will say I do still find myself surprised that many sites don't test cross browser and I find that these frameworks can alleviate that.
Most users simply don't care whether a framework or hand customized code is used anywhere in the stack. This includes the front end all the way down to the assembler shoveling bits through a processor.
Why should somebody who is technically proficient or even highly skilled in developing on the backend bother with becoming equally skilled enough on the frontend to not "need" these frameworks? Especially when it matters very little.
It is difficult. Look how much effort was put into Bootstrap3. Good UI framework brings consistency and good practices.
Browsers are not so consistent as people think. CSS is difficult to get right. UI/UX is hard if you are not a designer. Interactions between DOM, CSS, and JS are hard to test.
That’s exactly what i did lately. I replaced Bootstrap 3 with my own custom CSS after testing out Bootstrap 4.
With flexbox, media queries and SCSS i dont find any need for a CSS framework anymore. My codebase without Bootstrap (and JQuery) feels so light, flexible and maintainable nowadays.
It's certainly become easier but I rather like having people contribute fixes to issues we may not be aware of. For a small team like our startup, execution of the idea is far more important than having something completely unique.
I think this advice applies most to layout - at work we still heavily use Bootstrap components, but the grid layout we started out with turned into hellspawn really quickly.
Really it's very easy to build your own database software these days, database servers look an easy solution for beginning your project but they become a burden gradually as your project grows.
Really it's very easy to build your own car these days, pre-made cars look an easy solution for beginning your project but they become a burden gradually as your project grows.
...
All of these cases may be true if you are the 0.01% that wants to do it to learn or have some very special business need that calls for it. For the other 99.99% of the time, it just keeps you from focusing on the stuff you actually need or want to accomplish.