Clips aus meinem DEV AMA

Avatar of Chris Coyier
Chris Coyier am

DigitalOcean bietet Cloud-Produkte für jede Phase Ihrer Reise. Starten Sie mit 200 $ kostenlosem Guthaben!

Ich habe kürzlich eine AMA auf DEV gemacht. Ich nutze einfach die Gelegenheit, einige Antworten hierher zu übertragen, wie es sich für einen guten Indiewebber gehört.

Wenn Sie 2020 als Frontend-Entwickler anfangen würden, was würden Sie sagen, wäre das Erste, was Sie lernen würden und warum?

Sie müssen sich in eine Position bringen, in der es Ihre Aufgabe ist, eine Website zu erstellen und zu pflegen. Selbst wenn sich das für Sie anfangs wie eine Überforderung anfühlt. Besorgen Sie sich die Domain, bringen Sie die Website online. Stellen Sie Ihren Namen darauf. Jetzt haben Sie sich selbst die Einsätze erhöht und werden Technologien lernen, weil Sie Ihre Ideen zum Leben erwecken müssen.

Für mich war das vor 650 Jahren, eine Website für die alte Schulband aufzuziehen. Wir brauchten eine Website! Das klang für mich nach Spaß und ich habe es geschafft, mich durch den Kauf einer Domain, Hosting und das Aufsetzen einer WordPress-Website zu kämpfen. Dann habe ich im Laufe der Zeit Frontend-Webtechnologien gelernt, weil ich das Design, die Vorlagen ändern, coole Funktionen hinzufügen usw. wollte.

Suchen Sie sich ein Projekt und lernen Sie durch das Projekt.

Wie entscheiden Sie, was Sie in einen Blogbeitrag umwandeln und was Sie als einfachen Tweet belassen?

Den Tweet vermeide ich normalerweise nicht. Der Tweet ist normalerweise sowieso ein guter Prüfstein für den Blogbeitrag. Wenn es niemanden interessiert hat, na ja, vielleicht kein so guter Beitrag. Wenn er gutes Engagement erhält, ist die Unterhaltung darum herum nützlich für die Erstellung des Blogbeitrags. Außerdem sind Tweets so einfach rauszuhauen. Blogbeiträge haben für mich bewusst einen längeren Zeitplan, der Bearbeitung und Planung usw. beinhaltet.

Hier ist ein Beispiel-Tweet. Nur ein albernes kleines UI-Experiment. Ich wollte nicht warten, um darüber zu bloggen, um die Demo zu veröffentlichen. Aber aus dem Twitter-Thread erhielt ich einige interessante technische Rückmeldungen, Informationen darüber, welche Teile die Leute am meisten überraschten, und einige andere verwandte Ideen. Das wird hoffentlich zu einem viel robusteren Blogbeitrag führen.

Ich behandle DEV ehrlich gesagt sogar so. Ich habe diesen Blogbeitrag hier schnell als Reaktion geschrieben, aber dann ihn für meinen eigenen Blog verfeinert, mit einigen der Rückmeldungen.

Haben Sie einen Lieblings-CSS-Trick, bei dem Sie dachten: „Wow“?

Ich denke, „Scrollschatten“ in CSS ist einer meiner liebsten CSS-Tricks aller Zeiten. Ursprünglich von Roman Komarov, aber erklärt und verbessert von Lea Verou. Ich habe neulich ein Tool gesehen, das auf dieser Idee von Stefan Judis basiert.

Es ist ein echter Gedankenverdreher, der vierlagige Gradientenhintergründe beinhaltet, die jeweils unterschiedlich positioniert, dimensioniert und gefärbt sind und sich dann im Verhalten beim Scrollen unterscheiden.

Es ist nicht nur ein netter Trick, weil er echte UX-Auswirkungen hat. Einen Schatten anzuzeigen, wo man scrollen kann, ist wichtig für die Benutzererfahrung. Betrachten Sie diese Geschichte über ein kürzliches Design-Update in iOS, das zu völliger Verwirrung über UI-Aktionen führte, die hinter einem Bereich versteckt waren, zu dem man scrollen konnte, aber keinerlei Hinweis darauf gab, wie man dorthin gelangt. (Mir passiert das übrigens ständig bei Spotify.)

