Live data from Hacker News

Bootstrap 4 alpha

blog.getbootstrap.com

191–200 of 216 posts

Re: Bootstrap 4 alpha

#191
post #56

Does anyone know why they don't want to support right-to-left? I've seen tons of questions and posts about it over the years so I'm surprised that even with the next major release they aren't addressing it. Maybe I'm missing a perspective here though -- don't other people think that rtl should be a core capability of a framework like this? I'm also curious whether accessibility will be improved in 4.x.

They did propose to do RTL in version 3. They used some CSS flipping tech to do the bulk of the work.

However, it got abandoned, as far as I can tell from the outside, one of the people who manually creates an RTL version of Bootstrap basically called them imperialists for trying to automate something that was too precious to automate as it couldnt be 100% perfect and they caved to the pressure.

This is annoying for those that want to integrate CSS flipping into their own workflow.

Also, accessibility has been improving a lot recently, with PayPal and others contributing back and they announced Patrick Lauke would join their team to work on this.

Re: Bootstrap 4 alpha

#192
post #187
post #170

Earlier quoted context omitted.

I'm curios to know what doesn't work in rtl? Does bootstrap uses `margin-left` and stuff like that? It should be simple to fix it .some-class { margin-left: 1em; &[dir="rtl"] { margin-right: 1em; } }

It is a little more complicated because you have to omit the previous rule as well (and overriding it may interfere with other CSS rules), so it should be: .some-class { &[dir="rtl"] { margin-right: 1em; } &:not([dir="rtl"]) { margin-left: 1em; } }

Part of the problem is, that it's highly undesirable having to mark every node as rtl, when it should just be inerited.

Eventually (https://developer.mozilla.org/en-US/docs/Web/CSS/%3Adir) will be able to write it like this:

    .some-class {
      &:dir(rtl) { margin-right: 1em; }
      &:dir(ltr) { margin-left: 1em; }
    }
Right now it's probably easiest to load an additional stylesheet when a RTL language is used.

Re: Bootstrap 4 alpha

#193

One amazing thing to note is that in v3.3.5 (last stable) bootstrap.min.css was at ~123kb. The new 4.0.0 alpha bootstrap.min.css is at ~88kb. WOW. That's just amazing. Congrats to everyone who worked on this project. I'm always so impressed with the work done on it! Also, I want to add, I don't care where you land on the side of the debate whether to use Bootstrap or not, there is some very smart minds behind the pro…

>>> I don't care where you land on the side of the debate whether to use Bootstrap or not. I used to be totally against Bootstrap for a myriad of reasons. Then I got hired to build a fairly complex transactional application for a large health care organization under a tight schedule. Bootstrap allowed me to get a UI up and running super fast with all the components I needed, out of the box. It literally saved me hund…

It seems perfect for back end devs who need to do a bit of front end work. Makes things look good enough without a great deal of effort (certainly better than my own CSS would look).

Re: Bootstrap 4 alpha

#195
post #114
post #55

Earlier quoted context omitted.

For prototyping this is okay. But for production I try to keep bloat as low as possible. I see this as service to my customers. A fat ui framework like this adds its very own complexity and as soon as you want to go out of the crud box you will have to add your own styles anyway.

I try to get my bloat down, I just load the components which I'm going to use (most of the time it's the grid). There are some tools like purifycss [1] which can delete unused css 1: https://github.com/purifycss/purifycss

I didn't compare the results between Purifycss and this bash script[1] yet. But this alternative, not intent to compete, does mainly the same detection e.g. including dynamic class adding detection.

1: https://gist.github.com/50kudos/3028fac585eda85aea9a

Re: Bootstrap 4 alpha

#196
It's good to see that Bootstrap is progressing so fast. Frankly, some features like cards (or some variations of it) have been in Semantic-UI for a while now. It's a matter of personal preference, but like one of the other commentators have suggested, I've also replaced bootstrap in favor of Semantic-UI last year and never looked back.

For me, while developing a web app, it's the ability to come up with faster prototypes and then improve upon the UI at later stages that impresses me the most. Bootstrap was the first one to show me how much you can get done in very less time. But, Semantic-UI is simply miles ahead in this aspect. Semantic-UI is a full-fledged package - THe amount of custom CSS I write in comparison to a bootstrap project is way small say, 70-80% less. That's how good Semantic-UI is for me.

However, this new Bootstrap release actually excited me and I can't wait to test run it. Kudos and thanks to the team for this awesome release :)

Re: Bootstrap 4 alpha

#197

Earlier quoted context omitted.

I never got the hate for Boostrap or other frameworks. They definitely save a lot of time, and you don't necessarily end up looking like every other site if you put in some effort[1]. [1] http://expo.getbootstrap.com/

The dislike for Bootstrap isn't a hate for the framework and its components. It's the fact that most people do not customize it, and so nearly all Bootstrap sites _look_ like Bootstrap. Cartoonish and bulky rounded buttons, overly large menus, etc. The default theme feels equivalent to using Comic Sans MS. It's too Web 2.0 and not very professional looking. Properly theming (at least in 3.x) took a lot of effort. Jus…

Sweeping generalisation there on people in "real companies" not being able to use Bootstrap's default theme.

That's precisely what we do at my place. We don't do it for customer facing things, but for back office tools why would we spend time customising Bootstrap? There are better things we could be doing with our time.

Re: Bootstrap 4 alpha

#198
post #190
post #154

Earlier quoted context omitted.

The last time I looked at the PHP one, it compiled fine, but wasn't handling variables scopes in the same way of the JS one. This was a big deal for me.

Yeah, which is one of the reasons why I'm not a fan of Assetic in Symfony. The PHP versions of front-end build components are always lacking, unfortunately. But that's not a big deal in my opinion, you basically always need Node for a front-end application at this point for other needed tooling (Browserify/WebPack, Babel, etc.) so better to use the best-of-breed tooling and ignore Assetic as much as possible.

Yes, I tried using the React filter and failed. I switched to Gassetic (https://github.com/romanschejbal/gassetic) which is interesting but quite new and not well maintained. I couldn't make Reactify working with it which lead to way too long Browerify compilation time.

Next project I'll just use directly Gulp-or-whatever-is-fancy-then and find the simplest way to integrates it in Symfony/Twig.

Re: Bootstrap 4 alpha

#199

One amazing thing to note is that in v3.3.5 (last stable) bootstrap.min.css was at ~123kb. The new 4.0.0 alpha bootstrap.min.css is at ~88kb. WOW. That's just amazing. Congrats to everyone who worked on this project. I'm always so impressed with the work done on it! Also, I want to add, I don't care where you land on the side of the debate whether to use Bootstrap or not, there is some very smart minds behind the pro…

88KB? Pure CSS framework ( http://purecss.io ) is only 16.8KB!

Ok, so? I'm sure that Pure CSS has as many components and options as Bootstrap

Re: Bootstrap 4 alpha

#200
post #15

I'm a Boostrap lightweight, but I always respect an organization willing to drop support for old technology (IE8) and rewrite libraries with an improved technology (ES6).

Dropping old tech means projects/companies that require that support have to do it in-house. We need to support IE7+ for much of our UI, unfortunately, because of paying customers in hospital environments where upgrading is a nightmare.

So it's a good thing in that libraries can be leaner/meaner for everyone who doesn't need to care about old tech, but it also means the unpleasant work of supporting the old tech now has to be carried on by lots of different developers in lots of different companies, rather than being done well in one place.

If there's any possibility of keeping alive an "old-browser-support" branch of BS (like jQuery's 1.x and 2.x streams), that's rather better than abandoning it -- in theory we might be able to contribute some developer time into it.

Post reply on HN