I used to think that the biggest advantage of the Internet compared to the old-fashioned media is that the communication doesn't just go one way. It's not just a few people broadcasting to everyone, but instead it's everyone having an equal voice.
But having spent years on the Internet has taught me something more: most of those “equal voices” are stupid and spiteful. And that's I don't have to listen to all of them.
I have a bad habit that I'm trying really hard to get rid of: and it's the need to always be right, to always have the last word. I was basically this person:
I'm not saying that I'm always right, of course, because I'm not. But I usually decide to only voice my opinions on issues that I know a lot about. I can't be wrong about Kardashians for example, because I simply don't talk about Kardashians. But when we're talking about web development, the stuggles of the LGBTQ+ community, linguistics, etc., I'm speaking up and backing up my views with data, knowledge and experience.
The problem is – not a lot of people seem to share that approach. Just last week, after having created zaimki.pl and being featured in a Queer.pl interview, I went through the comments underneath and wept for humanity.
People would start their comment with “I'm not an expert, but…” and end with “…creating neopronouns / neologisms is absolutely impermissible in linguistics!”. People would read see an article mentioning that one of the creators of the website is a professional English-Polish translator, and then accuse the creators of not even knowing how Polish and English are different or even that they belong to different groups of languages. Seriously.
And that's the kind of comments that bring absolutely no value. They are a thing because of this stupid notion, that everyone's opinion is valid.
And it's not. If your knowledge of linguistics comes down to speaking your native tongue and having heard in school once about the existence of Slavic languages and Germanic languages – your opinion about language evolution will probably not be useful to a professional translator or a finalist of a national linguistic competition, will it? If you're a white, able-bodied straight cis man, your opinion on how minorities should behave and how we should fight for our human rights will probably not be too useful in the discussion, now will it? If you haven't read and understood the original post, your comment below that post will probably suck, won't it? And so on, and so forth…
But I was taught toxic habits, so I kept answering those comments. I kept answering the guy who transparently was trying to destroy my project for a personal vendetta. I kept educating priviledged people that they don't have a say in the minorities' fight for equal rights. I kept re-writing points from the post for the people who clearly have not read it. I kept answering the guy who used the online comments to bully me in real life.
Reading what haters and know-better-than-the-experts have to say is hard emotional labour. Answering them is even harder. It requires a lot of time and effort, and leaves you with ragged nerves. Some people clearly come to my mentions not to have a valid discussion or to share their point of view – they come specifically to waste my time. And I'm so stupid to let them play their game…
Anyways… a few years back I was really into making sure that everything I create has a comment section, that I don't “censor” any voices, don't ban any abusers, don't hide any homophobic slurs…
But now I don't care about that anymore. I simply create things that I like, I share them with anyone who wants to listen to my words or to use my projects – and if anyone has found a factual error in my post, a bug on a website, if they have any useful input or suggestion, or if they want to cooperate – there's still plenty of ways to contact me about it.
There is simply no need for a space, where everyone can anonymously put their queerphobic views on my website.
Technically speaking, creating a comment section is complicated – with the need for a database, possibly user authentication, moderation, rich text editor, etc. When I was creating a new version of this blog, I kept it simple (and then again I went even simpler). The current version doesn't even have a database – it generates static HTML from SUML files. So a comment section would be more complex than the blog itself 🙄 That's why I had decided to outsource that logic to Disqus.
Technically, Disqus works like a charm. But for the sake of my mental health and hours of needlessly wasted time – it's time to go one step further.
I simply removed the comment section. Poof.
And I'm not the only one to do that. Many major newspapers get rid of their comment section nowadays, or at least limit the write access to paying subscribers.
Life's too short for trolls.
PS Before you accuse me of “silencing criticism”, “hiding in my bubble”, “not being open to discussion”, “not being open to change my mind”, etc., please let me tell you that I used to be a devout catholic, conservative, right-wing… Now I'm a pansexual, polyamorous enby, intersectional feminist and human rights advocate. I am able to change my mind, because I already have made a 180° turn (and multiple smaller ones). I am constantly exposed to people disagreeing with me and calling me queerphobic slurs every day. Don't worry about my openness to opposing ideas. I'll be fine without this one extra place to anonymously bash me, thank you very much.
]]>Tworząc kiedyś stronę internetową, trzeba było się nieźle napracować, by na każdym komputerze wyglądała mniej więcej tak samo. Każda przeglądarka interpretowała sobie kod po swojemu. Teraz jednak, gdy wszystkie nowe wersje popularnych przeglądarek trzymają się standardów (a nawet mój ulubiony były klient, Santander, przerzucił się z dinozaurów na aktualne wydania), no a zdecydowaną większość pozostałych jeszcze różnic między przeglądarkami można zniwelować używając normalize.css oraz jQuery, mogę z całą stanowczością uznać przenośność za największą zaletę technologii webowych. Piszesz kod raz, a działa wszędzie.
Z drugiej jednak strony tę samą przenośność można też uznać za wadę. Cały Internet sprowadza się bowiem ostatnio do tej świętej trójcy: HTML5 + CSS3 + JS. Bo skoro te trzy potrafią już wszystko to, co kiedyś umiały tylko Flash czy aplety Javy, to po co ryzykować bezpieczeństwo witryny, zmuszać użytkownika do instalowania wtyczek i odbierać sobie możliwość lepszej integracji elementów strony? Po prostu nie ma sensu wychodzić poza świętą trójcę. A jej rozwój jest niestety ograniczony aktualizacjami przeglądarek. Czy zatem jesteśmy na nią skazani?
Na szczęście nie! Istnieje cała rodzina języków, które bardzo sprytnie obchodzą ten problem. Wprowadzają ogromne ulepszenia i ułatwienia, ale bez potrzeby interpretowania ich przez przeglądarki! Po prostu po stronie programisty są kompilowane do jednego z tych języków, które każda przeglądarka rozumie.
Powiedzmy na przykład, że chcesz stworzyć w CSS klasy od col-1
do col-12
, z których każda będzie nadawała DIV-owi szerokość równą ileśtam dwunastych szerokości kontenera. W Sass zajmuje to trzy linijki:
@for $i from 1 through 12
.col-#{$i}
width: $i/12 * 100%
A jest kompilowane do takiego kodu:
.col-1 {
width: 8.33333%; }
.col-2 {
width: 16.66667%; }
.col-3 {
width: 25%; }
.col-4 {
width: 33.33333%; }
.col-5 {
width: 41.66667%; }
.col-6 {
width: 50%; }
.col-7 {
width: 58.33333%; }
.col-8 {
width: 66.66667%; }
.col-9 {
width: 75%; }
.col-10 {
width: 83.33333%; }
.col-11 {
width: 91.66667%; }
.col-12 {
width: 100%; }
Pierwszy z nich jest prosty, krótki i czytelny dla człowieka, drugi natomiast zostanie zrozumiany przez wszystkie przeglądarki. I wilk syty i owca cała! Sass zawiera wiele elementów, których prostemu CSS-owi brakuje: zmiennych, instrukcji warunkowych, pętli, funkcji (tzw. mixins), zagnieżdżeń, operacji arytmetycznych... O ile bardziej elastyczny staje się kod, gdy możemy zdefiniować na przykład zmienną $navWidth: 300px
i użyć jej w pięciu innych miejscach (również w wyrażeniach arytmetycznych, np. width: $navWidth / 2 + 16px
), zamiast wszędzie podawać ją wprost. Każda zmiana szerokości nawigacji jest wtedy po prostu banalna, nie wymaga szukania wszystkich zależności. O ile krótszy i bardziej przejrzysty staje się kod, jeśli możemy często powtarzające się elementy zamknąć w parametryzowane mixiny i po prostu się do nich odwoływać? Świetną listę sassowych ficzerów można znaleźć choćby na Wikipedii.
Podobnymi do niego językami są Scss oras Less. Wolę jednak Sassa z jednego powodu – brak klamer. Skoro i tak w każdym kodzie powinno się stosować odpowiednie wcięcia tabulatorami, to klamry stają się zwyczajnie zbędne. Język, który wymusza stosowanie wcięć w kodzie po pierwsze wymaga mniej klepania w klawiaturę, a po drugie daje gwarancję, że po kim byśmy kodu nie przejęli, zawsze przynajmniej pod tym względem będzie on czytelny. Same plusy! Z tego samego założenia wyszli chociażby twórcy Rubiego, Pythona czy CoffeeScriptu.
A no właśnie, CoffeeScript. Żywy dowód, że nawet tworzenie JavaScriptów może być przyjemne (słowo daję, nie uwierzyłbym, gdybym nie spróbował). W JS to dopiero jest nadmiar nawiasów i klamer:
sse = new EventSource(Routing.generate('conversation_check'));
sse.addEventListener('conversation', function(e) {
if (e.data == 'test' || e.data == 'dev') { return; }
$.post(Routing.generate('conversation_fetch'), { ids: e.data }, function(data) {
conversation.html(data);
});
}, false);
Ta sama funkcjonalność w CoffeeScripcie wygląda następująco:
sse = new EventSource Routing.generate 'conversation_check'
sse.addEventListener 'conversation', (e) ->
return if e.data in ['test', 'dev']
$.post(Routing.generate('conversation_fetch'), { ids: e.data }, (data) ->
conversation.html(data)
)
, false
Wystarczyło zastąpienie składni function(a) {...}
prostym (a) -> ...
, zmiana klamer na wcięcia oraz możliwość pominięcia niektórych nawiasów w parametrach funkcji – i voilà! Mniej klepania w klawiaturę i doszukiwania się par nawiasów, a treści tyle samo!
Nie sposób się nachwalić wszystkich ficzerów CoffeeScriptu... JSON-owe obiekty można w nim definiować podobnie jak w YAML-u, pętlę można od 1 do 100 zawrzeć w króciutkim zapisie 1..100
, zmiennych nie trzeba deklarować, można im przypisywać wartości do wielu na raz (a nawet zamieniać je wartościami w jednej linijce: [foo, bar] = [bar, foo]
i tyle!). Najlepiej po prostu przejrzeć jego stronę domową i milczeć w zachwycie!
Również w przypadku HTML-a istnieje wiele technologii, które pozwalają na wygenerowanie go na postawie bardziej wyrafinowanych języków. Lecz tutaj to trochę co innego. Mowa o template engines takich jak Twig, Smarty, Haml czy Erb – one jednak są kompilowane do języków wykonywanych po stronie serwera (PHP, Ruby, Python...), więc niezbyt pasują do mojego zestawienia. (Nota bene w Hamlu jeszcze bardziej zredukowana jest klamrowa redundancja: z <html></html>
robi się zwykłe %html
)
Potrafię znaleźć tylko dwie wady całej tej rodziny technologii w porównaniu do świętej trójcy. Po pierwsze, tak jak przeglądarki, tak samo frontendowi programiści trójcę znają z całą pewnością, czego nie zawsze można powiedzieć o jej młodszym rodzeństwie. Więc jeśli ktoś dostanie po tobie projekt, w którym używałeś Sassa czy CoffeeScriptu, może nie być mu zbyt kolorowo. Z drugiej jednak strony, są to przecież technologie bardzo łatwe do przyswojenia, a zarazem niezmiernie przydatne i wygodne. Więc chyba tylko wyświadczyłbyś mu przysługę, prawda?
Po drugie natomiast, kompilowanie trwa i wymaga zachodu. Wystarczy jednak zainstalować Bowera albo skonfigurować sobie watchera w PhpStormie, aby każde zapisanie pliku automatycznie uruchamiało kompilację. Naprawdę, wygodniej już się tego zrobić nie da!
A poza tym same plusy. Jeśli tworzysz strony, a jeszcze nie znasz tych technologii – koniecznie je wypróbuj! Z odrobiną wprawy i doświadczenia, połowa twoich frontendowych problemów może zniknąć.
]]>