Was wären Ihre Top 3 schnellen Ratschläge für Entwickler, die einen ähnlichen Weg einschlagen wollen, um ihren Einfluss und ihre Reichweite zu vergrößern?

Ich denke, *Schreiben* ist buchstäblich der *einzige Weg*.

Ich kann mir keinen Entwickler mit Einfluss vorstellen, der diesen Einfluss aus einem anderen Grund als dem Schreiben hat. Oder wenn es nicht Schreiben ist, dann ist es ein YouTube-Kanal oder eine andere Form des *öffentlichen Schaffens*.

Wie sehen Sie sich selbst, wie Sie persönlich mit Houdini APIs spielen, sobald sie veröffentlicht werden? Welche API begeistert Sie am meisten (Painting, Layout, Typed OM, …)?

Diese extrem Low-Level-Sachen fühlen sich manchmal zu hoch für mich an. Es fällt mir schwer, die Auswirkungen der Branche auf so etwas nur anhand der Spezifikationen zu erkennen, wissen Sie?

Für mich scheint die Layout-API das größte Potenzial zu haben.

Was ich mir gerade vorstelle, ist, dass Houdini normale alltägliche Frontend-Entwickler wie mich nicht so sehr beeinflussen wird. Ich werde nicht viel Houdini-Code schreiben. Aber ich werde schicke Dinge verwenden, die andere Leute erstellen, weil sie etwas Nützliches für mich tun. Genau wie die meisten Leute nicht ihre eigenen Bibliotheken schreiben oder veröffentlichte npm-Pakete haben – sie benutzen sie einfach.

Es macht Spaß, von Houdini begeistert zu sein. Wenn jemand danach sucht, sollte er sich unbedingt Vincent De Oliveiras Showcase-Website ansehen.

Was ist Ihre Lieblingssache bei der Arbeit bei CodePen und/oder CSS-Tricks?

Wissen Sie, was ich wirklich mag? Ich mag es, jeden Tag ins Büro zu kommen und eine ziemlich gute Freiheit zu haben, was ich an diesem Tag tun werde. Ich werde wahrscheinlich Meetings haben. Ich werde wahrscheinlich einiges auf dem alten Kalender haben. Ich werde wahrscheinlich einige Erwartungen des Teams erfüllen müssen. Aber ich habe auch normalerweise viel Zeit, mich Dingen zu widmen, die mich im Moment interessieren.

Manchmal bin ich in der Stimmung, ein paar E-Mails durchzugehen. Manchmal möchte ich mit einem Demo basteln, das nach Spaß klingt. Manchmal möchte ich einen Gedanken aufschreiben oder ein Video aufnehmen. Manchmal möchte ich etwas planen oder dokumentieren. Manchmal möchte ich etwas mit anderen Leuten besprechen oder Pair-Programming machen.

Ich bin glücklich, dass ich der Chef bin (lol) und mich absichtlich in diese Position gebracht habe, um diese Freiheit zu haben.

Was würden Sie sich wünschen, was wir in CSS hinzufügen könnten?

Ich denke, jedes Mal, wenn jemand diese Frage stellt, sollten wir jede Gelegenheit nutzen, um *Container Queries!* zu schreien, bis wir sie bekommen.

Die Idee ist, dass wir CSS schreiben können sollten, das sagt: „Wenn dieses Element so breit ist, soll dieses CSS wirksam werden.“ Und nicht nur die Breite, sondern alle Media Queries, die wir bereits auf Seitenebene haben.

Die beste Demo eines Anwendungsfalls dafür ist die Seite von Philip Walton.

Ich möchte eine Kartenkomponente schreiben, die sich basierend auf ihrer Breite selbst neu anordnet, nicht darauf, wie breit die Seite ist, denn es gibt nicht immer eine direkte Verbindung zwischen diesen beiden Dingen (z. B. kann eine Kartenkomponente in einer schmalen Seitenleiste auf einem großen Bildschirm angezeigt werden, aber auf einem Tablet oder Ähnlichem volle Breite haben).

