Bootstrap 5 alpha
blog.getbootstrap.com
blog.getbootstrap.com
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.
Productivity, stability, consistency and joy to work with!
Thank you
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!
[1] https://getbootstrap.com/docs/4.1/getting-started/accessibil...
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?
I'll definitely give it a shot on a small project though.
But then I realized that it's probably still doing direct DOM manipulation, which is what makes it incompatible with Vue I think?
The libraries based on bootstrap should just be rendering components with matching classnames etc.
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.
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.
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.
JavaScript has improved so much you don't need jQuery anymore.
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.
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.
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.
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.
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.
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.
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])
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.
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.
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.
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.
* veteran of the original browser wars
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...
"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
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!
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".
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
For a normal/small website, there is no need for a framework like that which adds unneeded complexity.
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.
Throwing together an API in .NET Core and a website consuming that API in React takes less than 5 minutes to get going.
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.
There's one use case that might remain: the jquery plugins ecosystem. You can find many replacements on npm, but they're a bit less beginner-friendly.
I'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.
> 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.
I don't think it makes sense to use React and friends unless you are building Single Page Applications.
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.
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.
With that said, there's a lot to like in Bootstrap 5 to quickly throw together a site.
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.
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.
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.
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?
That’s probably changing as the web incorporates more SPA type stuff.
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.
"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.
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.
Seems like a CSS framework is the least likely to need constant patching.
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.
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.
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 :).
https://bootswatch.com/darkly/
It's just a matter of setting some Sass variables.
Read more about Bootstrap's color-yiq() here: https://getbootstrap.com/docs/4.5/getting-started/theming/#c...
So what is the difference between all these front-end frameworks if they are all dropping down to base HTML + CSS?
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.
But even within that, a couple use BS 3, a couple using BS 4, and now invariably some will use BS 5.
I don't think there's any way around doing a lot of maintenance grunt work nowadays with all this churn and constant API breakage. And it's a tough sell for many customers.
I run my blog on Bootstrap 4, and I don't have much skills for frotend/scss stuff. So I use bootstrap 4 out of the box with few customizations. I never understand the backwards compatibility model of Bootstrap. It broke significantly when I moved from some late-stage BS4 alpha to the stable version. I can probably assume it'll significantly break again? Maybe that's the beauty of BS, you just choose a version and stay there until it's impossible anymore?
It's the price of choosing the bleeding edge I guess.
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.
And yes! Definitely something that you can theoretically run forever without issue. Browsers basically have to keep supporting the historical properties, quirks, etc, so once you've built it, you're largely good to go :).
I 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. :)
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.
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.
The two terms certainly don't offer much more than a suggestion of what's inside the shrink wrap.
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.
- 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
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.
One question about release dates though: I remember watching the Bootstrap v4 progression from alpha -> beta -> release and I remember it took much longer than I thought it would. Just curious when we can expect the stable release version of v5 to drop?
Who knows how long this will take with the pandemic (and I work full-time at GitHub, and most of the team has full-time jobs), so all that does slow us down. That said, this should be faster than v4's development, and with fewer and smaller breaking changes by comparison.
I wouldn't start getting into the weeds with it in any kind of production environment until the beta though honestly. Release date for stable v5 is hopefully months away.
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?
> 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.
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".
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.
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).
Probably that will be the change for Bootstrap 6.
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.
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.
> 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.
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.
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?
This is for bespoke designs. YMMV
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.
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
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)?
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'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 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.
These are pretty amazing, see Color Admin and Inspinia.
Removing jQuery dependency is a big move, one that is welcome too.
What language is it?
I don't recognise it and this line
$utilities: () !default;
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.
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.
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.
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.
This is very opinionated.
Agree 10x
I like bootstrap, but after playing with tailwindcss I prefer 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.
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).
Even the title guideline ("Please use the original title, unless it is misleading or linkbait") implies that exclamation points should be taken out, since they're baity.
Arguably in this case the submitter was just trying to preserve the original title, which ends in a single exclamation mark. Site guidelines aside, a message explaining automated edits might be of help in these situations.
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.
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.
Also, you could try css-purge to remove unused classes.