It really can't be said enough: bootstrap is phenomenal and the creators, maintainers, and contributors deserve immense praise. They've collectively saved our industry millions of hours of frustration and helped us achieve good-looking, accessible, and responsive websites.
Just keep in mind that Bootstrap ist not fully accessible by default on purpose [1]. I really hope this changes in v5, because accessibility shouldn't be opt-in.
I'm not who you asked, but I've done it previously just calling the Bootstrap CDN within Django, and it was super simple. This was years ago, but I have this tutorial bookmarked from back then: https://tutorial.djangogirls.org/en/css/
Yep, manually calling the CDN is the simplest way, but I remembered that sometimes a lot of adjustments needed to be made to the forms and every form would need to be manually coded, or use one of the Django app to automate that.
Does the language of the CMS matter? Django is Python, but we are a .NET shop. Would Django still work for us or should we look into a CMS like Orchard or Umbraco?
So happy jQuery is gone! I'm also glad they're moving towards including more utility classes (this started in v4) but I've spent the last year with TailwindCSS and man is it nice. I just bought TailwindUI as well for the component aspect. I think it's going to take some convincing to move back to Bootstrap.
I'll definitely give it a shot on a small project though.
Direct DOM manipulations are not necessarily incompatible with Vue or React.
I'm not sure in this specific case, but I'm saying this in general because there seems to be a common misconception. People jump through the craziest, smallest, highest, flaming-ist hoops to get everything to render through Vue/React. Using virtual scrollers that aren't fit for purpose. Trying to get d3/plotly running on the VDOM. Etc etc.
You can always just pop a DOM ref out and let something else take control of it; easy peasy.
I can attest to this. I had the hardest time getting a vue wrapped google maps library to work, until I decided enough is enough and used the native google maps sdk. Perfectly doable and can save you a ton of time. If possible use a vue/react compatible library, but don't do it at all cost.
While it’s possible to use direct DOM manipulation via refs, IMO this defeats the purpose of using a reactive lib like Vue or React. If you are using a lib like jQuery/D3 with Vue/React, you are basically just using Vue/React to render the initial state of the DOM.
If your entire site's React/Vue implementation is solely serving up DOM elements to other libraries perhaps.
Frequently it's the case though where like 99.99%(hyperbole) of the site is handled by React/Vue and you just need a few specific components to be controlled by an external lib. Heck, anything wrapping a canvas based lib is pretty much doing this.. Tons of component libs do this. It's very "web component" like to let something control a slice of the DOM anyway.
I agree that sometimes its okay to give another lib control of the DOM (D3 probably falls in this category). However in the context of the parent comment where haberman is wondering if Bootstrap could work directly with Vue (which it could) I still hold that this is missing the point. In this case Vue would be nothing but a glorified templating engine. I would rather only use the boostrap styles while writing my own logic with Vue's reactivity model.
Can the interactive / JS parts of Bootstrap be reimplemented in a way 'native' to Vue or React? I'm probably naive but I can't imagine the JS parts are that complicated (things like collapses, menus, changing classes, etc).
It's definitely going to make it a lot easier than it is now. It's really not bad working with external libraries in Vue. I imagine the way that Bootstrap does it's Javascript will leave you doing a lot inside of Vue's lifecycle hooks (beforeMount, mount, etc).
How big is the CSS per page? Do you have to do any per-page optimisations? I like the concept but when I look into it, the full library appears large and having to e.g. run a CSS optimiser to bring in only the CSS classes used on every page is added complexity.
Generally I'm aiming to inline all the CSS into the page with less than 50KB of CSS when it's uncompressed. Bootstrap was always too large for this.
As another poster said with PurgeCSS it isn't bad at all. I'm lucky enough that all my users are internal and we're a Chrome only business so a lot of that cruft can be left out and the speed of the page isn't a large concern.
Prototyping with VueJS and Tailwind on the frontend with Rails on the backend is pretty much my ideal workflow. It's so quick to get a feature done I still surprise myself.
The full Tailwind without PurgeCSS is definitely huge (about 2MB uncompressed), but the more recent versions have PurgeCSS integrated directly, without needed to set it up separately.
The suggested use case is building one stylesheet that covers all your pages, with the idea that a site with a reasonably consistent design is likely to use only a very narrow sliver of the available classes. In practice I've found my styles when using Tailwind to hover around the 30KB mark uncompressed (single digit KBs actually going over the wire).
It's definitely added complexity, but it's not too bad imo.
I don't see that as an issue. It will get cached and it's the same difference as having a medium sized, well compressed image. Almost inconsequential when you consider you'll never have to write any more lines of CSS.
Don't get so hung up on the size of the CSS when it's relatively tiny compared to images.
> Don't get so hung up on the size of the CSS when it's relatively tiny compared to images.
It's an issue when you have to make the user wait for the top of the page to render (so they might leave if it takes too long to see anything), especially on mobile on a slow connection.
That's why APM for example makes you inline the CSS at the top of the HTML file and won't allow more than 75KB of uncompressed CSS.
CSS might be smaller than most images but it's critical to the initial page experience whereas image loading can be delayed.
JavaScript didn't work well across all browsers a decade or more ago, and jQuery made it easier to write JavaScript without resorting to browser-specific hacks. It also added some elegant features.
JavaScript has improved so much you don't need jQuery anymore.
Unfortunately vanilla JS is much less readable. JQuery function names make your intent very clear and chaining them is elegant. Also, very minor, but the "magic" (syntactic sugar) provided by `$()` compared to `document.querySelectorAll()` et al. makes using JQuery seem much more frictionless, especially since you know if you're using it, all the functions will work on whatever you selected and can also take HTML strings, etc.
One thing vanilla JS does have going for it though is performance. I profiled a script of mine and rewrote all the bottlenecks using native JS and it's undoubtedly faster.
Most if not all the modern frameworks/projects use Babel to compile modern Javascript to the es5 standard from 2009. I guess 11 years of browser backwards compatibility are enough, or should we downgrade and support IE 6 ?
I wonder if I can get more web developers where I work back in the bootstrap camp now. Use of jQuery was their main complaint and reason for abandoning.
On a related note, I feel like I'm officially becoming an old fogy because I learned web development with jQuery but never did enough to experience the pains it brings that newer frameworks do away with, and as such I still feel drawn to using jQuery, especially when I want to throw together a smaller websites.
Although jQuery does seem less popular as a choice for new projects nowadays, I'd like to chime in to agree here (not to knock Bootstrap; it's good that they're staying current with their developer ecosystem).
Given appropriate element names and classes, jQuery and CSS selectors can provide a straightforward and readable way to express application behaviours, and it's a well-proven and stable project at this point.
Yeah, this is what some commenters are missing. The real alternative to jQuery isn't some fancy new framework, it's just... plain JavaScript.
Things have really gotten much better in the vanilla world. Although some things remain more verbose or cumbersome than jQuery alternatives, you really don't need a whole layer of abstraction to handle the simple tasks jQuery was designed for any more.
jQuery somehow gets abuse for being more bloated and slower than vanilla js despite the fact that almost nobody is ditching jQuery for vanilla js and instead running to vastly slower and more bloated SPA frameworks.
HackerNews is back on this debate I see. Look, I still use jQuery, mostly because I comfortable with it. If I am doing a small side project or an MVP that doesn't need heavy JavaScript then why would I configure all that JavaScript tooling when I can just use something I am comfortable with? I hear, but jQuery is heavy. I wonder if any tests have been done to see how much that ACTUALLY matters. Is the difference between react and jquery file size that much? And does it actually matter? I don't think most people who drop the "its bigger" argument know the size differences, let a lone the impact. It's just a nice trope nowadays. But please link to something to educate me.
With that said, I do use the modern vanilla js api from time to time. It's gotten better. There are still some things that aren't great, but it's fine. I use it a lot when working in puppeteer actually.
But back to jQUery. If I need to add some interactivity to a site and I know some jQuery plugins. I just use that. I did it for an entire MVP just recently. I know if it takes off all that frontend work I did will be replaced. Great, jQuery (but mostly just plain old school web dev) got me there without the need for an over-engineered tooling ecosystem. I've watched people struggle with slick new shit on MVPs before. I'm already iterating on my product and testing new hypothesis.
If you are more comfortable with the newer stuff then you should use that. If you are more comfortable with jQuery you should use that. If the product you are developing specifically needs or doesn't need one, then go with what the product needs.
Edit: Also this about BootStrap. I love it, also makes my life easy for MVPs and backends. Keep going strong bootstrap!
Amen!! It reminds me of the people who used to talk down on devs who use Java, C#, Python, and basically any language that isn’t C++ “because it’s more efficient” and all the others are “terrible and bloated.”
Second that, I am also in this stage of life where having a good sleep is more important than having a pure code. Some annoying platform-specific bug is not fun any more, especially if it was solved many years ago by someone else, so yay to jquery!
It's not so much the pain it brings, so much as the fact that a lot of the original inconsistencies and querying it was invented for are either gone or integrated fully into the native APIs. http://youmightnotneedjquery.com/ illustrates this fairly well! After working with more modern JS and the pure browser APIs on larger non-trivial projects I can't say I've ever felt the need to reach for jQuery the way I used to in its heyday.
I'd be hesitant to refer to jQuery as a framework, as I don't think it fills the same void as what we commonly think of as a "javascript framework" does; it was more a utility for querying and mutating the DOM. It doesn't provide answers for questions like "how do I handle state?" or "how do I convert state into DOM?", although it does give you some tools to answer those questions yourself.
Agreed. I think people do tend to forget jQuery's primary use and greatness came from masking browser inconsistencies and exposing things that just weren't even possible with vanilla JS. Necessity for that type of thing has waned but someone coming into jQuery now or in the last couple years I could see the disdain if they weren't around when making your JS work in all browsers was ridiculously hard and time-consuming. It was a very, very good and useful segue tool that has run its course.
If you are using a framework/library like React, Vue, Angular, etc. then the need for jQuery goes away.
However, the number of websites where a full-blown library like React is the right tech stack is probably less than 5%. For everyone else you would want to use vanilla JS, though if you are already familiar with jQuery I don't think there is anything wrong with using it.
The funny thing is I spent years using jQuery and have also used Vue.js, but I'm just so tired have having to deal with importing libraries, setting up build systems, etc. that 9 times out of 10 I will just use vanilla HTML/CSS/JS and call it a day. It is just so much simpler. YMMV
I don't know. Being neither a web developer nor a frontend specialist (my professional development days are long behind me and were mostly spent on real time systems in Ada with some UI work using Qt), I recently developed a small site using react and redux. I chose the stack for fun but I found the experience a lot nicer than all my previous forays into web development. It felt a lot cleaner than what I was expecting. I think the stack pushes you in a clear direction regarding architecture and to me it seemed to make things simpler rather than more complicated.
That’s exactly why many of us use it, without giving much thought to the idea that it’s heavy or slow (which really makes me wonder what the hell some people are doing with their React apps...)
The developer ergonomics, and the mental models which it prescribes - which are why I’d argue it’s actually a framework and not just a library, but that’s semantics - are really well thought out and can make you very productive.
If I want to build a static site with minimal fuss I might still use something like HTML, Sass and vanilla JS with Parcel. For pretty much everything else React has become a default.
React is also well-suited for a single highly-interactive module on an otherwise non-React website. Of course, you still need to consider JS code size and loading performance, but it would often be completely reasonable to use React for, say, a very complex interactive form or table of data on your otherwise static Rails website.
Something like Preact can be pretty good for this too. The one thing that makes React (by itself, not with all the stupid extras) good for this stuff (as opposed to Vue and Angular) is that it has a very simple API without much surface area, so it's relatively easy to maintain, just like jQuery. But where it still falls a bit short is the actual size of the library itself, it's a bit wasteful to package in React just for a widget or something.
I don't agree at all. React is just as much a framework as a "way of thinking". I use react for _everything_ - because it's a great way to whip out a website - large or small. The "complexity" added is non-existent, unless it's because you are not willing to learn the way to do things. That's not the paradigm's fault, that's just people being complacent and lazy - sticking with "what they know" (which is fine, it's human nature).
Throwing together an API in .NET Core and a website consuming that API in React takes less than 5 minutes to get going.
Any app that requires lots of direct DOM manipulation (which are pretty rare cases).
Think making use of html `canvas`. Though there are nice libraries that abstract the ugliness like react-canvas, it would lead to less reusable code than the jQuery equivalent, imo.
Late reply, but yes, I totally agree. I was giving example of things that shouldn't use React. Everything should be SSR, and no in page interactivity at all is needed.
It's an unnecessary dependency for those using different frameworks. Its imperative model is also very incompatible with the reactive model that's becoming more common in frontend (React etc).
There's no problem with it, but its 2 main use cases are gone: ensuring a consistent idiom between various browsers, and providing a nicer API. Vanilla js does both now (if you really want to support older non-IE browsers, you can add a transpiling step).
There's one use case that might remain: the jquery plugins ecosystem. You can find many replacements on npm, but they're a bit less beginner-friendly.
I dislike having to write a separate front-end and back-end and worry about APIs and JWTs and security and Redux and multiple servers coupled with isomorphic React being more pain than it's worth when I could just as easily not use React.
I'd use React on every project if I could run it like a Rails front-end instead of needing to write distinct server and client side applications.
Have you looked at next.js? It allows you to write your server side database access code/etc in the same place as your react client side app. Pretty neat, however I personally would rather write my backend code in something better than JS so I don't go that route.
Not sure I follow. Reactive frameworks includes more than React. Reactive frameworks generally mean some form of observables, observers, and mechanisms for linking the two together via a dataflow graph, e.g. http://reactivex.io/documentation/observable.html.
> This page explains what the reactive pattern is and what Observables and observers are (and how observers subscribe to Observables). Other pages show how you use the variety of Observable operators to link Observables together and change their behaviors.
I'm not familiar with React so I'm not sure how all these concepts are implemented in React.
Most front end folks that I've spoken with didn't like the jQuery dependency not because it was huge or old but because jQuery does not play nice in a component world (React, Angular, Vue ...). Bootstrap 5's custom Javascript solution will unlikely change their view.
With that said, there's a lot to like in Bootstrap 5 to quickly throw together a site.
jQuery solved the problem of browser compatibility and hard-to-use browser APIs. However browser api have improved a lot, with new apis sometimes modeled after jquery, and browser compatibility is much less of an issue. There is really isn't a reason to use jQuery over just vanilla javascript anymore.
I don't think it makes sense to use React and friends unless you are building Single Page Applications.
That was one of the biggest reasons I abandoned it.
But also, since Bootstrap, a lot of competition in that space has popped up, and there's less of a need to buy in to everything that Bootstrap comes with, or any particular frontend library for that matter.
These days, I don't know if I would use Bootstrap again unless there were parts I wanted to harvest from it.
I’m very excited to find this. I have a handful of projects in my pipeline that require “just enough” of the dynamic sugar that this could potentially provide for little investment of time.
I just recently picked up front end dev and I'm curious how professional teams handle IE these days. Is it completely ignored? Or do sites still try to support it?
Depends on your customers. Can't just look at the stat counter usage sites and determine based on that. You have to look at who uses your site, and then decide what the financial impact of not supporting IE is going to be.
Where I work, we sell into large companies, where IE may be a default browser without the ability to install an alternative. Therefore, we support IE11 (only version of IE still officially supported). Financially, it would be irresponsible not to, as it could kill 6 or 7 figure contracts if the CEO tries to use our software and it doesn't load or just shows them a "upgrade your browser" page.
But even then, we do make allowances for IE. It is slower. In fact, some of the speed issues come from adding polyfills for things we deemed necessary for efficient development. It may not have exactly the same layout (for instance, we use an accordion to reduce the number of elements on a screen for IE on one page, but a list of carousels in browsers that are capable of handling the extra complexity).
We actually attempted to use CSS Grid, and it mostly worked. We've since stripped most of that out except some of the base page structures - just too many edge cases. And flex actually works fairly well as long as you stay away from some of the well-defined known issues.
Anyways, to the main point - has to be a site by site decision based on your site's visitor base, their browsers, and whether it makes the financial sense to spend the time supporting IE compared to the return you may get.
Yeah, I do business-to-business ecommerce and our yearly revenue coming from Internet Explorer is _more_ than _mobile_ (excluding tablet).
So, yes similar story. IE11 needs to _work_, though maybe not as well. Though, I generally avoid polyfills (even jQuery) and try to just write code works natively in IE11.
Yeah, same, also you don't wanna be on a demo with the sales, GMs and VPs of all sorts and all of a sudden find yourself in the position to explain the 'cross-platform' problems they are having on their devices - seen that, it's ugly, thus you go with the LCD - thanks to jquery!
In enterprise IT, I'm seeing more and more shops that refuse to give us support unless we switch from Firefox to Chrome, because that's "all they know works".
Which is to say, a lot of your potential customers already probably have a dozen tools they depend on that don't work in IE already anyways.
It is very rare to have to support Internet Explorer anymore for new applications. Most software that requires IE support is legacy enterprise stuff. Microsoft has been promoting Edge for 5 years already over IE.
We should all not care about IE anymore. Devs supporting it is the reason for people using it. If all the sites would be broken IE, users would be forced to upgrade.
It’s very much a matter of “what is your audience.”
My current employer has dropped IE11 for new projects, but we keep it around for already extant products and pages, unless we do a full redesign and rethink. IE11 is such a small percentage these days that the cost/benefit ratio isn’t good.
(I only prototype stuff as a designer, so I am just throwing caution to the wind and doing whatever the Big 3 rendering engines support, because the idea of giving up grid makes me sad, now that I understand how it works. [sort of understand how it works])
IE is still a thing in the enterprise and a lot of enterprise web apps are built on bootstrap. I totally understand their motivations but until IE is dead I wish they'd kept support. Based on the planned EOL this leads me to believe that they don't expect BS 5 to pick up steam in corporate environments until later next year.
They didn't _need_ it, but I think people gloss over how much easier jQuery made things back in the Bootstrap 1 era. In essence, Bootstrap used jQuery to bootstrap Bootstrap.
This is probably more of a mental thing for me than anything, but it's hard to separate myself as an old-school developer from the idea of supporting IE because of it's historical market share. As much of a PITA it was for so long. I suppose, though, I'm happy to see it go.
A huge part of the knowledge I had to acquire in the early years of my development career is now useless or even harmful... Anyone remember clear: left; ? :D
On the other hand, something like Bootstrap is pretty awesome if you want to create a slightly better, standardized look for your corporate intranet web app or site. Environments where IE11 is still somewhat common and where the relatively large share of Mobile Safari hardly matters.
Just recently someone mentioned to me that some SAP stuff can't be used without IE11. And as long as you get these hold-outs and enterprise IT guys avoid auditing multiple browsers, you'll get IE11 as the sole available browser in cubicles.
Been there too, remembering the nights dealing with IE... How to forget that dramatic years with the IE 5 debugger.
We were just other victims of the M$ monopoly.
Yup, and we're looking at dropping Legacy Edge from our supported browsers for this reason as well. As of right now, we still have v17 and v18 in there, but there's a PR open to remove.
So this will replace Bootstrap 4, which was released in early 2018 and will reach end-of-life before the end of this year. [0]
Could someone explain the target audience for a framework with this rate of churn?
Are people really creating websites that are expected to live for less than three years? Or are people working on longer-term products and expecting to do a major rewrite every few years?
Speaking to the lifetime of each major version—Bootstrap 4 can't go into any kind of LTS situation until v5 is fully stable. That's going to take a few months just being honest, so I fully expect v4 to be around into 2021.
We've also maintained security patches and more for v3 where appropriate well past the LTS for the web's sake. While we try to have guidelines around it, we want to help move things forward for the web :).
This might be a weird explanation, but maybe they just have fewer bugs to fix?
Correct me if I’m wrong, but “end-of-life” in this context just means that it’ll stop receiving active development and bug fixes. For a mostly-CSS framework, I wonder how much the average Bootstrap 4 user needs more development.
> Are people really creating websites that are expected to live for less than three years? Or are people working on longer-term products and expecting to do a major rewrite every few years?
"Yes". I imagine it's a bit of both. Would shops doing client work worry about the long term maintenance about the work they are doing? Using Bootstrap, knowing it will be end of life in 1-2 years is probably in their favour. They get to use a shiny new framework to impress the client and can sign a rewrite/tech debt contract in 4-6 years!
My personal experience with Bootstrap is that the upgrade story is fairly reasonable and we also have software on Bootstrap 2 still running just fine. It was the style of the time and the app shows it, but there's been no need to rewrite that portion.
I can't say I agree. I had a miserable time going from 3 to 4 because it also dropped Less support. Most of the blame goes to css but I do not welcome churn on a library like this.
With a strongly typed API, most of the breaking changes cause errors so you can just go through and fix them. With code then you can also cover behaviour regressions with unit tests.
With css / bootstrap, you get zero errors, just a broken visual layout. You get a lengthy migration guide https://getbootstrap.com/docs/4.4/migration/ that you have to manually go through line by line, searching the codebase for each affected feature. The affected features are not single css classes but how multiple different css classes interact in hierarchies with changing requirements on the DOM structure. Fixes don't just mean updating the css but changing the DOM too. So much for css separating appearance from content.
Some of the breaking changes are things like changing fundamental default sizes of things like fonts or media-queries which for a given site are not things you can change willy nilly so if you need to preserve the existing appearance you now need to rewrite very basic things and decide how much pain you going to through by fighting Bootstrap's changed defaults.
You only know you are actually done by looking at the appearance of every part of the site, on all the relevant devices, in all the relevant conditions so that each media query triggers. Ugh, it's a nightmare.
> My personal experience with Bootstrap is that the upgrade story is fairly reasonable and we also have software on Bootstrap 2 still running just fine. It was the style of the time and the app shows it, but there's been no need to rewrite that portion.
Same here. Our app has been on 2.3.2 for the longest time. Just not a high priority to update it at the moment, and not to mention it's just a giant effort.
Other than not getting newer features, are there any reasons you'd need to upgrade? Are there security concerns? I guess maybe some XSS with some of the JQuery stuff but that should be easily mitigated.
Seems like a CSS framework is the least likely to need constant patching.
I still have a ton of sites on Bootstrap 3 and know of a large number of “rebuild every decade” sites on 3. The nice thing is at least with older versions, they tend to work okay for years with no maintenance.
That’s probably changing as the web incorporates more SPA type stuff.
I think you're right. I know lots of products built on 3 that have "migrate to 4" in their backlog but it's an easy one to push out... for years.
Part of this churn fatigue is that we depend on community support for a lot of these technologies. Support for something like .net or Java used to be rudiculously long, but as they've switched to OS-friendly development practices the pace of releases has increased and lifetimes diminished. Coupled with building on more and more shaky and temporal abstractions and a web app written today won't compile in 6 months.
I'd love to see a built-in dark mode! I develop a SaaS-type control panel and many of my users spend hours a day interacting with it. Requests for a dark mode have been increasing over the last year, but restyling every built-in Bootstrap component feels clumsy.
The beauty of Bootstrap is that it's easily tweakable with SCSS variables. If you do, make sure you use Bootstrap's color-yiq() function so you'll always have the same color/text contrast, in dark and in light mode.
Unsure how we'll tackle this overall, but we are looking at increased customization and variants for a handful of key components. This might be a mistake, and if so, we'll hope to hear it in the alphas so we can shift gears and do dark mode across the framework. That said, it could be too far reaching and mean it'd come in v6.
I've recently been working on a greenfield project with Bootstrap and I've been really pleased with the development velocity by the core team. They're beginning to implement a icon library too, which will complement nicely with the built-in components they already have. They're quite responsive to issues as well, giving me confidence I need to build on top of this framework for the long haul.
Bootstrap is more than the layout. Its good having good looking buttons by default and cards and toasts and so on with less mucking around.
I find if I dont use a framework like this then I invariably end up creating my own with all these features and wishing I had used bootstrap from the start.
Its not for everyone but for myself (very small teams or just myself and sometimes one other person), its invaluable for getting things done.
What do you mean by 'significant' update? Version 0.90 was released just recently, and there are continual slow and steady updates that come through. For a CSS framework, that seems quite appropriate.
I used a good bit of Bulma prior to jumping on the Tailwind train when it released. While it was a very quick way to get a nice looking page out of the box, the design choice of aggressively over-specifying selectors[0] made it incredibly frustrating to work with, especially paired with utility classes (e.g. Tachyons).
I manage almost 10 projects that use different frameworks and at this point, I'd like to just standardize on something like Bootstrap. So it's less about one vs the other, more what's your comfort level.
But even within that, a couple use BS 3, a couple using BS 4, and now invariably some will use BS 5.
I don't think there's any way around doing a lot of maintenance grunt work nowadays with all this churn and constant API breakage. And it's a tough sell for many customers.
I run my blog on Bootstrap 4, and I don't have much skills for frotend/scss stuff. So I use bootstrap 4 out of the box with few customizations. I never understand the backwards compatibility model of Bootstrap. It broke significantly when I moved from some late-stage BS4 alpha to the stable version. I can probably assume it'll significantly break again? Maybe that's the beauty of BS, you just choose a version and stay there until it's impossible anymore?
With how the web has evolved over the years, we've been caught on the side of being too far behind and being too far ahead. We want to move faster and find the right balance. v4 was a bit of a nightmare scenario, and upgrading from v3 was nuts. v4 to v5 _should_ be much simpler by comparison. Still some breaking changes, but nothing like before.
And yes! Definitely something that you can theoretically run forever without issue. Browsers basically have to keep supporting the historical properties, quirks, etc, so once you've built it, you're largely good to go :).
I had the same issues with major breaks between Bootstrap 4.x alphas and betas, but to be honest, their migration changelog [1] was truly helpful and you could simply search and replace most changes.
It's the price of choosing the bleeding edge I guess.
Nope! We're a small distributed team that works on Bootstrap when we can. Jacob and I created it at Twitter, but we took it with us in 2012 when we both left :).
Here is a question for people who are more knowledgeable than me.
I remember reading somewhere that a library is a bunch of functions you call in your software whereas a framework is a software that calls your functions. I'm obviously paraphrasing but you get the idea.
Bootstrap is called a CSS "framework" but as far as I can tell, the user calls the predefined classes if putting them in an html element's attribute can be considered a "call". Or maybe CSS with its selectors is the one calling the HTML by, dunno, crawling it.
- a framework provides a structure you fit your stuff into or build off of
- a library provides functionality you can fit into the structure of your code however you see fit
In the case of bootstrap, I think they use the term framework because it supplies layout and styling patterns you fit your page/app into. E.g., the grid, containers, forms with form-groups, the predefined "primary", "secondary", ..., styles, etc.
As with many definition terms there are multiple answers to what is a library and what is a framework, and the phrasing you've described is one way, but another axis that is probably closer to why Bootstrap chose the name "Framework" over library is: "do one and only one feature" versus "generously include the kitchen sink".
Often in CSS terms a CSS library is focused on a specific "vertical": a grid library provides everything you need for a grid. Whereas a CSS framework generally focuses on providing a little bit of everything ("horizontal"): Bootstrap has a grid system (library), but also a button library, a modal popup library, etc, all bundled together in a one-stop shop for developer convenience.
If you use it as just a CSS include then I agree with you in a sense.
But typically or rather optimally you use it with Sass/SCSS and override Bootstraps variables so Bootstrap generates its classes based on your input.
Related:
One of the goals of Bootstrap 5 is for example a stronger shift towards utility (atomic) classes. In 4 you can already generate their utility classes based on your variable declarations. In 5 this will get more powerful and the API becomes cleaner.
Another goal is to improve documentation for users who integrate with Bootstrap SCSS this way.
That's one definition. Another valid definition of a framework would be something that is a fundamental part of your project, or something you build upon, whereas a library would be something that you use to enhance a particular part of a project.
Bootstrap would seem to fit that definition in most cases.
To me a library is a bunch of functions that you can drop in, whereas a framework is an opinionated implementation of functionality that requires you to adapt to it.
First off, congrats and thanks to the Bootstrap team for a wonderful and well-made CSS and design / UI framework. I love it and I have to say it makes it so easy for a developer without design experience to build a website or web application that actually looks good :)
One question about release dates though: I remember watching the Bootstrap v4 progression from alpha -> beta -> release and I remember it took much longer than I thought it would. Just curious when we can expect the stable release version of v5 to drop?
Who knows how long this will take with the pandemic (and I work full-time at GitHub, and most of the team has full-time jobs), so all that does slow us down. That said, this should be faster than v4's development, and with fewer and smaller breaking changes by comparison.
I wouldn't start getting into the weeds with it in any kind of production environment until the beta though honestly. Release date for stable v5 is hopefully months away.
Which results in much less js code shipped and better perf. Browsers have caught up to (almost) everything jquery does. Thanks jquery, you served us very well!
I agree the API and the chaining are nice in some cases. And I agree that native JS is less pretty.
But I personally don't use it anymore since a while now. I either use React/Next + Redux if they are a good fit, or just plain native JS otherwise. JQuery doesn't solve enough of a problem (anymore) for me to be worth loading and adhere to.
If I do the latter then my code is often structured the same (per module).
- defining some utility functions
- setting up state and state-transformation / "top-level" functions
- getting the DOM elements (once)
- defining DOM mutations on those elements based on the state, usually call these "render" functions.
- registering event handlers on those elements which call the top-level functions and pass the new state to the render functions.
I know this is kind of a dumb/rigid approach, but it suits me well. There is not much obvious use for jQuery here. The only place where the nice chaining API would be useful are the DOM mutations (sometimes) but I haven't found this to be a huge deal.
As soon as I need to do more AJAX, inserting/removing whole Nodes/NodeLists, have more involved state management and policy then jQuery doesn't help anyways and a more sophisticated framework is more fitting (like React/Next + Redux).
It's debateable whether jQuery is a library or a framework. It's definitely at the frameworkey end of libraries of the libraryish end of frameworks.
But if you'll admit the terms get murky in the middle then I think it's not controversial to assert that a framework can depend on a library without it offending the gods.
So we're very quickly in the territory of "things reasonable people could disagree about" and quite far away from "glibly asserting that something isn't even up for debate".
I hope with the support for custom properties (aka CSS variables) for everything we can implement dynamic light/dark themes without custom CSS overrides. v4 required this because some colors were manipulated at compile time in Sass and therefor you couldn't set them to a CSS var
Going for simple JS might make more sense for simple websites with broad deployment, so I can see the arguments against TS here. Like choosing CSS over SCSS for simple portability. Still, it would be a fun/simple type driven project to browse through, had they chosen it.
Can you elaborate on why TS would be "less accessible"? It was my impression (not a js dev) that TS is pretty close to JS in syntax, just with some additional sugar to ensure types and what not -- meaning that someone that knows JS shouldn't have a problem understanding what's written, and should need only a small amount of effort to contribute.
It’s javascript in the end so why complicate it more? Less people know typescript, making source less accessible, i.e you first need to understand typescript to understand the code. Also you’ll have several more layers of indirection: compiling, transpiling, bigger toolchain. In the end - why should not the latest javascript be enough?
In the old times javascript was apparently not good enough without jquery - but why add another dependency of similar ilk now that jquery is removed?
I am averse to complicated javascript franken toolchains because they don’t age well. Better to stay vanilla.
I don't mean to question your abilities here, especially since I don't write JS myself, but I don't recognize your view of TypeScript.
> why should not the latest javascript be enough?
The fact that TypeScript exists in the first place and is extremely widely used by large organizations would seem to indicate that the latest javascript is not "enough".
> In the old times javascript was apparently not good enough without jquery - but why add another dependency of similar ilk now that jquery is removed?
Again, I'm not a JS dev, but it seems very dubious to equalize jQuery with TypeScript. They have completely different objectives and achieve completely different things.
> I am averse to complicated javascript franken toolchains because they don’t age well. Better to stay vanilla.
I can understand and appreciate the sentiment, but since most people seem to agree that the lack of static typing in JavaScript is something that can introduce bugs and unexpected behavior, and the user base of TS is quite large (made by MS, used by many large organizations[1]), I would agree with what most users of it probably would say, that the trade-off is by far worth it.
I have used typescript for production but i am not convinced it adds to the experience. If you are not a js dev, why do you worry about typescript? It seems like you are in the static type camp and want to make a case for that. In the end the runtime is not typechecked anyway so it’s a false security.
Jquery was written to overcome limitations in js browsers as typescript was written to overcome the typing limitation.
It seems again you like the typed lanuage political agenda. I am on the other side - i like dynamic languages. I appreciate that there is another side - i just don’t agree.
There are lots of programming languages and tools that are in wide use by large organizations. That doesn’t make them better or worse.
It just comes down to politics, and I want to make a case for the dynamic camp.
Remember coffeescript? Just a waste of time and effort.
Just out of curiosity, do you write HTML5/CSS inside a text editor with live reload or have you switched to builders like Bootstrap Studio, Webflow, Pingendo etc.?
Asking since I'm converting a design into a template for a Symfony app and when coding with Bootstrap from scratch I'm a bit lost. Even doing basic things like sticky left sidebar and overlapping top navbar (basic admin panel layout) requires lots of StackOverflow digging. Should I give up and just buy templates?
I simply have the documentation open, which is really excellent and doesn't require any other sources.
I begin with copying one basic example and building from there.
Then I'll tweak the HTML+CSS live in the browser's DevTools until I feel I understand what's happening in the CSS, I switch back to IntelliJ and bake my tweaks into my own custom SCSS extending bootstrap's classes and building on them.
Never bought templates as I have the feeling that template authors don't really have the time to really grasp the concepts of bootstrap, nor do they care, and simply tend to pile tons of rules until they have some effect they desire.
I felt it's always easier to simply read the docs, and occasionally jump into IRC in ##bootstrap or #css or their Slack when I'm stuck.
> Even doing basic things [...] requires lots of StackOverflow digging
It's mostly a matter of getting used to it. If you do it by hand, you tend to better understand the building blocks and it gets easier to compose them into whatever you want. Same as any language or framework, really
> Should I give up and just buy templates?
Give up, no. Buy templates, why not. They're usually fairly cheap and if it saves you hours of coding, that's fair enough (I'm food with frontend and I buy templates sometimes). But if it's a skill you need, it's probably a better investment to hone it than to work around it
As a novice in front end stuff, i have tried Bootstrap Studio but i found it to complicated to use and have since coded my websites through documentation and examples.Perhaps if i have stuck through the learning curve i would prefer it.
Templates can help you a lot but be careful.Extending the template to fit your needs does require work and knowledge
Sass (scss) & overriding default variables/lists/maps & some custom class/mixin generation (via nested each & includes). I personally like to default to utility classes (builtin + custom) and only build components when they get apparent during development.
Today, I'd probably just use parcel and reference bootstrap from source in an index.scss from my index.html file... Not the fasted performance option, but works well enough and quickest getting started option for more modern projects.
I'm not really sure about accessibility, but I've been having a good time with boba.css. It's on the smaller size and is CSS only, but, at least for me, it has every feature I want.
This is good work by the team. For CSS beginners like me
it helped to start with a nice looking website. Thanks.
I would have loved if they kept the CSS classes same between different versions. I feel there are always some unnecessary renaming of classes with major version changes. I have close to zero knowledge on CSS, I might be missing the point. Two years feels a bit too quick for the release, I wish they slowdown and not release another major before 5 years.
> I would have loved if they kept the CSS classes same between different versions.
I'm not great with CSS either but I recently had to implement some very basic Bootstrap functionality in an environment that required Bootstrap 2 (sorry everyone), and FWIW I thought it actually helped that class names were different because it made it very obvious that I was working with a completely different release than most guides were written for, so I expected breaking changes, and any searches I did do for the "old" names gave me correct results. So in that sense, different class names as a type of "version locking" does make sense I guess -- and it perhaps also stops people from lazily just installing a breaking version of Bootstrap and expect it to work.
> CSS’s grid layout is increasingly ready for prime time, and while we haven’t made use of it here yet, we’re continuing to experiment and learn from it. Look to future releases of v5 to embrace it in more ways.
I was actually expecting that the next major Bootstrap version would come out way later and fully embrace the CSS grid. But I suppose they are choosing a more gradual adoption and testing of waters to stay compatible with B4 websites.
I think we need to get to the point where regardless of the build script, Bootstrap will make the perfect foundation for a design system. I defecated to ZURB long before this was a deal-breaker, but now I almost prefer to reinvent the wheel. Getting on board is quite a commitment, compared to just wrapping react-select, or something alike.
Reinventing the wheel is awesome! More people, myself included, need to build from scratch and learn ourselves every now and then. Definitely interested in more tooling around helping folks getting started, too. Spent a lot of time on the customizing side for this release.
I use a very old version of Bootstrap on almost all of my web sites. As part of my COVID-19 lockdown decision to clean up things, I am going to do a small test with the new alpha, and update. I have also been taking my old eBooks, one at a time, and updating those. It feels good, sort of like spring cleaning, organizing my garage, etc.
I'm currently working on a personal project and I was planning on using angulardart + tailwind (the css part only) but I will definitely check if the css side of bootstrap 5 might not be a more productive option. Good work regardless and thanks for all the effort.
It's SCSS, a language that compiles to CSS. That whole section has almost nothing to do with CSS, though. That's array syntax for holding a set of utilities to be used later in the code.
Sub menus are really hard to do right on a mobile device.
Mobile is important at least since Bootstrap 3, when Bootstrap became "mobile first" (e.g. you define breakpoints with the smallest screen in mind by default, adding exceptions for wider screens)
After all, Bootstrap is, like the name suggests, a "bootstrap" for your own project, and if you think the accesibility problems that come with nested dropdowns are worth it, you're totally free to implement that, and even create a GitHub project with your CSS clases.
There's no reason your solution wouldn't be merged if you provide a truly novel approach to all the other failed approaches.
> Sub menus are really hard to do right on a mobile device
No, they are not. Bootstrap is too opinionated here by not supporting nested menus. There are plenty of use cases for them, a navigable sitemap or your common application toolbar for example.
Speaking of accessibility: I'm surprised that Bootstrap only cares little about this important topic, especially considering implementing it on websites is required by law in many countries.
I mean, submenus are difficult. Even single-element tooltips are complicated enough to warrant a dedicated library that Bootstrap uses: https://popper.js.org/
Nested menus are no easier to make generic. Or they can easily be too opinionated for the Bootstrap team's tastes.
Also I don't think dropping something from your API makes you more opinionated. Their solution would be opinionated by definition if they had one. Nothing stops you from building your own or anybody from building a library that solves the problem. If you think it's easy, then you sound like the right person to take on the challenge.
Citing mdo, https://github.com/twbs/bootstrap/pull/6342#issuecomment-115... : "We haven't seen anyone using submenus in meaningful ways and the code necessary to make them work well is just too much overhead. Submenus just don't have much of a place on the web right now, especially the mobile web."
Now that we have CSS Grid and Flexbox, what is the rationale for using Bootstrap? Or, what is the benefit of using Bootstrap that I don't get using CSS Grid and Flexbox?
Sensible defaults. Consistent developer API. A great big pile of components that can dropped in and reskinned rather than having to be rebuilt each project. Easy theming. Accessibility, mobile... I dunno, it just seems to do the right thing from the start.
Here's my answer: after several years going bootstrap-free and doing everything by hand, I realized I just ended up writing my own bootstrap equivalent, so now I just use Bootstrap or TailwindCSS.
I don't use Bootstrap for the design or the components, I use it for the layout and utilities instead of building my own, and I code the design on top of it.
Unless you are going to write bespoke grid/flexbox logic every time you want to position anything or having to sync up a bunch of grid-template-area definitions, you may find yourself building a more dynamic generic grid system that abstracts the details away. Well, that's something that Bootstrap's Row/Col system does.
I am surprised I was downvoted too. I’ve never used bootstrap so I thought my question was a simple request for information. Apparently all the bootstrap users took it as a personal attack.
Please don't do things to make titles stand out, like using uppercase or exclamation points, or saying how great an article is. It's implicit in submitting something that you think it's important.
(Submitted title was "Bootstrap 5 alpha!", which HN's software correctly changed to "Bootstrap 5 Alpha", which was then edited back to "Bootstrap 5 alpha!", which we then edited back to "Bootstrap 5 alpha".)
It seems clear to me that the site guideline I quoted covers that case?
Even the title guideline ("Please use the original title, unless it is misleading or linkbait") implies that exclamation points should be taken out, since they're baity.
Arguably in this case the submitter was just trying to preserve the original title, which ends in a single exclamation mark. Site guidelines aside, a message explaining automated edits might be of help in these situations.
Well, in their defense, it was a single exclamation point not exclamation points, so if we're getting technical you should wrap your guidelines text to read "exclamation point(s)"
I'm really sick of title editorialization and the constant jockeying in the comments to editorialize the title. It's gotten really ridiculous and tiresome. Link post titles should just be pulled from the target's <title>, because this site can't handle it anymore. If the target page has too many exclamation points in its title, then I guess that link can't be on the site. It would still be better than this.
I guarantee, though, that the solution you mention would make the problem worse. Actually, it's not viable at all, because there's way too much variance in what people put in <title>. It's an HTML jungle out there. But even if you could halfways do it, the titles on the front page would then be so provocative that title fever would be much worse than it is now. And of course there would be a gaping loophole for people to say whatever they wanted on HN's front page just by putting it in <title>. Don't think that wouldn't get abused!
The question is how to minimize all the offtopicness, nitpicking, and bikeshedding that flares up about titles. HN's approach is: (1) use the article's original title unless it is misleading or linkbait; (2) failing that, edit the title to be accurate and neutral, preferably using representative language from the article; (3) if users object, flex until the objections subside; (4) keep the front page 'bookish' (pg's original word).
This is basically an optimization problem (note the word "minimize" above). We learned (3) through trial and error as the best solution so far: https://news.ycombinator.com/item?id=17496011. It would seem to have an obvious vulnerability: what if some users demand one change while other users demand the opposite change? Then we'd get a non-converging sequence and the objections would never subside. In practice, though, this almost never happens, and if it does then you can point out that it's happening and people will accept a best-faith arbitrary choice.
There's a deeper aspect too. The passion for titles is so intense that if we simply flex in response to objections, people feel heard, and immediately feel better. So it doesn't matter so much what the title edit precisely is, as long as it's good enough, because it demonstrates that there is an outlet for those feelings and that readers can actually affect the state of HN's front page.
As much as I hate AMP pages I have been forced to use it due to SEO reasons and bootstrap 4 sites aren't AMP comptabible as yet. They exceed the 50kb css limit by AMP.
There have been various attemps(1) to do it but nothing more be more amazing than to have in-built support for it.
Even if the AMP project is misguided mess the 50kb limit on css is still a good goal for mobile sites.
