It doesn't mean that the product is broken. Sometimes intelligence is the worst enemy of self, as you think you can easily understand something or not even have to learn it correctly, as it looks very trivial. This is the case with most software developers that trying to fit mental models from other languages to CSS and then expecting it to behave in the same way. Mismatch of mental models are not uncommon, especially in "intelligent people" as they don't always assume that their understanding may be wrong.
For me, biggest issue with CSS is how it's taught, how it's learned and mental models around the concepts. Most people have a different mental model of how the underlying system works, and this mismatch results in developer trying hard to bend CSS to his will.
CSS may be good or bad, there can be a better alternative... but are there any practical change that may happen soon enough that we stop learning and understanding how CSS works? Even we have a new language, people will try to use it as they used CSS before, so those intelligent people may do the same mistakes again.
We are stuck with CSS, whether we like it or not. I've been writing CSS since 2001 and it progressed immensely, still there are many things that's not possible to do easily with only CSS. But still it's the only thing we have for now and to make it better or to make a better alternative we have to understand how it works before just saying "i need a new tool", as the new tool may have the same issues as well.
Tailwind is just a way of writing/architecting CSS. There is nothing in it that "enables" rich web applications which browsers doesn't let you do with (vanilla) CSS, at the end it's just using CSS under the hood (utility classes). And CSS is not the alternative to Tailwind; there are numerous ways to write/architect CSS and Tailwind is just one of them, very opinionated and rigid that you should follow it's way of doing it. But you don't need any specific tool to write CSS, that's the point of the article.
Instead of learning/memorising CSS properties and values, you learn and memorise Tailwind classes which are just abstractions to regular CSS properties and values and you need to write them inside class tags. I think the lure of Tailwind comes from IDE integrations and its documentation. But it doesn't add any "new features" that enables rich web applications which CSS lacks in anyways.
If you need to adopt the HTML to fit a certain style, you're doing it wrong. HTML should be a semantic markup, it shouldn't change much when you need to change the styling/CSS. So you don't really go "back-and-forth" to architecture CSS, you just write your CSS. But maybe it's a Tailwind thing that you need to add additional elements to HTML just to be able to style it correctly, I'm not sure. It's like saying you shouldn't have JSON files (and embed the data inside the business logic) as you need to change the JSON file when you need to change the logic of the app. In short, you adopt your CSS architecture to your semantic markup, not the other way around.
I don't know about you, but I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that finished HTML structure. Instead, it's usually an iterative process of adding HTML, styling that, then adding more content.
That isn't even related to Tailwind, or any other CSS framework -- just that Tailwind allows you to stay in the HTML (or component) context, without having to switch to a stylesheet there.
Your JSON comparison doesn't fit: We're talking about styling, not business logic. But if you mean that I would need to define `"userAgeOver21": true` in a JSON file instead of having some `{{ %if user.age > 21 }}` in the code, then yes, I'm firmly in the latter camp. Not having to switch context often overrules pedantic purity every time.
I don't understand the big problem with switching different files. Don't we write components and tests in separate files? When we develop a component we add it to other components/views. When you need to add new props to a component, you open up the component file, add your prop, open up your component test file write your tests, if there are any tests fails you go back to component file and fix it there, then if everything works you add your props in the view components. Especially when we are talking about components and component libraries, you don't change the styling every other day especially when design tokens comes from centralised places (spacing, colors, fonts etc.).
What people misses out is CSS should be written in state-based architecture. For example for a button you have idle, hover, active, focus, focus visible, disabled states, and combinations of each button intent (default, primary, destructive, confirmation, warning) and color scheme (dark, light, high-contrast, low-contrast) states. Each of these states should enable-disable or modify some prop of the element, in most cases combination of different elements (sibling, child-parent). Trying to write them in inline classes is a PITA, especially the main concern for choosing that direction is just so we don't have a separate CSS file or need to find a name for the class (if you have a component, which Tailwind creators recommend you should, then you already need to find names for your components).
Also in addition to having separate component, component test and view/layout components; we also have separate hook files, separate state/context/store files. Even the component files doesn't encapsulate its own logic inside the same file anymore as to increase reuse of such logic. Somehow we practice separating almost every thing in the frontend to its own file, but when it comes to CSS it's too much "back-and-forth".
> I don't understand the big problem with switching different files.
Maybe it's really just fundamentally different workflows - I doubt we'll reach consensus here, and that's probably okay.
> What people misses out is CSS should be written in state-based architecture
I agree with you here. That breaks down as soon as you have states that depend on the layout - saying a button should be larger on smaller devices requires adding a style into a media query that lives separate from the button styles, unless you add hundreds of individual media query blocks. Tailwind alleviates that by making "md:" a state prefix just like "hover:".
> if you have a component, which Tailwind creators recommend you should, then you already need to find names for your components
True; I need to name my button component "Button", but I don't have to find a name for the wrapper container of the icon that goes to the right side of buttons that include an icon, which it needs to create a flex context.
How do you change a single CSS property (let's say "border-color") with Tailwind, when the conditions are: "color-scheme: dark", "high-contrast", "focus-visible", "not:disabled", "intent: destructive"? And how do you change 3 such CSS property (border-color, color, background-color) on the same conditions? As far as I can tell, you need to repeat the same condition for each property you need to change. And when you have all these combinations together, which is not uncommon for component libraries to have such different states and combinations, it's just become unreadable mess; just to be able to see which CSS properties the element has without switching files.
I guess to change these 3 property on the same condition, you need to write this TW classes (or create a "variant" in separate config file):
class="dark:contrast-more:focus-visible:enabled:data[intent=destructive]:border-slate-700 dark:contrast-more:focus-visible:enabled:data[intent=destructive]:bg-slate-50 dark:contrast-more:focus-visible:enabled:data[intent=destructive]:text-gray-50"
Or am I missing something that Tailwind makes it as easy as writing these states and combinations in regular CSS (without apply, which TW creators don't recommend using)? If that example is the preferred way of writing TW, and it's only 1 condition combination, I would happily switch back-and-forth files and write regular CSS without that syntactic high-fructose corn syrup.
> I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that
Indeed, not in the past 7-8 years. But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm. It’s unfortunate that we lost this in the transition to components.
Is that so? From my memory, most people used tables for layouts, or full-out relied on div tags for everything. At some point, HTML5 brought headers and footers and navs and more, and if anything, that made the situation better since.
But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic.
> But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic.
I mean, HTML is and will always forever be a system to display a few pages of text with some images thrown in. And even for that it sucks big time.
Anything standards committees have been throwing at it over the years are just haphazard hacks to make it into something it's not with no coherent goal in mind.
I started in 2004. Spent the years of 2007-2012 writing semantic, standards-compliant html (microformats, the works), css and js. Even my first years at booking.com still had that as a concern. Unless this was all a fever dream…
Maybe we simply had significantly different experiences? We were involved in many conferences and can definitely say it wasn’t just us.
Everyone I knew in the field was doing the same, Zeldman / ALA was everyone’s hero, UX, accessibility and standards compliance were the highlights of every project, not tooling or frameworks. Not saying everything was perfect but the focus was clearly different.
Audible Genius (http://www.audiblegenius.com) -> This is really a good resource. The subscription will be online tomorrow, 14,99$/m. I'm using it for some months now and it's really helpful, it develop your ear enormously. It's from the same guy who created Syntorial (http://www.syntorial.com).
Dance Music Manual (http://www.dancemusicproduction.com) from Rick Snoman, version 4 has been recently released and it's the only book you need (for a time being). I don't own it but Secrets of Dance Music Production looks good too.
Melodics (http://www.melodics.com) is also good for practicing keyboard, if you're interested in learning to play the keyboard.
Music Production is very similar to front-end development, especially Javascript development. Your hardware-software studio is like your bundle system, continuous integration etc. So there are many moving parts to learn and it takes time and many many readings (books, blogs, forums, facebook groups, music store product descriptions etc.). It also takes time to develop your ear and in time you will see that new levels will be opened in your mind, like a game. You will hear more details, you will easily describe the qualities of the sound (is it sine wave or a square, what kind of sonic movements happening, what kind of effects with what kind of settings make that specific sound sound like that)
It's fun, takes time, may take money (if you're interested in hardware studio and premium software plugins). But it's basically so much fun!
Ottomans were not Arab by any-means. Ottoman State is founded by Osman Bey, leader of the Kayi Tribe which is a sub-tribe of Oghuz Turks, who migrated from Khorasan. The official language in Ottoman empire was Ottoman Turkish, which is basically Turkish with many many Persian and Arabic words, while the structure and grammer was Turkish. Ottoman Turkish mainly used in Istanbul by a limited-number of people who are closed to state affairs or some educated people like poets or government officials in the federal states. Common people was speaking plan Turkish, which don't have much Persian and Arabic influence, and this language was the language of the Ottoman Army. Ottoman state and army culture, discipline and structure was a classical Turkish state structure, of course with differences from previous Turkish states.
The problem Arabs faced after dissolution of Ottoman Empire is similar in a sense to Turkish people faced, in regards to the national awareness.
Ottoman Empire didn't dissolved because they chose the wrong side, instead it was huge empire consisting of many nation and spans over an enourmous area (East Europe, Anatolia, Syria-Iraq, Egypt, Arabia, North Africa), while the army and many government offices couldn't keep up with the developments of the time. Basically, Ottoman Empire dissolved because of the wrong politics and failure to renew itself. After the French Revolution, nationalism started to spread over whole Europe and this affected the Ottoman Empire most, not only consisting of different nations, but also different religions. Being a religious state (Islamic), main subjects were Muslims and non-Muslims, separated by Millet system according to religious affiliation. Government officials were either Turkish or Devshirmes (Christian boys converted to Islam and trained to be gov. officials), being Muslim even wasn't a qualification to be an official.
When nationalism sweeps Europe, Christian Balkan nations like Greeks, Serbians, Bulgars etc. started to rebel against the empire to found their own independent nation states, feeling comfortable as the empire was loosing power every day. In that situation, Ottoman government was trying to cope with "the problem" by supporting the empire-identity of Ottomanism, and only small number of educated people were following the idea of Turkish nationalism and to create a Turkish nation-state. This was all happening at the last decades of 1800s, and Ottomans lost Balkan region, latery Ottomans also lost Middle East, Egypt, Iraq, Arabia, North Africa. British Empire also supported Arab nations to rebel against Ottoman Empire, promising their own land (British Mandates).
Empire was already dissolved when most of the nations declared their independence. WW1 was just nail in the coffin, that officially surrendered Ottoman Empire and Istanbul to British Empire. After the end of WW2, Allied forces (British, Greek, French, Italian, Armenian) shared the remnants of the empire with Treaty of Sevres, but Ottoman Army generals and irregular Turkish armed forces rebelled against the invading forces and this resulted in the victory for the Turkish side in the War of Independence, and ultimately resulted in the foundation of the Turkish national state.
TL;DR: Empire didn't dissolved because of choosing the German side. And also Arab nations didn't share "ottoman" ideals as Turkish and even many non-Muslim millet did and finally rebelled against Ottomans with the British support. Saying Ottoman Empire was an Arab Empire is simply ignoring the historical facts. This is not so different than saying all the Christian nations in Europe are descending of the Jews because Jesus was one. Having words from a language and having the same religious affiliation doesn't make two different states, nations or cultures one.
> Ottoman Empire didn't dissolved because they chose the wrong side, instead it was huge empire consisting of many nation and spans over an enourmous area (East Europe, Anatolia, Syria-Iraq, Egypt, Arabia, North Africa), while the army and many government offices couldn't keep up with the developments of the time.
Multicultural empires couldn't survive the onslaught of nationalism that came in the 19th century. The modernization attempts of the Ottoman Empire (unlike Austria-Hungary or Russia, the other two major multicultural empires of Europe) rested very heavily on a very narrow Turkish nationalism movement that alienated the Armenian, Arab, and Balkan peoples in the country. But Austria-Hungary, which was somewhat successfully trying to force an inclusive, multicultural modernization process still imploded, as did Russia, which was somewhat in the middle between Austria-Hungary and the Ottomans.
Even the multicultural aspects of the British Empire would come flying apart in the 20th century--Irish nationalism was successful in splitting from Britain in the inter-war period, and Indian nationalism would end the British Raj shortly after WW2. And Britain was consistently the most modern, liberal, and inclusive country in this period. The only countries that could successfully survive multiculturally were those that received multiple countries from the sheer immigration of the period and channeled them into a melting pot of immigrant cultures (most notably the US, but many of the large American countries went through similar experiences).
Syntorial is a charm, definitely the best resource to develop your ear. There are possibly waay extensive resources like books, but as the nature of the medium it's good for getting information, but for practice and developing the ear, Syntorial is #1.
The most useful tool I've found is Perfect Ear for Android and iOS. It's not as full-featured as GNU Solfege, but it covers all the important stuff and it's far easier to dip into when you have a spare moment.
If you're a late beginner/early intermediate player and trying to move past the chord shapes and scale patterns rut, I strongly recommend William Leavitt's A Modern Method for Guitar. It's hard - really damned hard - but it's logical, the difficulty curve is fairly linear once you get past the shock of traditional notation, it inculcates good habits from the outset and it provides you with a very broad base of technique that is applicable to all styles of guitar.
> The most useful tool I've found is Perfect Ear for Android and iOS. It's not as full-featured as GNU Solfege, but it covers all the important stuff and it's far easier to dip into when you have a spare moment.
Oh man, I missed this app when I switched from Android to iOS. So glad it's finally on iOS!
One technique I use is to noodle in some scale, then whatever note I land on try to play that note's chord by ear. You'll hit a lot of wrong chords at first but over time your ear will get better.
The real NIMBYists are the ones who pushed these people to ghettos, next to Berlin Wall.
I want my city to be better and i want workers to do this.
-Immigrants? Not in my backyard.
I want my city to be culturally rich and i want to be proud of the art that created in my city.
-Punks? Unemployed artists? Not in my backyard.
Because of this, these people located in Kreuzberg... many many years ago, before the Wall even came down.
Now the wall came down and the same people say:
I want to have a nice and cheap(er than my area) office next to Landwehrkanal in Kreuzberg.
-Immigrants and artists next to my office? Not in my backyard.
Wow, not only are your points completely a-historical and just stitched-together buzzwords from German history. You also have chutzpah to teach others about their history while living just for two years in Berlin (as you openly admitted in another comment here).
Understanding context is one of the most important thing, when you're trying understand the content/situation.
You repeatedly write that this happens because of some snowflakes' NIMBYism. Which is definitely not.
If we were talking about any other city in the world, whatever you're saying would make sense... because from the outside it looks like "oh the people who moved to city center doesn't want anybody else to move there".
That's not the case with Berlin.
Maybe you missed the topic recently but there was WWII and then East Germany, with Berlin Wall, death strip in between and East German State Police Stasi... and people who wants to escape from East.
Of course all of these happened in the city center, because the wall separated the city from the middle of it, and the areas once city center, become the dangerous ghettos.
The canals in Kreuzberg has become grave for some immigrant (and German alike) children, because it belonged to the East. If any child accidentally falls in the waters and scream for help nobody could save them. Because anyone who would enter the canals would be shot by East German police. And they did. And people couldn't save their kids from the waters, after these incidents happened. This is just one of the disadvantages of living next to a death strip, in the epicentre of the nuclear cold war.
Because of these dangerous properties, the place was cheap. And people in more "hip" areas didn't wanted to rent their flats to young people, artists, punks etc. So these people find home in Kreuzberg.
But yeah, feel free to forget about these context and try to blindly invalidate peoples experiences.
---
I gave the same example in another comment: There are many shops in Kreuzberg, which are located there for let's say 50-60 years. There are grocery stores, bakeries, markets, shoe repair shops, cheap quality restaurants, local bookstores etc.
But these people has to go now, because there is better buyer, who can afford the prices that these people can not. Or they have to increase their prices too. You were buying a croissant for 0,40€... now it's 4€. But hey, you can like our instagram page!
Now you're accusing these people of b+ching about the development, and you think they're greedy and they get what they wanted, now they're protesting so others can not get what they have?
Or do they want to live in the area, where they've been living for the last 60 years, and experienced many many disadvantages of the area?
The area was ghetto, so unwanted people located there. Now the area is hip again (after 100 years), and the people who lives there is unwanted again.
I've also been living in Berlin for the last 2 years. I want to point out that you said "immigrants, these are not the people doing the protesting" is basically wrong. Of course you can not see homogenous group in the protests, and it's easy to pick the people who fits to the stereotypes in your head. ("These guys wearing antifa hoodies, they can't be immigrant they must be leftist germans so the immigrants are not protesting" or "Oh this guy definitely looks Turkish, so the protesters are immigrants")
As it's stated by others also, the area was ghetto and the border to East Berlin, separated by the death strip and the wall. So "the unwanted" people located here. (they've been invited by the German government to repair the country after the young working population died in WWII)
Now the wall is gone, the place become hip again, and the people are "unwanted" again. And if you say that the local immigrants (mostly Turkish) doesn't protest, it's basically misinformation and not recognising their efforts to keep the area what it's been for many decades: a cultural hub of the misfits. (immigrants, punks, musicians, artists etc.)
https://www.bizim-kiez.de
One of the main initiatives by the local immigrants.
(Bizim means "our" in Turkish, and Kiez means "neighbourhood" in German)
Most of the people moved here because it was cheap and the society was welcoming the misfits. But what you say as "economic development" is destroying the culture there and pushing people out of the town. If you create a big startup hub there, all the shops will transform into hipster cafes and restaurants... Which is happening for many years and if you can't see this, open your eyes a bit. How can you expect people who live there for the last 50-60 years to pay the increasing rent, while their income doesn't because they don't work in a Startup? How can you expect a grocery store who sells cheap vegetables to compete with a vegan smoothie store, which sells the exact vegetables for 5 times the price, or even more? And after all the places will be gentrified, the rents will go even more up... then you will start protesting the smoothie prices goes up. (Which you think is happening there, which is not!)
Gentrification is not destroying the local culture, it's simply changing it. Cultures always change. Berlin is a living example of that. There is still plenty of room for artists, creatives, intellectuals, etc. in Berlin. Many of them are actually part of the growth. But yes, everybody is competing for space.
For me, biggest issue with CSS is how it's taught, how it's learned and mental models around the concepts. Most people have a different mental model of how the underlying system works, and this mismatch results in developer trying hard to bend CSS to his will.
CSS may be good or bad, there can be a better alternative... but are there any practical change that may happen soon enough that we stop learning and understanding how CSS works? Even we have a new language, people will try to use it as they used CSS before, so those intelligent people may do the same mistakes again.
We are stuck with CSS, whether we like it or not. I've been writing CSS since 2001 and it progressed immensely, still there are many things that's not possible to do easily with only CSS. But still it's the only thing we have for now and to make it better or to make a better alternative we have to understand how it works before just saying "i need a new tool", as the new tool may have the same issues as well.
reply