Jede Komponente kann sich in einer solchen Situation befinden, also lassen Sie mich um Himmels willen für CSS Media Queries schreiben, die auf diese Komponenten beschränkt sind. Ich teile die Meinung vieler anderer, dass, wenn wir das hätten, die überwiegende Mehrheit der von uns geschriebenen Media Queries diese wären, nicht Seitenebene.

Glauben Sie, es lohnt sich, eine { position: above-fold; } vorzuschlagen?

Ich bin mir nicht sicher, ob ich in meiner Karriere jemals eine große fold-basierte Entscheidung getroffen habe. Kein großer Fan von dieser Denkweise. ES GIBT EINE LINIE, DIE DIESES WICHTIGE MODUL NICHT ÜBERSCHREITEN DARF, haha. Die Priorisierung der wichtigsten Dinge weiter oben auf der Seite ist in Ordnung. Websites falten sich nicht wie Zeitungen.

Außerdem haben wir jetzt Viewport-Einheiten, sodass Sie, wenn Sie unbedingt etwas im oberen sichtbaren Viewport-Bereich positionieren müssen, das tun können.

Da Sie schon so lange Blogbeiträge schreiben, haben Sie einen Prozess dafür entwickelt?

So ungefähr! Es fühlt sich für mich immer noch ziemlich leger an (nennen wir meine Schreibqualität mittelmäßig), also miete ich keine Hütte in der Wildnis und suche Inspiration in Sonnenuntergängen und billigem Whisky.

  • Ich schreibe jede Blogbeitragsidee auf, die mir einfällt. Ich versuche, diese Liste ziemlich öffentlich zu halten, aber ich habe auch eine persönliche Liste, auf der ich noch schlampiger sein kann.
  • Ich füge diesen Listen so viel Kontext hinzu, wie ich kann, damit ich hoffen kann, die gleiche Emotion hervorzurufen, die mich dazu gebracht hat, sie aufzuschreiben. Wenn ich die Idee eine Woche später wieder besuche und es nicht kann, ist es wahrscheinlich keine sehr gute Idee.
  • Ich schreibe den Beitrag mit so viel Kontext wie möglich. Leichte Recherche ist normalerweise beteiligt.
  • Wir haben einen Chefredakteur bei CSS-Tricks, daher wird er vor der Planung von mindestens einer Person überprüft.

CSS oder CSS-in-JS?

Ich sehe eine Menge cooler Dinge in CSS-in-JS passieren. Ich denke, es löst viele interessante Probleme für bestimmte Websites. Zum Beispiel gefällt mir die Idee, die Option zu haben, Stile zu schreiben, die programmatisch auf eine Komponente beschränkt sind und daher automatisch weggeschüttelt werden, wenn die Komponente nicht verwendet wird.

Aber das Web ist groß und ich wage zu sagen, dass die meisten Websites nicht mit JavaScript-gesteuerten Komponentenmodellen aufgebaut sind. Daher ist CSS-in-JS für viele Websites nicht notwendig oder angemessen.

Obwohl, zwei Dinge, um klar zu sein

  • Man kann kein CSS-in-JS ohne CSS haben. CSS-in-JS sind immer noch Stile, die auf Elemente angewendet werden. Es entbindet Sie nicht davon, CSS zu lernen.
  • Die CSS-in-JS-Landschaft ist riesig. Es ist etwas schwierig, so vage darüber zu sprechen. Jedes Projekt im CSS-in-JS-Eimer behandelt Dinge ein wenig anders und wie die Stile auf die Seite angewendet werden, ist sogar ziemlich breit gefächert. Ich denke, es geht manchmal in den Argumenten unter, dass einige der Ansätze buchstäblich ein CSS-Stylesheet erstellen, das Sie wie jedes andere CSS verlinken – sogar Sass-produziertes CSS –, worüber es kaum noch Argumente gibt.