Bootstrap 5 alpha(blog.getbootstrap.com)
blog.getbootstrap.com
Bootstrap 5 alpha
https://blog.getbootstrap.com/2020/06/16/bootstrap-5-alpha/
274 comments
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.
Thank you! <3
> accessible
I agree with all the points except that one. The last time I've checked [1] it was "above avarage" but definitely not fully accessible.
[1] https://darekkay.com/blog/accessible-ui-frameworks/
I agree with all the points except that one. The last time I've checked [1] it was "above avarage" but definitely not fully accessible.
[1] https://darekkay.com/blog/accessible-ui-frameworks/
[deleted]
Just to express Big Thank You to Bootstrap team and contributors for everything over years of hard work.
Productivity, stability, consistency and joy to work with!
Thank you
Productivity, stability, consistency and joy to work with!
Thank you
Accessibility can't be stressed enough. I have worked with many big companies that want a small project/initiative for their users.
They always want these things, at minimum:
* Data security/compliance (GDPR, CCPA)
* Accessibility (WCAG 2.1)
As much as my team would love to just make every app in React or whatever. I always just say:
No. They want a CMS. Just make it with Django and Bootstrap. Then we'll be done with it in a couple weeks and you can all go back to your own stuff..
Django + Bootstrap gets us an incredible amount of accessibility just right now of the box. Invaluable for small development shops!
They always want these things, at minimum:
* Data security/compliance (GDPR, CCPA)
* Accessibility (WCAG 2.1)
As much as my team would love to just make every app in React or whatever. I always just say:
No. They want a CMS. Just make it with Django and Bootstrap. Then we'll be done with it in a couple weeks and you can all go back to your own stuff..
Django + Bootstrap gets us an incredible amount of accessibility just right now of the box. Invaluable for small development shops!
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.
[1] https://getbootstrap.com/docs/4.1/getting-started/accessibil...
[1] https://getbootstrap.com/docs/4.1/getting-started/accessibil...
Do you use the Django apps for Bootstrap or include it on your own? How do you do the Django form <-> Bootstrap integration?
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.
[deleted]
> Django + Bootstrap
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?
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?
Thank you! <3
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.
I'll definitely give it a shot on a small project though.
When I first heard that jQuery is gone, it made me hope that Bootstrap could work directly with Vue without needing to use BootstrapVue.
But then I realized that it's probably still doing direct DOM manipulation, which is what makes it incompatible with Vue I think?
But then I realized that it's probably still doing direct DOM manipulation, which is what makes it incompatible with Vue I think?
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'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.
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).
Yes they can. Libraries like reactstrap and sveltestrap do just this.
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).
You're probably better off with BootstrapVue (or one of the React equivalents) because they're doing dom manipulation...
The libraries based on bootstrap should just be rendering components with matching classnames etc.
The libraries based on bootstrap should just be rendering components with matching classnames etc.
You don't need to use BootstrapVue at all. For things like Modals just add the appropiate divs and change classes in the same order.
> TailwindCSS
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.
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.
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.
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.
30KB is still absolutely massive in terms of raw CSS
Like I say though, that's prior to gzip/Brotli. It's usually < 10KB actually being downloaded.
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.
> 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.
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.
Good job you can combine approaches by inlining the functional classes you've used and serving the remainder normally then.
Can you please explain to a non-web-dev - why such a fuss about dropping jQuery? AFAIK it is just a small utility lib.
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.
JavaScript has improved so much you don't need jQuery anymore.
Its an extra (30kb) dependency for many projects that can solve the same problems using vanilla javascript with the same amount of friction
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.
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.
And many projects/people don't care about not supporting anything but the latest chrome, so yes, for them it's a legacy.
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 ?
its not about js compatibility it is more about platform / browser specific glitches
religion mostly :)
Got recommended this twice in the past week. How does it change your workflow? Also is it as quick to get something started as bootstrap?
Bootstrap no longer depends on jQuery and we’ve dropped support for Internet Explorer.
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.
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.
I did my last small project with vanilla js and the ugliness of the native APIs reminded my how lovely jQuery is.
Do the maths - if the file size isn't a problem then go for it. Life's too short to be the victim of fashion.
Do the maths - if the file size isn't a problem then go for it. Life's too short to be the victim of fashion.
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.
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.
There is very little functionality JQuery offers that the modern browser DOM API doesn't provide with more robust performance.
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.
Unless, of course, you care about IE...
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.
Unless, of course, you care about IE...
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.
Did this comment onwards miss
"I did my last small project with vanilla js and the ugliness of the native APIs reminded my how lovely jQuery is" or am I seeing wonky here
"I did my last small project with vanilla js and the ugliness of the native APIs reminded my how lovely jQuery is" or am I seeing wonky here
Yes, but the native APIs are a PITA.
At they? I don't write much js but always found the native apis to be the quickest way to implement functionality when I need to
Yes, nearly every native API is uglier/longer/more inconsistent than jQuery equivalent.
not like they used to be, youngster*
* veteran of the original browser wars
* veteran of the original browser wars
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!
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!
Seconded. $(document).ready(fn) is far more easier and comprehensible than document.addEventListener('DOMContentLoaded', fn, false).
Even if I'm aware of the latter, I refuse to use it when former is available just for the sake of being "PureJS trendy".
Even if I'm aware of the latter, I refuse to use it when former is available just for the sake of being "PureJS trendy".
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.
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.
I‘m new to frontent development. I had a lot of fun with jQuery so I‘m wondering: What‘s the problem with it? Do people now ise vanilla JS?
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
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
In which situations is React unsuitable? I learned web development starting with React and have been using it for everything since.
React is meant to simplify application development, specially suited for single-page apps (SPAs).
For a normal/small website, there is no need for a framework like that which adds unneeded complexity.
For a normal/small website, there is no need for a framework like that which adds unneeded complexity.
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.
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.
Throwing together an API in .NET Core and a website consuming that API in React takes less than 5 minutes to get going.
Did you ever have to optimize for SEA/SEO/Page speed?
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.
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.
Hacker News, reddit, any blog, any newspaper.
You got to be kidding, HK? Newspaper? i rather choose SSR and got more SEO friendly than interactive components on screen for what? Newspaper?
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.
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.
What is the problem with jquery exactly? What is a person that hates the reactive frameworks with a passion to use nowadays?
Just because they dropped the jquery dependency doesn't mean you can't use jquery anymore.
I use jquery. But I don't get what the fundamental problem with it is to be needed to be dropped. Or its use to be frowned upon
If you develop an Angular/Vue SPA you may want to use Bootstrap for styling but have no need for jQuery.
What is wrong with reactive frameworks?
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.
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.
> 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.
Look into InertiaJS. Svelte/Vue/React become just the UI piece and everything else (routing, validation, etc) is handled server side
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.
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.
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.
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.
jQuery does still have a place for smaller websites IMHO. I really wish Intercooler (http://intercoolerjs.org/) had caught on more for such uses.
The author of Intercooler has a new project
https://htmx.org
https://htmx.org
Dang. The documentation links don't seem to work on Firefox Mobile.
That's strange. They work for me on Firefox Preview
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.
There is also Cash JS.
I have found that vanilla js is now cleaner than jquery for all my use cases.
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.
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.
I have a feeling IE11 will be around a while.
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.
I have a feeling IE11 will be around a while.
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.
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])
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])
IE11 support is still common. Almost nobody is supporting anything lower than that. I expect that will be gone in a couple of years.
[deleted]
Mostly ignored now. Reddit's broken in IE11 (at least the simulated IE11)
>> we’ve dropped support for Internet Explorer.
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.
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.
BS4 being in maintenance doesn't mean it will cease to work. I imagine they'll just continue to use BS4 (or 3, or 2, even...)
The thing is, you never really needed jQuery. You could always add whatever JS-powered stuff you needed back in with vanilla.
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.
> we’ve dropped support for Internet Explorer.
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.
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.
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.
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.
Bootstrap 4 is not going to be EOL anytime soon according to mdo, so you are good for a few more years.
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.
I feel you! Good news is IE11 is going end of life soon and it's increasing less of a concern. Legacy Edge is still there to fill the void though :D.
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?
[0] https://github.com/twbs/release
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?
[0] https://github.com/twbs/release
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 :).
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 :).
THANK YOU for keeping version 3 alive.
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.
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.
"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.
> fairly reasonable
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.
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.
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.
Seems like a CSS framework is the least likely to need constant patching.
Very happy to hear this for both of you! Bootstrap 2 was life changing for us to create and share :). <3
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.
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.
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.
Read more about Bootstrap's color-yiq() here: https://getbootstrap.com/docs/4.5/getting-started/theming/#c...
Read more about Bootstrap's color-yiq() here: https://getbootstrap.com/docs/4.5/getting-started/theming/#c...
Do you use CSS or a preprocessor like SCSS? In the later it is mostly a matter of changing a few variables.
You can create a dark mode by changing a few variables, and all of the Bootstrap components will still look right? Can you show me how?
Yes.
https://bootswatch.com/darkly/
It's just a matter of setting some Sass variables.
https://getbootstrap.com/docs/4.1/getting-started/theming/
https://bootswatch.com/darkly/
It's just a matter of setting some Sass variables.
https://getbootstrap.com/docs/4.1/getting-started/theming/
[deleted]
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.
Can your users install extensions? Dark Reader[1] works well enough that I don't care if websites offer dark mode, they are dark for me.
[1]: https://darkreader.org/
[1]: https://darkreader.org/
CSS custom properties would be a step in that direction. Although native dark mode support would be nice.
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.
The argument against Bootstrap was the jQuery dependency, but that's now gone.
So what is the difference between all these front-end frameworks if they are all dropping down to base HTML + CSS?
So what is the difference between all these front-end frameworks if they are all dropping down to base HTML + CSS?
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.
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.
That's what most of these frameworks also do. (e.g. Bulma, which specifically bills itself as a no-JS framework: https://bulma.io/ )
Bulma is great but hasn't had significant updates in years it seems -- I would love to get some updates (I use it in multiple side projects)
Isn't that a good thing? runs away
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).
[0]: https://github.com/jgthms/bulma/issues/2292
[0]: https://github.com/jgthms/bulma/issues/2292
from what I've gathered: look, feel, and `class` naming conventions...
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.
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.
To clarify, v5 removes jQuery, but not our JavaScript—we've rewritten everything to work without it.
... CTRL+F, 'compat', no results. Oh crap.
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?
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 :).
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 :).
Thanks! Having an answer from the project owner is super valuable.
Well you can't really expect much about breakages or backward compatibility when you use an alpha, that's kind of the deal.
Just wait for the stable release to upgrade? Or don't upgrade at all, it's not the sort of thing that you absolutely need to keep up to date anyway.
Just wait for the stable release to upgrade? Or don't upgrade at all, it's not the sort of thing that you absolutely need to keep up to date anyway.
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.
[1] https://getbootstrap.com/docs/4.5/migration/
It's the price of choosing the bleeding edge I guess.
[1] https://getbootstrap.com/docs/4.5/migration/
[deleted]
You can donate to Bootstrap via https://opencollective.com/bootstrap
In case anyone from bootstrap is reading this: The opencollective icon in the top bar on https://icons.getbootstrap.com/ doesn't link to opencollective (it links to /). The same header icon on https://icons.getbootstrap.com/ works fine.
Their website is also open-source, so I just submitted a pull request [0]. Thanks :)
[0]: https://github.com/twbs/icons/pull/302
[0]: https://github.com/twbs/icons/pull/302
used this for my website too https://serabut.com
Isn't bootstrap owned by Twitter? I love what they're doing but I don't really know if they need more money
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.
Can you help me? I'm confused. :)
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.
Can you help me? I'm confused. :)
I would say:
- 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
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.
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.
[deleted]
You're right, but bootstrap forces your html to have a certain structure (everything should go in a container div, in columns or lines, ...)
So it is more a framework in that aspect in my opinion.
But it had also "components" which are more library-like (buttons, bars, cards, tooltips...). So I'd say it's both.
So it is more a framework in that aspect in my opinion.
But it had also "components" which are more library-like (buttons, bars, cards, tooltips...). So I'd say it's both.
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.
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.
[deleted]
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.
I don't think there is a really solid standardization on what makes something a library versus a framework. Particularly not with regards to CSS.
The two terms certainly don't offer much more than a suggestion of what's inside the shrink wrap.
The two terms certainly don't offer much more than a suggestion of what's inside the shrink wrap.
I don't agree with this definition.
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.
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?
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?
Thanks! <3
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.
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.
As a result we now have the most homogeneous, boring looking web.
"we’re now able to drop jQuery as a dependency", interesting
... by replacing large parts with a native jquery-like implementation.
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!
> Browsers have caught up to (almost) everything jquery does.
For me jQuery is mainly about an elegant, chainable API and all the DOM tools I'm likely to need on hand.
I understand there's a bit of bloat but there's also lighter jQuery-alikes.
I tried vanilla js recently and the native DOM APIs are fairly ugly in comparison with none of the quality of life stuff I got used to.
What am I missing?
For me jQuery is mainly about an elegant, chainable API and all the DOM tools I'm likely to need on hand.
I understand there's a bit of bloat but there's also lighter jQuery-alikes.
I tried vanilla js recently and the native DOM APIs are fairly ugly in comparison with none of the quality of life stuff I got used to.
What am I missing?
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).
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).
The point is that one framework should not depend on another. If you like jquery, no-one is stopping you using it.
I wasn't specifically talking about Bootstrap. Parent post seemed to be making a general point about jQuery.
> The point is that one framework should not depend on another.
It's not hard to think of counterexamples unless you have very particular definitions of "depend" and "framework.
> The point is that one framework should not depend on another.
It's not hard to think of counterexamples unless you have very particular definitions of "depend" and "framework.
The counter argument would be that one framework should depend on another. Good luck with that.
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".
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’m not sure whether you’re debating the point or the terminology.
I'm disagreeing with your fundamental point. It sounds truthy but I don't think it withstands scrutiny in this case.
In this specific case, Bootstrap does not need to depend on jQuery. The proof is that version 5 doesn’t.
As arguments go, it doesn’t get any clearer cut.
More fundamentally, interdependency is a disease infecting the entire JS ecosystem. The antithesis is the antidote.
As arguments go, it doesn’t get any clearer cut.
More fundamentally, interdependency is a disease infecting the entire JS ecosystem. The antithesis is the antidote.
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
I'm surprised/disappointed they didn't embrace CSS grids. I've found them to be so much better to work with than Bootstrap grids
I guess browser support is not good enough. They just dropped IE11, after all.
Probably that will be the change for Bootstrap 6.
Probably that will be the change for Bootstrap 6.
It's too bad they didn't rewrite the JS in Typescript. That would have been neat. But congrats on improving performance and code quality nonetheless.
Looks to be ES6 class driven: https://github.com/twbs/bootstrap/blob/main/js/src/dropdown....
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.
Looks to be ES6 class driven: https://github.com/twbs/bootstrap/blob/main/js/src/dropdown....
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.
Why? Less accessible that way. I would have liked it to be in clojurescript myself but thats even worse!
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.
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.
[1]: https://stackshare.io/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.
[1]: https://stackshare.io/typescript
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.
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?
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.
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.
> inside a text editor with live reload
this one
> 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
this one
> 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.
This is for bespoke designs. YMMV
This is for bespoke designs. YMMV
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 guess this is a pertinent question in the context of such announcement posts.
What are the current alternatives for Bootstrap that provide:
* a good set of defaults with a sensible/easy grid system
* a modern look with readable typography and color choices
* a good enough set of controls
* support accessibility out of the box
* are leaner in size
* reduce/avoid the use of JavaScript (preferring CSS where possible)
* and lastly, very easy to get started with (and have great documentation)?
What are the current alternatives for Bootstrap that provide:
* a good set of defaults with a sensible/easy grid system
* a modern look with readable typography and color choices
* a good enough set of controls
* support accessibility out of the box
* are leaner in size
* reduce/avoid the use of JavaScript (preferring CSS where possible)
* and lastly, very easy to get started with (and have great documentation)?
Bulma is a great alternative: https://bulma.io/
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.
The shift towards atomic/utility classes is what keeps this framework alive in my eyes. The productivity boost is quite massive.
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 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.
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 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.
There's some grid bugs out there, but dropping Internet Explorer is probably more 'drastic' than CSS grids.
What are some of the coolest bootstrap projects you all have seen? I haven't used Bootstrap in years, but would love to see some of the creativity.
I have only used bootstrap recently through implementations of commercial web template packages.
These are pretty amazing, see Color Admin and Inspinia.
These are pretty amazing, see Color Admin and Inspinia.
I have been using Bootstrap for 8 years now and I am very thankful for your work.
Removing jQuery dependency is a big move, one that is welcome too.
Removing jQuery dependency is a big move, one that is welcome too.
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.
I really hope you meant defected!
Well frontend devs love marking their territory you know.
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.
When is the right time to upgrade to a new bootstrap version? Anyone had bad experiences upgrading to version 4 too soon?
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.
Can anyone explain the code in the Utilities API section?
What language is it?
I don't recognise it and this line
What language is it?
I don't recognise it and this line
$utilities: () !default;
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.
It's Sass. Compiles to CSS.
It !defaults a $utilities variable to an empty map (if it's not already set to something) and then merges some things into it.
If I had to guess, the snippet is showing you how to declaratively control how width and margin will change for a give class as it's resized.
It !defaults a $utilities variable to an empty map (if it's not already set to something) and then merges some things into it.
If I had to guess, the snippet is showing you how to declaratively control how width and margin will change for a give class as it's resized.
In case folks from the team are reading, I think you mean "our logo evokes the feeling of a rule set" (rather than "eschews").
Bootstrap. The people who removed sub-menus from Bootstrap 4 because it was deemed "too difficult". Not cool.
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.
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.
And accessibility is also a non-issue, see W3C's / WCAG's recommendations: https://www.w3.org/TR/wai-aria-practices/#menu
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.
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.
And accessibility is also a non-issue, see W3C's / WCAG's recommendations: https://www.w3.org/TR/wai-aria-practices/#menu
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.
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."
This is very opinionated.
This is very opinionated.
> No, they are not. Bootstrap is too opinionated here by not supporting nested menus
Agree 10x
Agree 10x
Makes me wonder about the jquery based interactive components like select2/chosen etc.
Funny thing that footer is broken.
I like bootstrap, but after playing with tailwindcss I prefer it.
I like bootstrap, but after playing with tailwindcss I prefer it.
You guys are the best! Thank you ! You have helped me so much in my career!
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.
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.
Decent looking typography and presentation.
why is this downvoted, I have the same genuine question
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.
Bootstrap is so much more than grid. It has plenty of useful components too.
I LOVE BOOTSTRAP!! Keep it up you'all!
I miss the 3D look and feel from 2.x
Some work for theme creators now.
The end of jquery is here
for me the best thing about v5.0 is the official RTL support!
145Kb ouch!
Please don't edit HN titles to break the site guidelines: https://news.ycombinator.com/newsguidelines.html. This has been first on the list of the submission rules for over a decade:
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".)
Also, please don't post the same story within minutes (https://news.ycombinator.com/item?id=23543329).
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".)
Also, please don't post the same story within minutes (https://news.ycombinator.com/item?id=23543329).
To be fair dang, the linked article does have an exclamation mark in the title. I imagine @mkurz just wanted to transcribe it.
Please don't do things to make titles stand out
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.
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)"
Actually I added the exclamation point because the original blog post title ends with one.
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.
It's certainly true that the dreaded title fever is a power no mortal can reckon with, only bow before:
https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
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.
https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
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.
Dang, should that be the case if that's the article's or blog post's exact title? Seems weird.
Sorry, won't happen again.
Missed an opportunity for "Sorry, won't happen again!" there I think.
They did, but HN software correctly removed the unnecessary exclamation point.
It did in my comment as well but I edited it back.
Add dark mode
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.
(1) https://www.google.com/search?q=bootstrap+amp+github
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.
(1) https://www.google.com/search?q=bootstrap+amp+github
You could use only some parts of Bootstrap, by including its SCSS files and commenting out ones you don't need.
Also, you could try css-purge to remove unused classes.
Also, you could try css-purge to remove unused classes.