For those not familiar with where cities are located in the US, that map is basically a population density map of the US. High population density regions are blue, low population density regions are red. This is true even in "deep red" states and "deep blue" states.
The founders knew this divide would exist, because the same basic divide was there 200+ years ago (different parties and party names, but the same rural/urban political divide). They purposely chose to design the electoral college system in a way that gave rural regions a significant say in political outcomes even when their population densities are much lower than those of cities. They also purposely placed seats of government away from major cities, for much the same reasons.
The country may be more polarized today, but the color pattern on the map is not new.
The electoral college was originally intended to have the states appoint some grandees who would get together and discuss whom the best candidate for president would be (for an election system that actually works like this today, imagine the papal conclaves). This system worked like this approximately once, and failed catastrophically by the fourth election, which prompted the slight adjustment that we see today. Electors weren't regularly selected by popular vote until after that change, largely complete by the 1820s.
Meanwhile, the reason for the electoral allocation reflects one of the most fundamental compromises in the design of the federal system: is the national government be representative of the people, or is it representative of the states? The answer is it's both--that's why there's one house for the people and one house for the states (the Senate). And the number of electors for the president is similarly a compromise, giving one vote for each member of both houses. (Again, recall that senators were not elected by popular vote until the 20th century).
There was no concept of a rural/urban political divide, because urbanization really wasn't a thing in 1787. The overarching concern of the people who wrote the Constitution was balancing the powers of a state like Virginia versus Rhode Island--the small state/large state divide is the major focal point of discussion--although there was also a contentious issue over the role of slavery (of course, in 1787, most states were slave states--only Massachusetts had fully abolished slavery by that point, although the rest of New England had just adopted a gradual abolition program) which yields the ⅗ compromise.
> They purposely chose to design the electoral college system in a way that gave rural regions a significant say in political outcomes even when their population densities are much lower than those of cities.
This is a myth. The electoral college as originally conceived simply granted a elector count[1] to the states and let them decide how to allocate them. It had nothing to do with urban/rural divide, which barely existed at all outside of the three (!) states that actually had cities of meaningful size.
The interpretation you're proposing is decidedly modern. It's a retcon intended to justify the fact that "red" states in the modern electorate are clearly wielding outsized influence. But even that has only been true for 2-3 decades.
[1] What asymmetry existed was actually because of the way senate seats are allocated. Its effect on presidential elections was essentially an accident.
I am skeptical of this claim because in the 1700s the urban population would have been minimal compared to what it is today. A large majority of people were employed on farms.
Wall St was an actual (medieval) wall until the turn of the 18th century. It's at the very south of Manhattan, a ten minute walk from the tip of the city it was built to protect.
NYC's postal names are a mess: Manhattanites can write "Manhattan" or "New York". Brooklynites are supposed to write "Brooklyn." Queens denizens write the historic names of the farm towns that used to be there. "Astoria" is actually part of New York City, even though seeing a letter addressed there might make you think it's a town upstate.
The postal service is older than the current boundaries of New York, and they never updated the mail routing to reflect the unified city.
Before the bridges were built, much of what's now NYC was very rural.
I believe the medieval era ended in the 15th century, but the wall was built in the 17th. So actually the wall would have actually been a colonial era wall, if going by eras - not to mention the construction style was actually more reminiscent of colonial era structures rather than medieval.
Seats of government necessarily become cities. You don’t create a new city to keep power away from cities. State governments tended to be put in central locations for the convenience of all urban and rural dwellers, and away from existing power centers to avoid concentrating power with the wealthy.
The electoral college demands proportional representation in presidential elections. It says nothing about whether the electors are rural or urban dwellers. In fact, proportional representation weakens the power of less populous states.
The original unicameral continental congress with only a senate gave more power to less populous states, but the founding fathers found it effectively gave any single state veto power, which was counterproductive, and hence the great compromise was passed creating the House.
The map of where slavery is allowed corresponds pretty well with the areas that are rural, as you don't need slaves to work the fields where there aren't fields, and slaves are a poor labor source for the more differentiated and fluid industries in cities (there isn't enough liquidity for them to adapt to changing economic conditions, as the slaves are property of a single owner and their labor isn't traded on a free market).
This is not true at all. Slavery wasn't allowed in the rural north. And in the south, slavery was part of all sectors of the economy. Slave factories were even a thing. Furthermore, slave labor could be traded on the market just as well as any other labor. There was nothing stopping a slave owner from renting out his slaves a contract labor. If the civil war hadn't happened when it did, southern slavery would have been an industrial horror.
I'm waiting for the day developers realize the fallacy of sticking with pixels as their measurement for Things on the Internet.
With a deeper understanding of CSS, one would recognize that simply parsing it out for only the components "above the fold" (which, why are pixels being used here in such an assumptive manner?), completely misses what is being used in modern CSS today - global variables, content-centric declarations, units based on character-widths, and so many other tools that would negate "needing" to do this in the first place.
Yes, this is for specific use cases, I don't have a use for this for sites where I coded everything myself, this has been useful for static sites where I downloaded a template that uses libraries, probably useful for people with similar cases
The difference is that the internet can exist (and did) quite well without JavaScript. Without HTML there is no internet. Furthermore, ECMAScript is a language and W3C/WHATWG are a consortium that maintain HTML.
Except when using Tailwind, you're learning Tailwind nomenclature and syntax and approach - which really isn't modern CSS, at all.
Today's CSS - if anyone would take the time to actually learn it as they do JavaScript - doesn't need something like Tailwind to make it powerful, scalable and manageable.
I write plain CSS today, which is then scoped to components or bundles of interactivity, and all of those point to major, top-level control sheets that help determine the mode (light/dark/high contrast) and the theme. We tweak small changes up high to effect large platform changes throughout, saving time, energy and headache of the hunt/peck exercise.
I don't understand the statement "no one is going back to writing plain CSS" because plain CSS today _is complex_. It is a beast. But it is still "plain" CSS. Yes, it has evolved, it has grown, and it meets today's modern needs with excellent results.
CSS nesting is coming up soon: https://caniuse.com/css-nesting That will more than likely allow me to migrate any projects I have with Sass still in play, to remove Sass. One more dependency removed. Done.
So there's really no need for Tailwind if you know how to build with modern CSS - with the one caveat that if a project _already_ has Tailwind in it, it is a bear to work with/alongside.
That to me is the biggest con with Tailwind: it gets in your way when you don't need it.
I write plain CSS today, which is then scoped to components or bundles of interactivity, and all of those point to major, top-level control sheets that help determine the mode (light/dark/high contrast) and the theme. We tweak small changes up high to effect large platform changes throughout, saving time, energy and headache of the hunt/peck exercise.
I do similar things with Tailwind, making global changes by updating a config file instead of a base CSS file. It's not hard and it works well. To be honest, it's not something that really comes up very often. I don't see this as a particular advantage of Tailwind or CSS. I care much more about the day-to-day dev experience.
Prior to using Tailwind I spent about 20 years trying every system you can imagine to manage styles across large websites/apps. I still use the skills I learned when Tailwind doesn't cover an edge case I need. It's fine. Before that I spent about 5 years doing the same with tables and font tags (Adobe Pagemill was awesome). Of all the systems I've used, Tailwind is the easiest to keep neat and tidy. Maybe I'm a terrible dev and other people find CSS really easy to manage, but having spent two decades talking about it with other frontend engineers I'm reasonably certain that's not a common skill. Tailwind makes life much easier for most people.
One more thing I find baffling is the preference to ignore the cascade… and seeing it as a benefit.
The cascade is where the value of CSS comes from! It’s an incredibly powerful concept.
I use and love the Inverted Triangle CSS (ITCSS) approach and write a fraction of the CSS code I used to.
Having a few utility classes, using variables for project-specific colors, breakpoints, spacing, using fluid typography, grid, and flexbox, make writing well-structured minimal CSS code a pleasure.
One more thing I find baffling is the preference to ignore the cascade… and seeing it as a benefit.
Tailwind styles cascade just like any other CSS rules. No one is ignoring it. The reason it might appear not to is because Tailwind uses layers (https://developer.mozilla.org/en-US/docs/Web/CSS/@layer). Technically it's a polyfill at the moment, but v4 will use the native @layer syntax.
If anything Tailwind is actually better at using the cascade than most plain CSS approaches.
Except if you bundle your styling with the component, like you should be doing with React or Vue, and you have two _maybe_ three over-arching foundational style directives being implemented across your build, you do not need Tailwind.
I believe both React and Vue have the capability to scope your CSS along with the components. Modular CSS has been much easier to maintain over years than fixing when Tailwind updates or finding (again) that one !important that happens to conflict with a new released component set.
I save my teams time and money by applying CSS in the manner that it should be; which means not as an inline style mechanic.
> I believe both React and Vue have the capability to scope your CSS along with the components.
While that's true, it also means you need to propagate all of your exceptions for support of old browsers. And you still need a ton of global styles so your application can be re-themed or white-labeled according to your customer specifications. And god forbid someone applies a color directly in a component and you have to grep the codebase looking for the errant code.
After 5 years of tailwind on several complex applications, I can say that it's been easier to maintain, especially as engineers come and go, than any of the applications I worked on before. Frankly, every company I've ever worked for wound up with something like their own bespoke tailwind anyway, but instead of having it well-documented, every new hire had to learn whatever naming system whoever wrote the global design styles decided on.
> I believe both React and Vue have the capability to scope your CSS along with the components. Modular CSS has been much easier to maintain over years than fixing when Tailwind updates or finding (again) that one !important that happens to conflict with a new released component set.
In my experience that's empirically false. Maybe if you only care about Chrome, but CSS is hell to maintain when you need to keep support for browsers like pre-blink Edge.
In today's uses, cascade _with_ custom properties (the vars defined within :root ) are powerful and are what I leverage when providing theme-able ui libraries. Dark mode, light mode, large mode can all be solved using custom properties which to me most exemplify the power of the cascade.
that is inheritance not the cascade: Inheritance allows for DOM nodes to use properties set on their ancestors, the cascade algorithm is how multiple conflicting rules interact and are overwritten.
Custom properties are by default inherited by all descendant nodes (they also interact with the cascade, but it is less relevant) and this can be used with tailwind in a couple of different ways: https://stackoverflow.com/questions/64872861/how-to-use-css-...
I vehemently disagree. When you're using tailwind, you're learning Tailwind, which is using CSS in absolutely the unequivocally anti-CSS way.
CSS was meant to cascade; it's what the damn 'C' stands for, and if you cannot understand the efficiency of the cascade, at scale, you are most definitely missing the entire point of CSS.
I have personally built ui libraries for boutique firms and enterprise (Apple) firms and guess what we did _not_ use in any of those instances? Tailwind. Because it's an utter toddler to manage and very definitely not efficient in its application.
There's a strong contingent of developers who would argue that the global-by-default aspect of CSS was a mistake. Hence nested selectors in Sass/SCSS, CSS modules, and so on.
Styles applied by Tailwind classes cascade. The library just makes it (intentionally) difficult to define a class that will easily collide with others.
Actually, the "C" in CSS stands for "Mistake". Cascading styles are not a good idea, and Tailwind encourages using styles in a way that makes sense for a component-first web.
If you want to cascade all your styles all the way down, by all means go for it. However, I aim for readable / scalable styles rather than dogmatically "cascading" everything just because it's in the name.
Disagree. Have been using and developing with CSS as my focus for ten years now. If you take the same amount of time you would take to learn the ins and outs of [pick any other language], you would have a better time of it.
I'd like to add a reason that you do not list and one that I constantly run into is that due to the lack of understanding, large applications have been built and it is simply not cost-effective to re-wire the whole thing using better approaches. The only time I get to apply features and structures that are less than five years old to projects is when it's a green field opportunity. Otherwise, the budget just doesn't cut it.
Personal comment/response:
I will say that CSS seems to be for a particular _breed_ of developer. Almost designers, but not quite. My perspective of this comes with also using JavaScript for the same amount of time. The thinking I use in both of those domains differs at times quite dramatically.
I'll use the number of pages of OReilly's foundational programming books as an example of anecdotal complexity of three languages: JavaScript - 704 pages, PHP - 842 pages, and CSS - 538 pages (the new one coming out will be 1090).
No frontend co-worker that I have had spanning the past ten years has ever worked through the _old_ CSS one from 2006, at all. Even those that loved CSS, did not own a copy of that one. It covered everything CSS and I read it cover to cover.
Without a commitment to CSS on par with commitments that developers make everyday to any given framework or other programming language, anyone trying to wield CSS on the same level as the other tools will continue to be disappointed.
And as long as the culture of web development continues to de-value solid in-depth understanding of both HTML and CSS, then yes, quite a lot of us will remain over-burdened in our day-to-day responsibilities.
That's just my take. As I am also a musician who plays both piano and oboe - I can use that as an analogy as well. I can teach _anyone_ piano. I cannot, at all, simply teach anyone oboe. They _must_ have an inclination towards it and I can literally bet my life savings every time that really good oboists also seem to be really quirky humans. I would put passionate CSS developers at the same table and I would expect them all to get along.
Your belief that you must use classes to apply CSS is false.
CSS is a generalization programming language, with specificity meant to be used for _exceptions_. Therefore, CSS should be used with general statements first, contextual statements next, utilitarian statements following, and then and only then exception-specific declaration in the edge cases they are needed.
Programming with CSS the way it was intended: Cascade, Inheritance, and then specificity, generally produces a quite DRY experience.
The one thing engineers/other programmers seem to have missed, continue to miss and seem intent on missing into the future is this: CSS is a static programming language that must account for being in and rendering dynamic contexts.
When I'm in JavaScript, I _depend_ on having the one thing, be the one thing, whenever I reach for it. I depend on immutability to keep my life sane.
When I'm in CSS, I _must_ account for flexibility, because I cannot predict the future, and I cannot predict all the various contexts in which my declaration might exist. Therefore, each CSS statement I create is based on how I would _like_ my thing to behave based upon a variety of circumstances, and to have static fallbacks when all else fails. My sanity is in producing the most responsive yet stable experience for the unknown.
Tersely, but without apology: Tailwind is for developers who do not want to take the time to learn CSS the same way they took time to learn JavaScript [or insert language of choice].
CSS is scalable. You have to actually know CSS in order to accomplish it. I've been here since mid-90s, when CSS first existed. It isn't until the past four or five years that things have really blossomed into (imho) what it should have been from the outset.
Unfortunately, since we have had to use filler tools for things like layout (tables, hacked flexbox for grid), CSS itself has taken a beating in perceived usefulness/weildability. I believe because of THAT, fewer and fewer people have decided to actually learn CSS.
CSS is a robust language. It is programmable. It is scalable. You just have to learn it, practice it, and approach problem solving from the top down, bottom up, and sometimes sideways. :-)
