Thomas Michael Semmler - helloyes.dev

Craft vs Industry: Separating Concerns

2023-03-09T00:00:00Z

This post is probably too long, but I need someplace that I can refer to. As is often the case, I am writing this to sort my thoughts, primarily. But I am hoping to give voice to what I am observing in other people in our field but is rarely spoken about. I am not attempting to postulate a solution to a complex problem; instead, I am trying to provide words in the hopes that they resonate with what other people are experiencing, if nothing else just to let them know that they are not alone with it.

Every good post starts with a quote, right?

[Industry means] something that is produced or is available in large quantities and makes a lot of money.

(Quote from the Cambridge Dictonary)

We have long referred to our niche on the web as the "web industry," but never has the term been more congruent than it is right now. I believe this throws us into some conflicts that we are left to deal with alone. Because what we've learned in the decades before, what mattered to the craft of making websites, seems to sometimes not be compatible with what is asked of us from our jobs. This throws us into significant conflict, and resolution seems to be left to our own devices. In this post, I am trying to tackle this conflict that has been on my mind for so long.

Welcome to the Age of Industrialisation

I think it is very clear for most of us to see that our little corner of the world has reached the age of industrialization. With this "little corner", I am referring to the community of people who make websites. Designers, developers, and everything in between and beyond alike

There are many signs that we have irreversibly entered a new era, one that is determined by industrial practices. We constantly hear that we're not supposed to reinvent the wheel; websites are now being derogatorily called MPAs (multi-page apps), and we're generally referring to websites as software. UI is now coming in the form of self-contained, composable pieces of single sources of truth, "components", and the question "Will it scale?" is the number one differentiator for "maturity" in the tooling surrounding our craft.

Scalability as Leitdifferenz

A single difference that allows us to sort something into a dichotomy—that is what a "Leitdifferenz" refers to (I am using the German word directly here to refer to Niklas Luhmann's concept, because I cannot find a semantically fitting translation). We have been obsessed with this scalability as the single differentiating factor that will tell us how well something will adapt to the changing requirements of an organization and increasing, diverse technical demand. But for businesses, scaling means that output remains the same or only slightly degrades while production costs lower.

Scalability has become the leading differentiator, the Leitdifferenz, of almost everything in our industry. From the tech we develop with, for, and on to what, how, and who we design for It's almost like a trance that we keep repeating to ourselves."But will it scale?" is first and foremost a matter of business. But in development and design, it also refers to other factors. Yet when it comes to matters of industrialization, these factors remain secondary.

For example, a course is a scaling product. Because you are investing time into its production, and then all you have to do is maybe every now and then generate a promotional advertisement for it, but the price remains the same while your initial expense disappears entirely. Your margin has increased; your product value has scaled. The purpose of industry in general is to achieve scale by reducing production costs. Create a "streamlined" (another term that we have become very familiar with) manufacturing process and automate it as much as possible to generate a product that will sell to as many consumers as possible.

Configured, Consumed & Composed: Components and Design Systems

We can consider design systems themselves as an answer to the question of scalability for design. And even here, scaling is still the leitdifferenz by which we categorize. Design work is being compartmentalized into "components", small, self-contained deliverables that can then be composed together by someone who is not a designer. The idea is that this will allow for a more efficient and scalable design process. But obviously, design is more than just that. And design is still happening by the person who puts components together, just without the skills necessary. So the reaction is to create an even more restrictive set of rules, so that instead of applying systemic principles to design work in order to enable design work, it is being reduced to a set of consumable components and rules.

That is not the premise of design systems as a way of working, but it is what some designers are postulating because that is what sells them to industry. The way that industry incorporates design systems is basically a misappropriation, or abuse at worst. It is not just me who is seeing the problem with ongoing industrialization in design. Even Brad Frost, the inventor of atomic design, is expressing similar concerns. In the words of Jeremy Keith:

[...] Design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.

So no. It is not just you. We all feel it. This quote is from 2020, by the way. What was then a prediction has since become a reality. And it is also reflected in the way that people are entering the industry. Lately, we've seen a lot of bootcamps popping up that, for the most part, educate people just enough so that they can get a job, at least that is the premise. But they rarely know the principles, values, and philosophies that constitute the web platform. But they can create a fully functioning "web app" with Next. JS in React! Of course, they don't learn how to manage CSS for this type of site; instead, they just use Tailwind. But at least they know how to specify TypeScript interfaces!

And of course, they learn that design comes from UI libraries. Gone are the days where we used to tell people that bootstrapping was just for prototyping and otherwise would quickly turn into technical debt! Nowadays, designers are sometimes even told to start with one of these libraries. Just, they're not called bootstraps. Instead, they're called Material UI, Headless UI," or Chakra UI. But they bear every necessary resemblance. But it's fine, because it's just the components, right?

What could have become Design Systemics, in which we applied systems theory, cybernetics, and constructivism to the process and practice of design, is now instead being reduced to component libraries. As a designer, I find this utter nonsense. Everyone who has even just witnessed a design process in action knows that the deliverable is merely a documenting artifact of the process and does not constitute it at all. But for companies, the "output" is all that matters, because it can be measured; it appeals to the industrialized process because it scales. Once a component is designed, it can be reused, configured, and composed to produce "free" iterations without having to consult a designer. The cost was reduced while the output was maximized. Goal achieved!

Seats at the Capitalists Table

The larger premise of design has degraded over the years, in my opinion. As it got more embraced into the industrial process, it did so by devaluing the perspective of the people for whom the discipline used to design and replacing it with the perspective of companies. This is the price that design continues to pay for its seat at the capitalist table. In my opinion, the cost is too high to be worth it. This was also one of the reasons why I decided to not pursue it as a career any longer, in 2022.

When we referred to ourselves as Web designers, we were constantly struggling to find companies that took our profession seriously enough to integrate us into their processes. But design was not considered valuable. So we started to call ourselves UX designers because we were designing experiences, not websites. And slowly but surely, we got our oh-so-desired seat at the table. But only if we demonstrated our worth by demonstrating a number-go-up linear-causal relationship to our work, which would necessitate extensive monitoring of our users.And thus, companies have successfully forced us to degrade the merit of our work to quantifiable markers of increased conversions and clicks and the firing of whatever other random KPI we could somehow pull off our asses—all to appeal to the growth-at-any-cost mindset.

This often happens with important values in our craft. The recent increase in attention on accessibility is already taking a similar path. Accessibility advocates and experts are often forced to "sell" (see what I did there?) accessibility work to companies by showing them how much more revenue, conversions, or users they could be having by making their sites accessible. But our craft, on the other hand, clearly dictates this as a primary focus—a Leitdifferenz to judge the merit of our work. If what we do isn't accessible, it's to a certain degree broken or incomplete at best.

The problem with this angle is that, inevitably, industry will respond industriously. And now we're having to explain to companies why they cannot just install an overlay and see it done. But that is the price of putting a number on marginalized groups. Unfortunately, that is the language that businesses speak, so experts and advocates are not to blame. They are doing the best that they can because they know that, in the end, the removal of barriers for people who rely on them is what matters. They are, in their own way, navigating ambivalence and finding their way through the conflict of craft vs. industry.

When Places become Products

UX Design used to stand for "User Experience", but in order to get our seat at the table, we had to degrade it so much that it has long since shifted its meaning to "User Exploitation", as Mark Hurst writes. The practice of UX, removed so far from its subject that it now considers the company itself the subject of their work, is now being used for bad-faith manipulation to increase capitalist numbers.

This is reflected in another marker in language. Just as we were once web designers and then UX designers, we now call ourselves "product designers." As designers, our relationship to what we design and for whom we design it has changed. We used to design websites for people, then experiences for users, and now we are designing products for companies.

This coincides with the fact that we are now broadly regarding websites as software, but we're not calling them websites. We're calling them "Apps". And it makes sense—we have entirely normalized the practice of having our websites controlled by JavaScript from server to client because JavaScript is mature now and thus appealing to traditional programmers, who used to shun it fiercely.

This change in the demographics of those who write code has made it easier to hire for these positions. A website entirely rendered in JavaScript can be worked on by someone with a University Degree, in which they are rarely taught about the special relationship between HTML, CSS, and JavaScript, but are instead told that CSS and HTML are not real programming languages. And with these capital-P programmers, their language is long, as are their world view and their heuristics.

The Craftsperson vs The Factory Worker

People who make websites and are also working in what we refer to as "the web industry" are often forced into a difficult conflict. In their position as an employee or freelancer, they sometimes have to work on technology that they know isn't compatible with the values that they learned to hold dear in their craft. Designers are asked to implement dark patterns, even though they know that it is unethical. Developers are asked to work with React, even though they are aware that it is maintained by Facebook, a company profiting and and enabling genocide. And the list goes on.

It is also expressed in what I think is best summarized as "Industry Fomo". Developers know full well that using next.js to create a relatively simple website is overkill, inappropriate at best, but they see themselves required to use industry-grade technology because job requirements are not listing skills anymore, instead they are listing tools and frameworks.

I consider this a conflict between two identities: the craftsperson and the factory worker. The craftsperson wants to do what honors the values of the craft, but the factory worker needs to do what will keep them employed or employable. A conflict that we are being left alone with, often lacking the words to conceptualize what is really happening here.

Separating Concerns

Postulating to know a solution to what I consider would be hubris on so many levels. But what I can do is access a little trick from my work as a systemic counsellor. Systemic counseling operates on many different principles, one of them being second-order cybernetics, in which cybernetic principles are applied to cybernetics itself—recursive cybernetics. We know a thing or two about recursion, right? We can apply some of the principles that we usually use as a guide in our craft to our own situation: Separation of Concerns.

While this integer design principle of HTML is usually referred to in order to justify the separation of concerns for content (markup, HTML), presentation (styles, CSS), and behavior (scripting, JavaScript), it is also a general design principle in computer science, and we can also use it to separate the concerns of the craftsperson and the factory worker.

If we separate the demand into independent concerns, made by independent parties, we get the chance, instead of having to decide, to hold the ambivalence and complexity of the situation. Industry of course would force us to reduce complexity, another religious mantra of programming. But complexity means possibility, and with possibility comes the ability to decide. Do we go with what the industry demands, or do we go with what the craft demands? The conflict is the oscillation between both possible decisions. Not only can we not decide, but we are also uneasy with the fact that we cannot decide. Fritz B. Simon calls this a "double negation,", and it becomes the constitutive marker of conflict, described systemically.

But what if, instead of oscillating between both positions in an attempt to make a decision, we just stay in this ambiguity for a while?A room emerges that we are holding. In this room, both positions aren't changed, but it may allow us to not experience them in conflict with each other. If we understand them as a conflict of concerns and not a conflict of identity, we may even see where both concerns align. Or we can give voices to both parts.

At the very least, it may help us to not experience this as a personal conflict but instead leave it to the job, which has to find a way to utilize craft in a way that makes it compatible enough with industrial processes—another different concern reveals itself here, the concern of the business, not the concern of the employee.

Failing to reconcile competing Identities

This isn't always possible, though. And sometimes, people may decide to leave not only the industry but also the craft all together to protect themselves from this conflict. Not because they couldn't hold the ambivalence of the craftsperson and the factory worker as is, but because they don't want to degrade themselves or their view of the craft—or maybe because they weren't able to see two separate concerns but instead saw a personal conflict that they were left to deal with on their own.

But if we somehow manage to conciliate those two competing identities, we may find some personal relief from trying to find a common ground between two competing sides within ourselves. I have to work with technology that I find deeply offensive and politically abhorrent all day. But at some point, I found great relief in understanding myself as an employer who works with this technology, not as a craftsperson working on the web. I understand that it is not people who want to create SPAs; it's an industry—businesses.

Many people are not differentiating here, and so they just repeat the capitalist programmers mantras. But that says much more about how they relate to others and how they define themselves. Do they even consider themselves craftspeople? Do they even see the craft that is there?

Ultimately, the fact that we see a conflict here can be considered a good sign. As I said before, systemically, we can understand a conflict as an oscillation between possibilities. That means that in order to experience conflict, we first need to see possibilities. So if you are currently battling this conflict, you may find some relief in knowing that you are experiencing it because you see possibilities and are not submerged in the trance of the factory worker, induced by industry.

AI: The Penultimate of Dehumanisation

We do need to talk about AI because it is an inevitable part of industrialization and there is no escape for any of us. The desire to reduce manual labor by automation and reduction of complexity is the seed that gave birth to programming in the first place, and AI is a tangible premise of endless scaling. I think it would be incredibly unwise and hubristic to assume that the broad majority of us who are employed at this time will remain employed in the next years.

Apologists often claim that "we will move on to other things", but that is not true. Some of us will divorce further from craft and appeal to business desires in managing or other administrative jobs, but these jobs are given, not earned. The value of our work will inevitably reduce massively, and few of us will be able to do what we do now and get paid for it.

The groundwork for this has already been laid. Take a look at dribbble, and you'll find one interchangeable site after another. And this is the dataset that AI is being trained on because it can't look at an actual website; it only looks at pixels for the most part. But even if it were looking at real websites, they have long since started to look so similar that they are often only differentiated by their themes.

In order to protect ourselves from this inevitable reality (again, programming was invented to make human labor in weaving redundant; this is the leitdifferenz of the entire profession), we can learn to understand employability does not make us craftspeople.

The Craft remains

Because the craft will remain even after most of it is automated. You can order mugs online, yet there are still potters out there. We can go into C&A and buy a dress, but there are still seamstresses making bespoke garments. This is the craft's unavoidable final destination - where it all began.

Handcrafted websites are made by humans for humans. This is what differentiates our craftsperson from the factory worker—what the craftsperson does is valuable to people, not businesses.

And until that time comes, we can be both at the same time. We can hold both perspectives as important voices with different concerns. We can switch between them, look for common ground, or side with one or the other in a given situation.

So the next time you are approaching a website, ask yourself, "What would the craftsperson do?" And also ask yourself, "What would the factory worker do?" See what answers you come up with!

Post Credits

Thank you to Hidde de Vries, who in a conversation we've had, helped me to see the potential value, that a post about this topic could have.

Proof Readers & Feeback-Givers

I feel especially grateful for these individuals, who not only took the time to read through this post, but also came up with fantastic and extensive feedback, which I've incorporated into this post. Thank you so much!

Hello 2023!

2023-01-08T00:00:00Z

Yes. I have also written one of those annual-conclusion posts (thank you for reading <3). As is the case with everything I write here, it serves primarily a documenting function, with the optional bonus of maybe even adding some value to whoever reads it.

Recapping 2022 and projecting the near future feels extra appropriate — even necessary — this time, because 2022 has been a very big year for me personally.

Lean Coders

In 2022, I started a new position as a UI Engineer and Product Designer at Lean Coders. This was a somewhat radical shift in many ways for me. I went from continuous development on a single product in a set team to working on a variety of different projects and clients, sometimes in a team, sometimes on my own. Lean Coders is also a remote-first company. We have offices, but I've now adopted a fully remote work-life balance that I am very happy with. I am enjoying the benefits of working from home, which I never thought would happen, but then again, life had different plans.

It was at that time that I also decided to leave behind any aspirations for achievement in design. While I am still a designer, I am not pursuing any goals in that discipline any longer. This specific part of the industry has changed too much for me to feel aligned with any longer, and so have I. Focusing more on development has brought a sense of play and freedom into my professional life that I once felt with design. I am still very, very happy with that decision!

In November, I also assumed a new position at Lean Coders as a technology evangelist. We're still figuring out exactly what that will mean for the company and for myself, but it will inevitably mean that I'll be focusing my efforts on producing content and on becoming more accessible as a public figure. Or, well, becoming a public persona to start with!

Beyond Tellerrand Düsseldorf

I attended BTConf in Düsseldorf! While this conference is always well organized and filled with fantastic speakers, it was especially special to me because I got to meet the fantastic Stephanie Eckles in person. We were both co-organizers of the Eleventy Meetup at the time and had had some contact over the previous year.So meeting in person for the first time was a great opportunity that I didn't want to miss.

Project Congruence

I had some major breakthroughs in my personal life this year. This marked a major paradigm shift in my life. Without going into too much detail, I finally understood all the strange connections between my eating disorder, attachment trauma, and my childhood and how they manifested in my daily life. For the first time in a long time, I felt that a window had opened, that if I were just courageous, I could take advantage of it and manifest some long-awaited changes—and I did, and it worked!

As a psychosocial counsellor (in training, under supervision), I am obviously a big proponent of psychotherapy as a vehicle for personal growth. And for these processes, therapy was an invaluable instrument—a tool that accelerated them. As part of this, my relationship to food changed severely, which had always been a big topic as I had been living with an eating disorder since I was 11. This year, I am happy to report that not only haven't I had any eating disorder-related adverse events, but I also have been able to let go of its compensatory function in my life. As a result, I started to lose weight, and I found great joy in exploring hiking and eventually running.

I'm a runner now.

Yes! This has been a life-changing experience. Not only because I was able to test some of the tools I am using in my work as a psychosocial counsellor but also because it supported me in my weight loss journey, which is truly a journey toward more congruence.

My very first run was on the 7th of August, 2022. It lasted for 18 minutes and 46 seconds. I took many walking breaks, and I lasted for 800 meters. I weighed 145 kg, and I had a resting heart rate of 90 bpm. Since then, I missed a run once because I was having a cold. Ever since, I've been running at least three times a week, slowly increasing volume and intensity.

As of writing this, my longest run is 18,93 km, which happened on the 9th of January, 2023. I ran for 2 hours, 41 minutes, and 32 seconds with no walking breaks needed. I am 117.4 kg heavy now. Meaning that I have lost 27.6 kg in 5 months. My resting heart rate averages around 54 bpm now.

Strava reports that I have run 425 kilometers since I started. I am slow, but that doesn't matter to me yet. I have taken a very, very slow approach to building up my running habit, which I'm going to go into detail in a separate post. My top priority was to run safely and injury-free. So after six weeks of running, I hired a professional trainer, Verena Ullmann. I needed to make sure that as I am learning this sport, I am doing it the right way. I got valuable insights and adjustments for my training plan from her. Just having a professional that you can run your questions by is so valuable. It gives me so much confidence and makes me feel like I am not alone on this fitness journey and that someone has my back.

Next year, I have an interim goal of running a half marathon. But I don't want to stop there. In total, if I just keep my current running volume, it should be easy for me to log 1400 km of running next year. But I'd rather keep it small and achievable. So I am setting a goal of 750 km next year, in total. in hopes of exceeding it! I also want to improve my time for the 5K distance. I attended the Vienna Night Run with Lean Coders in 2022, and it took me 43 minutes and 56 seconds. This year, I would like to run that distance in that race under 40 minutes, again in hopes of exceeding it.

I am also looking to keep losing weight. Though I gotta rephrase that because to me, it's not about reducing something; it's about increasing something—the feeling of congruence between my body and myself. I am planning to get to 95 kg, also here, with the hopes of exceeding it. But even if I get just near that, I'll be very happy.

Speaking...?

As part of my new role as technology evangelist, I am going to start speaking at events. I have a lot of stuff to share. I already had the opportunity to speak at the Web Zürich Meetup, which was a lot of fun! But it was my first real public speaking gig, meaning I have lots of potential to improve. And next year, I am planning to do so!

Counselling

In just a few weeks, I am also having my final exam for my psychosocial counselling studies. It has been two and a half years, and I am really excited to finish it. This has significantly impacted the way that I live my life. And as I am now an aspiring "Systemic"—as in, someone who practices systemic counselling or therapy—that's how they call themselves, I found some really unexpected ways to combine my somewhat superficial but still interesting studies of epistemological systems theory, constructivism, and cybernetics with my experience in design. I've just recently alluded to this specific connection in a [toot])(https://indieweb.social/@nachtfunke/109592074735526394).

This topic has been circling in my mind since 2020, ever since I started diving into systemic counselling. And I want to make 2023 the year that I finally tackle it. And in the end, hopefully, I will have made something to share that maybe someone else gets some value out of.

Other Goals for 2023

There is so much else I want to do in 2023. I am looking to redesign helloyes.dev. I've gotten a lot of compliments since the website went live, but I have started to dislike it a lot, though I will keep the branding! There are also some issues that some visitors have luckily made me aware of, but I never got around to fixing them because I never set aside dedicated time to work on this website. I want to change that in 2023.

The most important thing for next year will be to finally write down some of the articles I've been procrastinating on. I am hoping they'll get some traction in the community because all of them are topics that are not often talked about.

So really, that's it! I didn't include some of my personal goals, as they are, well, personal. I'm excitedly tackling 2023!

Mourning my obsolete Skillset

2022-11-05T00:00:00Z

Heads up - these specific words were important for me to write down and to share with people who might feel similar, more than a year ago. You might feel criticized or even attacked by some of the positions taken in this text. For that I can't apologize, yet at the same time I am asking you to realize that they aren't intending to attack. It's an observation based on subjective experiences, nothing more. And ultimately, this text is very emotional. And this is obviously not fully rational. There was no desire to rationaly sublimate my feelings, instead, the opposite was the plan. I am mourning, after all. I kept this in my drafts for over a year, but recent events led me to believe that maybe someone else could also profit from this sharing.

With this post, I am trying to mark a transition in my identity as a person making websites. I feel like this is necessary and a human thing to do. As humans, we create markers as we go through life, which also guide us through transitioning from one phase to the next. Often these are rituals, for birthdays, for the unification of partners, but also for separation and for loss, for death.

The industry has changed. It has become what is now worth being described as an "industry". And it is affecting a lot of people. Some in good ways, some in not so good ways. In a way, that is a self-fulfilling prophecy, because we always aspired to become what we now are but we still have to talk about the losses, the hidden costs. We, as those who make websites have not learned to endure critical discourse. Instead, it is met with toxic positivity, ultimately dividing the people into segments. A classic way to prevent conflict: splitting.

So I am trying to broadcast my inner processes about the web industry and my place in it. Not in the hopes of creating more division, "tribalism" as they say, but to hopefully normalize ambivalence just a bit. All conflict has also the potential for realignment, discovery and reconstruction - in other words: conflict is a function of bifurcation, of possibility.

JavaScript eats the world

The most easily distinguishable artefact that speaks to the changes in the industry, the markers that define the outer and the inner, that which we positively define (as in, it is here) to the now and negatively define (as in, it is not there) in the before, is the role of JavaScript on the web platform. JavaScript had a moment, a transitional phase, in which it forever changed its position and thus how those who work on the platform relate to it. I believe it is safe to say that this transition can be marked with ES6.

ES6 was highly celebrated. It brought many things to developers that they deemed missing (in comparison to other realms of programming) and their adoption in the browsers didn't matter, because transpilers made sure that developers didn't have to think about this part of the ecosystem. Instead, they could focus exclusively on the DX. I believe that this is the turning point, this is where everything changes forever, because it brought the SPA mindset into the general tooling ecosystem and thus affected even those that didn't develop SPA's.

Bower, Gulp, Webpack...

During that time, it was still somewhat common to write code for other people that was intended to land on the website itself. This might sound a bit weird, but what I mean by that is that when we downloaded jquery, we just linked that downloaded JavaScript file with a script tag in the head or somewhere in the body. There was even a tool that made this much easier, called "bower". I used bower to include whatever I needed. But pretty soon, bower started prompting me a passive-aggressive message, asking me to use webpack instead.

To me, this was incredibly odd, because webpack did something entirely different. Bower downloaded files from github into my project in a folder, and I then linked those files. Drop-in dependencies with no further processing required. Yet Webpack did something entirely different. And it did it in a way that was entirely foreign to me. It wanted me to point it all towards a JavaScript file. Which, in many cases, I didn't even need. Sometimes I just downloaded icons, fontAwesome, or some svg stuff.

I started to realize that the game was changing but I wasn't aware of what was actually going on. Because while I was happily writing HTML, CSS and the occasional jQuery Code to build the frontend of dynamic websites (that means there is a server language involved, such as PHP), other developers were ditching PHP and the short but highly celebrated Ruby left and right to render as much as possible in the client, the SPA was slowly starting to become the major way of doing things.

The Website / Webapp Dichotomy

Even before that, people kept justifying their technological choices by referring to their websites as "webapps", postulating that their needs are inherently different and need different solutions. There is no point in fighting this dichotomy, because the people involved have by now clearly adopted this way of hierarchically sorting website. But let's be very clear - a web app is also always a website. This dichotomy does not exist on the platform, it exists as an epistemological device, with the function of determining which tools (approaches, methodologies & technologies) are appropriate and which are not. Maybe there is an exception to be made for electron apps, which use web technology but don't run on the web platform. But web apps are always also websites, yet not all websites are also web apps. What is the difference?

The difference lies exclusively in how people and companies relate to it. This blurry term often encapsulates varying degrees of properties and attributes that they see positively defined in webapps that they then see negatively defined in websites, such as interactivity, processing of API's and, as of lately, how the code gets shipped. Epistemological devices in language are essential and important. They mark a commonly shared understanding of how something is described, explained and evaluated (Simon, Fritz B.) - in other words, how we make sense of something. It prevents conflict. If a decision is made about what term perfectly encapsulates the meaning of something, we can move with our cognitive processes and live with the consequences of that decision. This is a natural process, yet it comes with a big cost, once this very fluid, very organic process gets manifested from the world of language into the physical world (as in, code).

Single Page Applications (SPA)

As this understanding of differentiating between website and webapp started to be accepted as an ontic gospel, tools adopted and built upon its consequences. Why would you need multiple entry points in a packaging tool, if your webapp is rendered in a single document anyway? You only want a single JavaScript file, right? And this has obvious positive consequences. If a tool can assume all types of scenarios, it can optimize for it. And where gulp reflected a developer's need to have a generic tool in place that could do everything they told it to, webpack only did that one thing, and you better not stray from that path!

Even current generation of tools still mostly postulate "less configuration" or even "zero configuration". All of this onl works if they can safely assume all kinds of things about how you are gonna make your Website, err, I mean, webapp, of course. For example, Vite assumes that there is an index.html file that it will take full control over. Now what if you just want fast javascript compilation but you still work in a nicely maintained dynamic website environment, where there is no index.html before the server answers with a document? Sucks to be you I guess, better be ashamed for using WordPress anyway. You should have gotten headless instead! The SPA perspective rules everything.

This is not a hate on tools. The tools react (ha, get it?) to the changing developer needs. People in our industry are very much aware that being the person or the organisation behind a useful tool will inevitably translate to money. Either via security, attention, donations or purchases - in other words, it will translate to freedom and/or power. And yet these tools may be made with pure-hearted altruism in mind, but their much needed opinionatedness persists epistemological processes that were volatile and ambivalent (and thus subject to conflict, meaning possibility) in technology and recursively confirm their meaning. They end their possibilities. Developers love this, it reduces complexity - don't make me think.

The "happy path" lies before the developer, consequences obfuscated and alternatives out of reach, soon shrouded in mockery. Quickly are the tools and the ways that were once considered good becoming now bad, irrelevant and a new decision was made; What was once positively defined here and negatively defined there, has now flipped. The theory of complex dynamic systems coins a term for this called "attractor". In the systems-theory that is used for counselling, this is often called a "completion logic". In social systems, a complexity reducing term exists like a pole and linear-temporarily, individual units in those systems (these are "communications", not people, according to Luhmann) move towards this pole. This behaviour is called "emergence" and this movement over time is called a "structure". This is what systemic counsellors call "circularity". The results of the behaviour are recursively being confirmed and reinforced back into the system.

Much of this is very invisible. And even more so invisible to people entering the industry. Because they are seeking starting points and the obvious starting point nowadays is JavaScript. Everyone is making SPA's and those that don't are being shamed into doing so, even though there is no technical or business reason for it, they are very soon gonna have to because the developers residing in these companies are starting to realize that their experiences' worth is starting to diminish. So they are turning their site into an SPA, just because they need to hold the developers with them. Because even though developers are flooding the market, they are still being desperately needed everywhere. Because we are making SPA, after SPA, after SPA, after SPA...

How do I React to this?

Much of this trend towards SPA's was spearheaded by Facebook's React. The illusive "is it a framework or is it a library" way to render your UI entirely in the client. It was neither the first nor was it the "best" or the only one. I think its safe to say that chronologically the first wave of shifts towards SPA's was angular. Nowadays angular is not very popular with developers. But even next to angular, there where other ways of approaching client-side rendering in various degrees. Yet React became much more popular, because it had facebook behind it.

And soon tooling started to focus on it. So much, that nowadays nobody uses just react anymore. Nobody wants to. They are using "React & Friends^TM" (thank you Chris Coyier for that term!). Yet who has time to set all of this up? Developers don't have time for this, they are not given time for this, so there are now even tools for setting up your tools. And all of a sudden, people who previously entered the industry by downloading a website onto their computer, changing some stuff in HTMl and opening it up in their browser, are now not only learning javascript before anything else, are not only learning react before they are learning javascript, they are learning Create React App.

Yet in the end, they are still shipping a website. What they think of as webapp and what we keep postulating as a webapp is an epistemological construct that exists exclusively in DX. Obviously, I don't find this good. Because the complexity is not reduced, it is obfuscated. But these are the new markers that determine the viewpoints of the next generation of tools. They have a recursive effect. CSS was such an outlier in the world of making webapps, in SPA-Land where JavaScript is the reigning Entity, beheading or ignoring everything it doesn't know or can't control, that we made tools that first allowed us to write CSS inside of JavaScript, and now even obfuscate the writing of it at all. But just as it was before, if you don't see something, it isn't there. I tweeted about clamp() a while ago and someone literally answered with "because tailwind makes CSS so easy I will never use this". It's pointless to blame someone for this, because it's just a development. CSS is being eaten by JavaScript.

Demographic Changes

This changes the demographics. Because whereas writing software for the web previously meant dealing with the dreaded uniqueness of the web platform - writing HTML or the goddess forbid even writing every so awful CSS, now you can just write JavaScript and not think about anything else. And with better tooling, the unwanted complexity hidden and a single language providing the DX that developers want, everything is prepared for people who didn't used to sail these waters: Traditional Software Developers. Universities never bothered with properly teaching people HTML, CSS or even JavaScript. Because HTML and CSS are not programming languages. But with ES6+ closing the gaps to other languages, programmers can transition easier than ever.

This also means that the people that used to do certain jobs have either moved on to other things, left their domain behind and succumbed to the need for JavaScript/SPA-flavour developers or they are now sitting in management, architect, or lead positions - positions where domain-specific knowledge and experience is important, but being responsible for people is the main purpose. And now that we're finally coming to the conclusion that HTML and CSS are programming languages too, I am afraid we'll soon trade even the term "Author" in HTML/CSS Specs for "Programmer". Yet it made a difference. I never considered myself a programmer. Because that term represents something that I didn't see in myself. I didn't make apps, I made websites.

Inevitable Obsolescence

Yet the industry is caught in its circularity. JavaScript is eating everything up. CSS's much needed specs to concede to the capabilities of CSS-in-JS and Utility-CSS approaches are coming 10 years too late. Former work colleagues are probably still annoyed by me claiming that all we need is scoping (which we already had!) and that the vanilla solution is just around the corner. Now that we have it coming up, those that care are on the margins of the web platform, not at the center any longer. Soon it will not make sense any longer to cater to these people.

To a certain degree, this obsolescence is inevitable. Where e-commerce was a dedicated, separate field not too long ago, it is now everywhere. And what is considered a possible next iteration of the web, web3, is making the transaction the loop that powers absolutely everything. The web has lost to capitalism. And web3 will not change this - instead it will make it its core. I was always laughed at, when I somewhat pessimistically claimed that my skillset will not be wanted any longer. Yet I am now in this position. What I bring to the table is worthless. Because it is not speaking the language of the industry any longer. As a developer I am worthless, because I am not a "programmer" that builds SPA's. As a designer I am worthless, because gone are the times where understanding the rules of gestalt psychology, aesthetics and beauty, paired with unconditional positive regard, congruence and empathy (person-centeredness) are enough to get you a job - the only thing that counts is numbers, because it is the language of business. This is the industrialized web.

The Price of Industrialisation

Processes and tools are being unified, persisted in the process. With reduced complexity, those that were unable to navigate this previously volatile domain are now able to walk the paths that were walked before so often that not only the grass that once grew there is long gone, but that the ground is now sealed forever under asphalt. The web that was once populated by those that didn't find a place anywhere else is now populated by those that pushed them into the margin before. And I find myself in the margin once again. This is the price of industrialisation.

When the outcome matters the most, the process needs to be identical or adjusted to produce the same results. Furniture that was once only made by millions of human hands, making it unique in the process and thus made to last for as long as possible, is now being designed by a handful of people and created by machines. Today we are still needing designers and people who write frontend code. But even these people will become obsolete sooner or later. As is the price of industrialisation - because the reality of having to make money will inevitably overrule everything and everyone. And humans are still the most unreliable and expensive part of the industrial equation. Developers are already happily training code-writing algorithms for github. The habituation phase for invasive technology has long begun and new developers are not unaware of it, they just don't care about it. Empathy has been long irrelevant for designers, though it was once postulated as the most important skill to have. Why be empathic, when you can quantify behaviour into numbers and then make a decision based on this? Empathy requires a person, A/B testing does not.

Where I am going from here

I am a Designer & Developer on the Web. I know how to make beautiful websites that people will like to use. I know how to make them in a way that will support and hopefully even empower the people who interact with it. I have done this for 11 years and I will continue to do so. But I will not be able to make a living from it any longer. It will become a hobby eventually. Something that I look at with nostalgia, reminiscing about that odd time when I was actually paid to improve someone's experience, paid to make something not only beautiful, but useful - and useful because it was beautiful, and vice versa. Where I was asked to empathically understand someone in order to adapt something to be more congruent with their world view. Making websites always felt useful to me. And at the same time, I always felt the ability to venture, to explore new possibilities and to be creative. These things were not allways effective or lasted, but they were valuable non the less. They made a difference to someone.

I've made the decision to leave the industry a few years ago. I've seen the signs of obsolescence very early. For now, I am changing direction and I am giving up my bastion, because it is not getting anyone anywhere. I've tried finding a job with my skillset, and it is very clear to me that is 11 years in this industry of making more than 40 websites, Expertise in HTML, CSS are absolutely worthless if I am not also an expert in JavaScript, or if I am not at least experienced in React, Vue or Svelte.

So with this post I am mourning my obsolete skillset, which I cultivated to carefully, so intentionally for 11 years. And as it goes with mourning, it hurts and I am getting angry and sad. I learned HTML & CSS when I was suicidal and very addicted to online gaming, mourning my first love (and unknowingly mourning a childhood I never had). Because of it, I was able to make a living, sustain myself, be autonomous, which ultimately lead me to extraordinary individuals and communities. Not only that, but some of those individuals that I got to admire from afar even know that I exist and have shared messages with me. That is just wonderful.

Luckily, I can carry over these positives into a new time, which also inevitably comes with every loss. And, I have a very perverted love of being wrong about my pessimistic predictions. Maybe all of this is different. But for now, I am looking at what I am gaining. I am looking forward to learning new things, new possibilities and new capabilities. I'm excited to see where these new things are gonna carry me.

Things I wish I'd known earlier in my career

2022-07-28T00:00:00Z

I saw this post from Vitaly Friedman on smashingmagazine.com and it resonated well with lots of realisations I've had recently about my own career. So I wanted to compile my own list of things I really would have wanted to know earlier.

It is important to me to mention, that I don't write this with regret or resentment for me or my career nor to I wish to undo my decisions. At the same time, as a more mature person and experienced tech worker, I would like to share my own insights with other people on similar trajectories, not so that they do it differently, but so that they have another perspective to potentially consider, and ultimately become more empowered and self- and pro-effective.

I've done a lot of waiting and observing, and while it sharpened some skills, it didn't necessarily lead to progress in my career. It did the opposite, it reduced my momentum. And you can do a lot with momentum.

Vitaly elaborated on these points beautifully:

Never tell your salary expectations first
Switching companies is how you make more money
Pay attention to your job title
Keep Record of your Achievements
You can't have it all
Pay attention to your estimates
Test the company during your probation period
Think about passive income early

I've come to similar or identical conclusions, in varying degrees. The points I am adding on my own may or may not apply to you in varying degree.

This is more a list to myself, a record of a dialog I've been having with myself, made accessible to whom it may concern.

Separate the craft from the industry

I saw the actual practice of making websites, designing or developing directly intertwined with the larger industry. The ideals of the craft must be the ideals of the industry as well. This led me into many conflicts, in which the needs of the business clearly outweighed the requirements for good craftswomanship.

This classic conflict would not subside in me, until I eventually had to accept both realities, with their value systems and their goals, as existing in parallel. All conflict is resolved by decision. By deciding that the ambivalence between craft and industry are something I am indeed well-equipped to hold, the conflict had turned into possibility.

Rarely do the interest of automated business align with the interest of craft, not just on the web. Craft itself is always concerned with creating the best result possible. The result of our craft is served and offered to people to interact with, meaning that much of its quality is determined by the receiver. Consequentially, craftswomen align their craft around those peoples needs.

Industry on the other hand, does not care about the needs of the people - unless they can directly tie it to monetary gain. That is the point of a business. Industry is the larger application of this intention.

There is great freedom in accepting both as independent value systems, that are not fighting for objective evaluation and rigid hierarchical alignment, instead, they can ambivalently live together, in symmetrical relationship to us.

What I mean by that, is that we allow ourselves to compartmentalise and confine the needs of the industry and the craft respectively to their own contexts. If a client asks us to make the logo bigger, even though we knew it would be a mistake, we may speak up and advice against it, but if we accept this request as an expression of seeing a business need fulfilled, we can approach it respectively and allow ourselves to not see it as a devaluation of us as craftswomen, if we go along with it. Because in this interaction, we are not only paid as craftswomen, but also as employees, contractors or suppliers - or experts of process, not result. And in these contexts, the need of the craft are not primary.

Learn to ask questions, then ask questions

This is the one thing that I am sure would have improved my movement in this career, had I learned it earlier. Learning to ask questions as a discipline has become integer to me as a systemic counsellor (in training under supervision). In systemics, we accept all reality as constructed, meaning that all external descriptions of reality are merely offers that can be accepted or not. Instead of "educating" my clients about how to think about things, I ask questions that may allow them to construct alternatively themselves.

This same principle can apply to the way we interact with stakeholders and other people in our industry. If instead of assuming to be experts in our fields, and thus experts in what our clients and stakeholders need, we assume to be experts of helping our clients and stakeholders express their needs themselves, we become experts of process. And as experts of process, we become focused with how we do things, not what it will lead to. Because if stakeholders and clients have the ultimate say in what gets accepted or not, then they are the experts after all.

But what we can do, is ask questions - questions, not intended to add information to us, but to them. This is a bit of an art form, but for the sake of this little post, I'd like to give you a few examples of solution-focusing and circular questions, that I have borrowed from my counselling practice and that have proven to be helpful in my design & dev career too:

How will you know, that our work together will have been successful?
On a scale from 1 - 10, how close to what you are imagining do you think we are? What would have to change in this draft, to nudge us up or down a number?
If I showed this draft to your CEO, what do you think his feedback would be?
If I asked your users about what to improve on your website, what would they tell me?
From your previous work with designers / developers, what would you say would need to happen, to make this relationship fail completely? [In order to avoid it]
Until today, what have you tried already to improve the UX of your website? What has worked already, what hasn't?
How will you know, that the changes that you are suggesting will get you towards your goal?
So in this current redesign, you said you want it to be less [adjective], right? What should it be instead?
Now that we are gonna change your website, in your opinion, what should definitely remain intact / what works really well?

None of these questions are intended to give the person asking the question information. Instead, they are intended to create new information within the client itself. I've asked these questions to clients directly and if they have a hard time answering, then that is usually a good sign. It means, that before asking that question, they haven't thought of it before. Yet, asking what to leave intact on a website redesign is not only a really valuable information to have for the process, but it also important for the clients to get a better feeling of what they want and need.

Same goes for asking circular questions. Circular questions are asked in order to gain information about relationship dynamics, without having to have all the people in the system present. For our context, there is a system and a dynamic present between our client and their users / customers. We can never gain objective information, instead we ask the client about how they are experiencing this dynamic: "What would your users tell me, if I asked them right now..." - This question invites clients into a meta-position, in which they are observing themselves / their business / their website from a user's perspective. You'd be surprised about how specific and accurate these answers can become, or how shocked they are, if they realise that they actually do not have an accurate enough picture to answer that question. In the latter case, this is what you need to focus on.

This is just a small excerpt about how I am approaching questions nowadays. I believe that as experts of process we need to become masterful questioners.

Avoid "why".

I would like to focus Why-Questions for a short moment. I picked up the idea of the 5-why's very early on and started using it. It made a lot of sense to me. Nowadays, I avoid "why" as much as possible. The idea of the question is to find out about how someone else sees something, what their logic is, what their reasoning is.

But why as a question can be a spearhead, a weapon that stings. Instead of inviting people to reveal their thoughts, it may force them to justify themselves. And to that, we have no right to ask stakeholders to justify their choices. Not only does it danger the complementary (hierarchical) relationship we are in, it may create a power dynamic with us at the losing end on it.

Instead of asking "why", we can ask "what for" - as in, "what will this be good for / achieve?" - not from a place of disbelieve, but from a place of respect for the desire behind the request, with the intention to understand said desire. Another way of getting to the same place, is to frame it a bit differently, like: "At the moment I don't yet understand what you are improving with this change - can you explain it to me so I can support you better?".

The gist of it is that the question "why" is often an attack - try to avoid it.

Don't stay for the "potential"

I have spent years in companies, waiting for an either promised or imagined reality, that never came to be. I joined and I saw potential of how good things could be, and I saw myself thriving in this potential reality. And while I poured my heart and twenties into these companies, the potential went unfulfilled until it eventually rotted away and I was forced to start anew.

I did not see this pattern until very recently. Now I know, that staying with a company for how things could be, is a draining and dooming attitude towards yourself. If we allow ourselves to remain in unsatisfying and lacking situations and circumstances, despite having the choice to go another way, we are treating our own needs and also our time with disrespect.

We see all this potential, and we believe that if we just stay for long enough, and if we just fight hard enough and pour enough of ourselves into the company, it must eventually lead to the fulfilment of said potential, with us thriving in it. And it may happen, but if we stay for the potential, we are just gambling with our time. Time, that could instead be poured into a position that is giving us what we need.

I don't regret my time that I spent waiting, suspended and having to understand that things just can't be different right now, but that the company after all is growing - but looking back I can pinpoint exactly the time when a part of me already knew that it would be doomed, and yet I stayed, leaving only me to blame for it in the end.

If we want to achieve certain things in our career, we are left alone with it. Especially as a queer person, even though I am still much less discriminated against, I am still over mentored and under sponsored. The only way forward, is to be self-sufficient and pro-active when it comes to my career choice, because nobody else will lift me where I want to go. I need to go there myself, and so do you.

Always be looking at open positions

In order to have movement, you need to be able to have possibilities. Without options, there is no movement. This applies to your career. Always be aware of other potential positions for you to apply to. In our industry, increasing your salary is only really possible by hopping from one company to the other, as Vitaly has already pointed out in his article. I didn't know that. I had to turn 31 to come to this realisation.

If you are like me, you might have grown up in a time, where older generations proudly talked about how long they had been with a firm and you may have sensed a feeling of pride and respect. This is a generational artefact that most of us will never experience. This thinking is so old, that nowadays, if you are not changing companies every 1-2 years, people will assume something was wrong for you staying this long. This has happened to me before, in which I was asked to justify myself for staying with a company for so long, despite not getting into higher positions.

Even if you are not intending to step up the career ladder, keep looking and maybe even applying to other positions, in order to know what the market expects you to be capable of. Your job may not offer you the possibility to learn and master tech that maybe other companies will require you to be experienced in, should you lose your job suddenly.

Be loyal to the people, not the business

As is true for separating craft from industry, it is valuable to differentiate business from people. I never separated these two, because I've never worked inside huge corporate environments. So asking for raises, different hours, or saying no to the business automatically meant asking for things or saying no to that person that I was on a first-name basis with. But it is very different to ask for a raise from a friend, or to ask it from a company.

As you build relationships to the people over time, try to separate them from the interest of the business. We can be accepting, loving and tolerant with the people, while at the same time remain firm, confident and in-control with the business.

When we ask for a career plan, the people answering, are representing the business, not themselves. And as we ask, we are not asking as people, we are asking as employees. Same principle applies to interacting with clients, even as freelancers. As people, two individuals working together on a project, being welcoming, understanding and empathic is required to a positive relationship, but as a one-woman business, I may have interests to protect that are directly tied to my existence as a person in this world.

Ultimately, it is practicing separation of concerns. As humans in friendly relationship with each other, we have different concerns than the business who are dancing through a carefully orchestrated transaction.

Consider an exit strategy

I believe that we are reaching a point in tech, where we are automating more positions than new positions are opening. It certainly is the goal of tech to make people redundant. And in an ideal world, all of these people would move on to other jobs. But that is not the reality. Some people will move up and move on, but many people won't.

If I were to join tech at this time, I would make sure that I had a backup plan. I believe in diversity and I personally learned that I have to not focus too hard on one thing, but instead learn to balance many things simultaneously.

In a way, this sentiment is also expressed by Vitaly's point of thinking early about passive income. But the truth is that most people working in tech are not present on social media or even have the desire to invest even more time in addition to their already cognitively and socially demanding day job. It certainly is an attitude that we are seeing as a result of generational change and I believe it is rather healthy.

Your job may just be a job and that is fine. But tech is only a secure job if you are willing to switch gears at any given point in time and if you are willing to do the industry's bidding, maybe even forcing to ignore your own morality in the process of it. There is no denying the volatility of even the smallest aspects of tech.

And let's not forget the fact that sitting for hours on end, no matter how much you are stretching in between, will either force you to counter-balance it (inadvertently sacrificing even more time on the job, because you are trying to undo damage) or deal with the consequences later on.

Chances are, that you are working in a company that is held "exit ready" at all times. That means, that they are making sure that if push comes to shove, the few people invested in the company can sell it and exit the business, leaving with a profit in the process. And I think as tech workers we need to do the same. This doesn't mean that we should prepare for a doomsday scenario, but it may be wise to widen our options, consider an alternative or maybe complementary path. Keep your options open and diversify. Companies do it too.

Don't take career advice from anyone

As a systemic counsellor, I am aware that no reality is constructed from the outside. Via communication, messages are decoded, sent, received and decoded. A famously lossy process in which meaning is given to what was decoded, not found in it. All interventions are offers, invitations of alternative constructions, but the construction is done by the client, not the counsellor.

For that reason, I think it is in general not a bad idea, to think of all career advice with an asterisk that reads: "May not apply to you".

Come to your own conclusions and where as well intentioned people can become powerful allies, mentors, sponsors and friends - but making their interpretation of our career a requirement for us to pivot is not a good idea.

Aim to be as self-sufficient as possible - while at the same time not thinking that all success will always ever only come from you. All success has a component of luck or at the very least privilege playing its part. But I've come to understand that if I want to be autonomous with my career, I need to to be sure that I am able to move on my own. And for that I need options, the ability to discern and a little bit of momentum.

Don't take it too seriously

My last piece of advice I would give to myself would be to not take it so seriously. If a feature wouldn't end up how I designed it, if an animation wouldn't turn out how I envisioned or prototyped it or if a stakeholder just needed to take a dump on my work in the very last moment, it would feel like someone had eradicated all my time and effort. My ego was so hurt that it would keep me up at night, forging plans to save myself from yet another loss. Working became a game of counting wins and losses, hoping that eventually, it would turn out in my favour.

Yet at the same time it prevented me from seeing the possibilities that these situations also had offered me - including the compliments about how I had approached my work. If the end result can only be a win or a loss, nuance gets lost and instead of seeing lots of small wins and a few small losses, it turns into one general loss that overshadows everything else, eradicating all the things that went well.

So nowadays I approach most of my work with an explorative mindset, with the knowledge that if things don't turn out well, that other things will have gone very well and if push comes to shove, I'll be able to deal with the situation as it happens, and with its consequences as well.

So that's it. That's what I would tell myself retroactively. I wonder what advice I'll give myself in 10 years, if I still work in this industry that. Though don't mistake, I'll still be writing HTML & CSS, I just don't know if I'll get paid for it! :P

RE: CSS Breakpoints every Developer needs to know

2022-07-21T00:00:00Z

There was this tweet. You know which one. Well, this post is an attempt to bring structure to what went through my mind when I saw it. First I'd like to dissect a bit more what irks me about the original premise of the tweet, and I'm ending with a suggestion for an alternative mindset - but in the same frame of the original tweet.

Obviously this is not meant to insult. But I do believe that we need to talk about things that are not working. I believe that this is one of those things where the phrasing infers that parts of the community is already relying on a mindset that is incongruent with the underlying concepts of the platform they develop with and on. And I think that is a problem that we need to address. So this is what I am attempting here.

There are no "CSS Breakpoints"

What this idiom refers to is media queries, usually querying the size of the screen. Most people where annoyed by the nowadays really antiquated, to a degree even inappropriate idea of treating media queries for specific sizes (such as 320px, 480px, etc.) as substitutes for specific devices. But that is not what made me upset, instead it is the usage of the term "CSS Breakpoint" itself.

It demonstrates the severe lack of basic understanding of the web platform and how the languages that allow us to build on it interact with it. There are no "CSS Breakpoints", because not only is it not CSS that is breaking, but they are also not exclusive to CSS.

Even in the earliest drafts of the media query spec, querying media properties from the media="" attribute in a <link> element was possible. Though that argument is a bit of a stretch, I get that. So let's focus on the other one:

What is breaking

We write our styles and develop our sites and as we test it by subjecting it to all sorts of environmental hazards, such as making the screen smaller and wider, we may encounter moments from which on our styles seem to not work any longer, they seem to break. We're testing a bit further and pretty soon, we may be able to pinpoint the exact threshold, from which on we need to adjust our styles. This point is called a "breakpoint", because at this point, the styles our code results in, break.

It is important to understand that it's not CSS that is breaking, or its properties. In fact, it all does exactly what we programmed it to do. But we've decided that what we've programmed should only apply to a certain point. And from that point on, we want different code to run so that the styling adjusts to be more appropriate for the given screen estate.

It is interesting to point out, that I just couldn't find the origin of the term "breakpoint". In my mind, it was part of Ethan Marcotte's Article / Book "Responsive Webdesign". But it isn't! I unintentionally nerd-sniped Ethan with a tweet and he himself couldn't pinpoint its origins. But he did some valuable research in this little journal entry. Read that too! And thank you for the mention :)

The breakpoints you need to know

Your CSS is not breaking. It's the style that stops working under certain conditions.

Don't name your SASS variables "phone" or "tablet". Yes we did that for a while, because the ideas of responsive Webdesign where almost a remedy for dedicated device-focused sites, which were often a sad excuse of their desktop-mother-site.

But we've since long moved on. The truth is that there is no set of salvatory collection of pixels that you need to memorise. You need to write your styles, test it and see at which point it breaks. There. That is a a breakpoint in your layout from now on.

Holding Complexity

The argument against this is that when you work in a team you'll want a shared set of predefined points that you can refer to. A valid concern, but it has little to do with the nature of the web platform or the reality of device sizes. The only reason we find this effective is because we are trained to spot potentials for reducing complexity in programming. And sure we should do it - but we better remember that we ourselves constructed these breakpoints and that they have little connection to the reality of the platform or our users. We do it for the business.

The Web as a platform is as flexible as a programmable environment will get. It mirrors many qualities of social systems and so it is capable of holding ambivalence and an extraordinary amount of complexity with ease.

Not everyone makes websites for a business. If you are working on a website on your own, ask yourself if the doctrine you are following in order to please the desires of the industrial exploitation of the web platform is still serving you and the people you are making the site for.

Layout is a fading concern - meet your new breakpoints

Stephanie Eckles has countlessly, beautifully demonstrated that modern CSS that you can safely use right now in your projects often reduces the need for screen estate based interventions in form of media queries. Meaning, that the CSS we write becomes more and more resilient to its environment and truly responsive to it.

This is mainly experienced in the way we are programming layout, but not exclusively. But as we are more inclusively approaching the way we design and develop our sites, and as we write less media queries to adapt our layout-based styles, we realise that nowadays, there is a whole new dimension of circumstances, that can make our styles break. These are our new breakpoints, which actually, every Developer needs to know:

Motion Preferences

If your site heavily relies on motion then it will break for some people. They will have a very bad experience or may even be unable to use your site at all.

Luckily we have the tools to adapt to it, with the prefers-reduced-motion media feature.

More about this

MDN - https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion
Una Cravats, for web.dev - https://www.youtube.com/watch?v=_ZdZh-ESOHY
Michelle Barker, for smashingmagazine.com - https://www.smashingmagazine.com/2021/10/respecting-users-motion-preferences/
Thomas Steiner, for web.dev - https://web.dev/prefers-reduced-motion/

Pointer Variety

People using your site may not click, like, ever. Because they may not traverse it with a pointer device at all. Maybe they are using their finger, or they are using a keyboard, or something entirely different. If your site relies on exact pointing, or if it relies on clicking at all, it will break for some people. And some people may not be able to use it at all.

This is another feature, we can query, with: pointer, and we also have the hover media feature, to specifically query conditions in which :hover is possible. Besides just CSS, making sure that your site is keyboard accessible will make sure that people relying on a keyboard are included.

More about this

Christian Diaz, for smashingmagazine.com - https://www.smashingmagazine.com/2022/03/guide-hover-pointer-media-queries/
David Walsh - https://davidwalsh.name/pointer-media-query

Color Scheme Preferences

Often trivialised as "Dark Mode", for a variety of reasons, people visiting your website may require your site to be either on the brighter or on the darker side.

We can respect this preference with prefers-color-scheme.

Contrast Preferences

Not only may people in general prefer and rely on websites that are high in contrast to see what is on it, but they may even bring their own colors with them, by way of forced colors.

The media features prefers-contrast, forced-colors and inverted-colors allow us to consider this context.

More about this

Ben Myers - https://benmyers.dev/blog/fix-low-contrast-text/
Eric Bailey for smashingmagazine.com - https://www.smashingmagazine.com/2022/03/windows-high-contrast-colors-mode-css-custom-properties/

Reading Direction Variety

People visiting your website may have very different understandings text flow.

In order to be inclusive with this context, we can rely on plenty of things. One of the most important paradigm shifts is the switch to logical properties, which are relative to reading directions of the settings of the people browsing the website. The other one is making use of pseudo-elements such as the :lang and :dir selectors, to intervene, when something is breaking.

Una Kravets postulates the new responsive to be respecting user preferences. Maybe that is not just a result of increasing capabilities of the platform, but also of our increasing capacity to accept the complexities of the human realities it has to respond to in order to serve the people on.

As the platform becomes even more capable of holding complexity, the contexts in which our programming will result in something breaking for someone will just increase. And so will our capacity to adapt to it.

Unfollow people that give you listicles of arbitrary pixel values to satisfy your desire to have it easy. The web is easy. But it is also very complex. You better get into it!

I'm not pursuing design any longer

2022-06-04T00:00:00Z

"Do you wanna focus on design or development?", people I worked with used to say all the time "It'd be good for us to know so we know where your career is going". For a while I thought I had to decide but I eventually decided to pursue right what is in between, the middle between Design & Development.

I still think that my sweet spot of talent and experience is right there, but after a few months of deliberation, I have come to decision to not pursue design as a career path any longer.

What it was

I found my way to the web platform via Graphic Design. I made wallpapers, avatars, signatures, etc. But I did fall in love with HTML and CSS when someone asked me to design a website and told me that would need to learn HTML & CSS in order to delivery.

That website never came to be, but I had gotten hooked on the platform. I devoured books and blogs like crazy about everything HTML and CSS - but always as a designer, in which Code allowed me to manifest what I had envisioned.

I eventually ended up never having only a design job. Design was always part of it, but I was always a Designer & Developer Hybrid. When I got my first job, "Web Designers" were expected to be proficient in HTML & CSS as well. But I quickly learned that design was judged very differently from code.

Nobody cared about what the code looked like. They wanted results. But design was different. Not only did they only care about what it looked like and didn't care about results at all (or more like, they didn't correlate visual design with success or failure on the business side) but instead they saw it as an extension of themselves.

Whereas with Code, I was explicitly given Expertise, as in, the trusted power to decide, in Design, the Expertise was always conditioned on how much I was able to bring forth what the client was not able to express without me.

What it is

Design as a Profession and a Value Proposition has changed since. Nowadays, understanding of design as a meta-discipline is omnipresent and visual design is happening everywhere and with more frequency than ever. That has good effects too, but more than that, it has turned Design into a demand that needs to be present in an industrial pipeline.

Thus, design is now being approached with industrial tools and industrial mindsets - and industrial demands. Never have I ever felt more disconnected from the energy that drove me there in the first place.

To me, Design was always a process formed around the desire to create something specific to the unique context of a given problem. And I don't think this has changed, but I think the problems have changed.

New Designers in Bootcamps rarely learn basal skills that are required by the craft. Instead they learn industry tools that will make them hireable. "Design Systems" are not being used to facilitate design, they are being used in order to not having to dedicate time and money.

I heard in a podcast a while ago, that "you shouldn't make your own design system anymore, always start with an existing system". Another Design Influencer on twitter postulated that there should be a global design system and that designs should just use themes.

This couldn't be more incongruent with the spirit that I channel in my work. I wanna sit down with a project and think about what could be done for that project. I don't wanna take an existing design decision and adjust some values. I am not saying, that configuring design tokens is not also an act of design, but I am saying that it is not enough for me. It bores me to tears.

And that's why I am no longer pursuing design as a career path. The truth is that there is much more of that creative spirit in development, and more so than there ever was. I still JavaScript is nasty and needs to be avoided at all costs (except where it includes people), but I'd rather become a JavaScript Developer than keep constantly fighting for basic validity.

Obviously my years of experience and my inclination for good design follows me wherever I go. But for the time being, I will not look for jobs and opportunities in design any longer. That dream has died long before the pandemic, and a part held on until now. But now I am tired of waiting and I am moving on.

Recapping the last 6 Months

2021-11-13T00:00:00Z

This time of the year usually means introspection, readjustment and realignment for me on a personal level. This time, it's really special, as I reflect upon the last 6 months, since leaving my previous job. I decided to leave.

I left a lot behind, because the individuals that made up my team and the greater company in general, where and still are exceptional to me in so many ways. Leaving easyname was very difficult for me and I didn't yet know how difficult it would be, in the months coming.

While I also reflect on this - privately - I wanna take this time to publicly take an inventory of the constructive things that I was able to do in this time. In narrative therapy, we call this "internalising", in which we bring a narrative closer to us. This usually takes out the volatility of a narrative and instead solidifies it.

Usually I write myself a letter, by hand. This time, I wanna see if maybe there is value in making some of that process public and share it with other people.

I made a tiny personal brand

I created the "hello, yes." brand! It is something that I used to say in our internal team chats whenever I started a new conversation. It has a certain quality of derp that just speaks to me. And where I took it visually, it quickly started to feel like an iteration on what little there was before, when my personal website was just "thomassemmler.com":

The old thomassemmler.com. I never invested too much time into it, and it ran on jekyll. So I decided to redo it entirely.

I recycled "Work Sans" as the main headline font, and I added "Poppins" as the paragraph font. As I started working on it, I realized that maybe a new domain would not be too bad of an idea. I had the domain "fantastic.horse" for a year, just because I found the domain "pudding.cool" so dumb that to this day it makes me giggle that someone came up with this idea. That is how the idea to re-brand myself not just with my name but with "hello, yes." came about in the first place, and it inspired me, so I went for it.

The first draft of the desktop version of the website.

I have this weird desire to use graphical elements to fill up space. Just because I don't wanna throw some meaningless words at the canvas but I also don't wanna show photos, so graphical elements it is. Yet I am not an illustrator, so I often end up making simple compositions with basic shapes or textures. This is how these shape-composition illustrations started as well.

The illustrations are composed of really simple shapes.

I had fun finding a rule set for these compositions. Analog generative art maybe? I am actually planning to do some generative experimentation with them. They actually also lead me to experiment with inline SVG patterns! I even blogged about this:

Very simple Patterns with SVG

from my blog

I originally started out with a different layout, inspired by Andy Clarke's article on compound grids. But I eventually had to write 4x the media queries, because of how the main-column on the website was defined. So in the next iteration, I rid myself from that pain and returned to a plain old single column. It's still a compound grid, but it's centered now. For the most part. A perfect use case for container queries, btw. If you haven't noticed, they are coming.

I connected with exceptional people

On the development side of things, I decided to reach for eleventy. I always knew that I wanted the site to be statically generated. I've worked with jekyll before, so moving to eleventy seemed logical and that journey was mostly very smooth, but I did run into some things that I needed help with. That's when I discovered that there was actually an eleventy community discord, with quite a few very active people in it!

And while I asked questions and received useful answers (usually very quickly), I also started helping other people with their small problems, as I had already encountered and fixed some of them myself before.

I also noticed that they even had an official Meetup! I attended the very first one meetup and was just amazed by how close some of these people all of a sudden felt to me. This was a big deal, because even at my previous work, only my colleague and now friend Cezar Neaga was actively participating in community activity surrounding frontend web dev. But to have so many people close to the domain that I am also continuously falling in love with? That was quite a formative experience for me. It allowed me to see that I can actually connect with people, not just by reading articles and sending an occasional tweet, but more meaningfully.

THE Elventy Meetup

They announced that one of their co organizers had to step down and that they were looking for a new member. I did not hesitate a single second and asked to join immediately. This was important to me, because I saw a chance to contribute to a community that I quickly started to identify with. I didn't wanna mess this up, so I tried to keep my steamrolling as low as possible. The coolest part is that I get to collaborate with Sia Karamalegos & Stephanie Eckles on a thing that is intended to create community. I just love that. And we even won an award for "Outstanding Community Meetup" during the Jamstack Conf 2021!

THE Eleventy Meetup

11tymeetup.dev

Frontend Horse

During that same time, I also stumbled upon Frontend Horse stream on twitch, by accident. And they just happened to also have a discord community, which I quickly joined and discovered lots and lots of really fantastic people there! It was then that I realized how much I had craved to feel connected to community and that even during my previous employments over the years I never felt this.

Frontend Horse Twitch Schedule

frontend.horse

These two communities specifically made a big impact on me and changed how I now relate to myself as a developer/designer and how I related to the industry at large through the lense of my craft. This was really important to me. Leaving easyname was necessary but difficult, emotionally and socially. These communities filled a very real need for connection and social interaction which helped me get through his transitional period in my life and career.

It allowed me to connect with many amazing people, beyond just the discord channels and streams: Stephanie Eckles, Ben Myers, Ben Holmes, Alex Trost, David Aerne, Manni Ikomi, Anatole Ayadi and so many more. Some of these people offered their ear to me and offered their professional expertise and their personal advice when I really needed it. Having these connections made a big difference, professionally and personally. The sad part is that I will probably never meet many of these people in person - but I have learned to not assume too much about these things, one never knows!

I blogged

Also, after 10 years of wanting to do so, I started blogging. I've written 6 posts - plus one post that remains private. I didn't find it too difficult to come up with topics to write about, though I do find it sometimes a bit challenging to not just rant about stuff. Also my habit of just word-vomiting out stuff gets just a bit more held in check by people actually reading it and then telling me about my spelling mistakes.

I'm still refining my approach how I write. I am maintaining a somewhat decentralized backlog of topics I want to talk about. As in, some of it lives in my phone, some lives in an obscure trello board (I think) and there is actually an A5 yellow postIt flying around my flat somewhere, that I cannot find. Oh well. One could call it an organic, maybe even a self-organizing process.

I tweeted

I am in my personal life not invest in social media. I have accounts everywhere except tiktok, but I only really use twitter, where I have developed a habit of ranting about the industry. I took notice those few followers that I have tend to not really care bout this at all, as they are usually not reacting. But it still feels cathartic to me. There is a lot of stupidity happening on tech twitter that I don't really like. I do not want to be seen as part of the grifter section on twitter, so I'd rather be seen as critical, a devil's advocate even.

Also, I am really happy with the velocity of growth of my following, because it keeps my bubble quite far away from much of the nonsense that I notice people with larger followings seem to be subjected to. I would still like to grow my following though - but this speed seems to be pleasant to me. I grew from ~100 followers to ~250. Maybe I can aim for 300 or 400 followers in the next 6 months. I'd be super, super happy with that!

I did code things

The irony behind my my professional journey is that whenever I stray more into design or development, I always get somehow pulled back into the other side. I have accepted the fact that I am wandering the space in between. So I shouldn't have been surprised that I experimented so much with code, and yet I still was. But to be fair, all of these things started as design and they needed to be solved in code.

The biggest thing was the basic pattern repository. During this process, I needed to do something that I've been wanting to do for a while: learn how to hand-code SVG. Or in this case, understand the svg's path command syntax. It took a bit but eventually I started to understand why some people actually prefer writing it by hand instead of using the pen tool.

Due to some key people actually picking up on it and finding it worth mentioning in social spaces, it got a bit of visibility in blogs, listings, etc. All of this lead to 190 stars on github. Which I am told is a good number. I was really surprised about this, because what value it brought felt niche to me. It made me really happy to feel that apparently it is valuable to other people!

Creative Code Stuff

I also started playing with Houdini, with paintWorklets to be exact. I've known about them for quite a while, but recently (in my bubble at least) attention on this topic seemed to increase. Inspired to look at it more closely, I quickly identified a design for a website I was working on, that actually would benefit from this approach and started playing. After investing a few hours into it I am now 100% convinced that writing paintWorklets is a great introduction to writing canvas JavaScript code and maybe even generative coding in general to a certain degree. The power a simple Math.random() can have is amazing!

See the Pen vYZogLx by Thomas Michael Semmler (@thomassemmler) on CodePen.

One of the first experiments I did was trying to render a box with rough edges at the top. I needed to understand quite a few unfamiliar things in order to achieve this. And I think I got about ~85% of the way there, but then got stuck trying to smoothen out the generated bezier curves.

I have no mathematical skills what so ever, so the equation needed to position the bezier curve handles in relation to each other was graciously provided by Leif Niemczik! He also endured all of my stupid questions regarding the math behind it and my increasing frustration not being able to cognitively grasp it. Because obviously it isn't enough to just get the result, I also need to understand how it all works. It eventually evolved into this:

And then I didn't stop there. I reused some of the things that I learned while playing with this and I made a tiny little houdini template that allows for drawing of horizontal lines that have a hand-drawn look to them. And it's even available on NPM!

See the Pen JjyErxw by Thomas Michael Semmler (@thomassemmler) on CodePen.

I also collaborated on another really small code sketch with David Aerne. I actually started out with this code to do something entirely different, but it wasn't too much work to make it look really pretty. So with some of David's help, this was the output:

See the Pen ExvwMPy by Thomas Michael Semmler (@thomassemmler) on CodePen.

I find the end result really satisfying! :D

I talked (kinda)

I also got the chance, twice, to do something that I always wanted to do: giving talks. I firstly talked at the eleventy meetup, in where I did a walk-through the basic pattern repository, from an eleventy point of view. And then I also went on the Frontend Horse Halloween special, where I talked about the BIOS CSS approach to organizing large scale CSS!

That's it. Thats my 6 month assessment of the positive things, maybe even achievements, since May. I'm excited to see what other stuff awaits in the future! I wanna write more content. I wanna collaborate with even more people. This is what I really enjoy the most - working together with people. It does not matter if it is design or development. I just like to feel intellectually and creatively in synch with people. It feels just right.

And this is what I am gonna emphasize on in the coming months. Depending on how it feels to have this post out in public, I might do another post in 6 months, so in May, 2022. Or maybe not. We'll see :)

Make Eleventy the next thing you learn

2021-09-22T00:00:00Z

This post is specifically for you - the person who has just started to learn how to turn your designs into code. Or you have heard from someone that you need to learn HTML and CSS in order to make websites and now you know just enough but you also want to make an actual website. Not that we wanna gate-keep terms here. The web community would never do that... But what I mean, is that maybe you want to add an imprint to your website, a contact page, a page dedicated to your work.

These multiple HTML documents will most likely share elements, such as the contents of your <head>, or visible Elements such as the Header or the Footer. It's rather easy to share your CSS or JS, because multiple documents can just point to the same file. But you can't extract parts of your document and point several documents to them. Well, at least not from the browser.

Turns out, this is a problem that we already know how to solve, with something called "Hypertext Preprocessing", in where the hypertext, which our Documents consists of, is getting processed before it actually turns into a fully fledged HTML document. What a great idea!

Hypertext Preprocessing... I've heard that before.

Well, that is kinda the reason d'être for PHP. Obviously PHP has since evolved, but the acronym still means "Hypertext Preprocessing" because that was its initial purpose. Most websites will not converge all of their content on one page, they'll have multiple HTML Documents and dedicate a shared collection of links to conveniently access those documents. We call them "Pages", because the correspond to pages, just like in a book or in a newspaper, in where we also don't have all content on one sheet of paper.

Of course you could style every document individually. But this has some drawbacks. Obviously visitors might not understand that one document is connected with the other one. Or they might not be reachable at all via links, because they are not shown. So naturally, you are gonna have some elements that are shared across those pages. But if a link changes, you are gonna have to change it everywhere. With the number of pages naturally increasing, this becomes quickly an insurmountable task. So naturally, the need to extract and repeat markup arose. And that was one of the many things, that PHP solved.

Dynamic Websites

When a HTML document gets built on the server, dynamically, based on certain requests sent to it, we speak of "dynamic websites". A term that is often thrown into conversations to mean a variety of things. But historically, and in the context of how websites are sent from the server to the client, this is what this term means.

But a webserver needs to support this! And we need (mostly) a programming language, that runs on the webserver. There are more programming languages that support this type of website making, not just PHP. And the numbers game still will present this way of website making as the dominant way. And there is nothing wrong with it! But there are drawbacks.

When to go static, and when not

from Chris Coyier at css-tricks.com

Servers & Programming

Making dynamic websites will need you to understand much more than just the writing of HTML. There is an entire realm of computing involved that will feel extremely foreign to you, if all your experience in programming is HTML & CSS. And yes, HTML & CSS are programming languages. I don't wanna hear any arguments against this. We have settled this debate.

The point is - this is an almost radical shift. But it was necessary, until not too long ago. But now we have more opportunities. Now instead of of rendering documents dynamically on the server, we are able to shift this work to the place where we are making our websites: our very own computers that we design and develop our websites on!

Enter SSG'ing

This is called "Static Site Generation". It's called that because we are generating our entire site as a static website. Static websites are the opposite of dynamic websites, in a way. Because the server will not take a request and build a document that then gets sent back to the client, instead it sends whole html documents to the client.

Tools that do this for us are called often just abbreviated as SSG, for "Static Site Generator" and there are many different ones out there. We won't dive into the history of SSG's. But let's just say that there is a great variety out there. And thus also many different approaches. They all usually help with certain things that we need when making websites, especially around reusing and recycling markup as well as creating markup based on some type of data.

Eleventy to bridge the gap

If you know HTML and CSS and maybe a bit of JavaScript, entering the world of SSG's is a wise move. It will empower you to make websites that are much more complex, without requiring you to adopt a mindset that is radically different. In fact, for the most part you might be able to do exactly what you have already been doing but you'll also be able opt into concepts that will carry over to more complex ways of making websites, without overwhelming you.

I believe that for this task, Eleventy is the right tool especially if you are entering this craft. It is very fast, easy to install and unopinionatedly opinionated, with the ability to become the backbone of more complex projects.

Good at... static site generation.

It feels odd to say this, but Eleventy is really good at static site generation. This deserves a specific mention because competing projects are not focused too much on. Projects like gatsby do much more than that and are much closer to a framework or a "developer experience". This comes at an expense that is either specifically monetary or in most cases it is opinionated abstraction. Meaning, that in order to provide a certain experience, it will take control over certain aspects of the development process without giving you much control over it, limiting your choice, for effectivity. This is obviously fine, but it requires you to be congruent with its opinions, or understand them in the first place. For someone entering the craft of website making, this is probably not the case.

Eleventy's opinion seems to be that it shouldn't have opinions on your DX. Instead it focuses primarily on the generation part. And it leaves you with much freedom!

Opt in to a HTML Templating language - or don't!

Eleventy will allow you to not just stay with HTML, but you can also decide to use and slowly learn to use HTML templating languages. One of the USP's of Eleventy is that it comes with many different languages that could be used alongside of each other. Nunjucks, Pug, Markdown, Liquid, Handlebars, Mustache, HAML, Pug, etc. And they can even be used simultaneously! At the very first official Eleventy Meetup (Of which I am one of the coorganizers!) Mike Aparicio highlighted this unique feature of Eleventy. Check it out here!

This is a crucial point, because this allows you to move at your own pace. You can use Eleventy to just extract and include your <head> or to make a navigation. That is up to you, at your own pace. And when you do that, there won't be one way that you will have to go in order to make it work nicely for you. That freedom is something valuable to retain when you are just starting to engage with the craft of making websites.

Many tools and SSG's out there nowadays cater not to individuals but to big organizations. This is fine of course but the challenges that an individual faces are not the same that a small team or a big corporation faces. Many current gen SSG's are mostly designed to make you productive. They do that by making working with it as frictionless as possible. As organizations trying to sell a product, this is an important factor to consider. But as an individual learning how to make websites, friction in learning is a good thing. The result is important, but will fade. The process is sustainable and will reap many results. The more productive the process, the better the sustainable outcome.

Not a JavaScript Framework

People starting to learn this craft nowadays are often redirected to learning not just JavaScript but go directly to a Framework that employs a very specific idea, the SPA. And there are good reasons for why that is happening. You'll be productive quickly. Setup is minimal, boilerplate code is reduced, economy exists (as in, supporting plugins and people working with it to engage with), etc. These are valid arguments when it comes to finding a job in this industry. But not all people learn to make websites just in order to get a job. The heavy focus on tools surrounding the SPA flavoured outcome easily obfuscate access to knowledge of the subject, in this case the fabric of websites: HTML, CSS and a bit of JavaScript.

I am arguing that this focus on outcome allows people to rarely engage with the edges of the technology, in short, to make less breaking changes. Yet it is so important to engage these edges and to make mistakes, because it allows people to build a more meaningful and complete relationship with it. This is not about deliberately frustrating people. In fact I am arguing that this way will actually decrease moments of frustration. Because Eleventy in essence is concerned with one important outcome, to generate a static website, mistakes that lead to actual failure will be much easier to solve. This is a very different experience for errors in SSG's that are providing a more complete Developer Experience, because even simple errors might trigger something in several layers. Debugging this might require deep understanding of these layers.

The creator of Eleventy on why Eleventy is not a JavaScript Framework

from Zach Leatherman at zachleat.com

You don't need a dedicated build tool

SSG's that extend into the SPA world might need you to run and understand a dedicated build tool such as Vite, Snowpack or Webpack. These tools are very complex because they are doing complex things. In order to make it still easy to use, they abstract away certain things. Which will force you into a way of working that might not be suited for you. There is nothing wrong with this in general - but it, again, will restrict your freedom.

In Eleventy, you can of course use these tools if you want to. But they are not coming with Eleventy, because it is not something that Eleventy does. If you decide to include it in your process, it will be on your own terms.

Benefiting from the industrialized Jamstack economy

Another Reason for why Eleventy is a great next step when coming from learning HTML & CSS and maybe a bit of JavaScript, is that it profits from the current state of the Jamstack economy. SSG's fit nicely into this mindset of the Jamstack (JavaScript, API's & Markup). Often an SSG is powering much of Jamstack sites so tool surrounding it where developed (undoubtedly to profit from it) and we can use these tools.

Previously, one of the reasons for why it might not have been a viable idea to work with an SSG is because it might be difficult to bring it from the local machine to the server in an automated way. Nowadays web-hosting services often will build your site for you on their infrastructure. In some cases like netlify, it will even do that for free up to a certain degree. In a sector where traditional web-hosting companies argument their pricing with services like php, mysql, etc., having very fast free web-hosting is a game changer for many.

Comparing several hosting options for eleventy projects

from Mike Street at mikestreety.co.uk

This is a relevant argument for Eleventy, because it is really fast. And whether or not you may require a paid tier of a web-hosting service like Netlify often will depend on how long your build is running, meaning how long it takes the generator to generate your site. Eleventy is really fast and is very likely to cost you less build minutes than another SSG.

Eleventy Sites on Netlify

from the netlify docs, docs.netlify.com

Conclusion & Getting Started

If Eleventy had existed when I was starting out, things would have been very different in terms of my professional career. I was dependent on someone being good at writing PHP - there was just no way around it. I learned it a bit, but it soon would have required me to go into databases, etc. This is a very different world, when all I wanted to do was make websites.

I believe that Eleventy specifically closes this gap that lies between just tinkering around with HTML, CSS & JS and launching full on projects. This is the right tool for you, if you are at this stage. Now, to get started - luckily, I am not the only person who is in love with this. So here is the perfect tutorial for getting started:

Converting a simple HTML site to use Eleventy

by Cassey Lottman at cassey.dev

But it doesn't end here. The community is vivid and there are tons of great entry points to Eleventy:

Stephanie Eckles shares in this wonderful tiny video, how to get started with eleventy in just 3 Minutes!
She also made a course on egghead.io that is entirely free!
Sia Karamalegos made the "Itsiest, Bitsiest Eleventy Tutorial", featuring the best header image that in the world.
Tatiana Mac has a multi-parted Beginner's Guide to Eleventy, in which she also introduces the economic landscape of SSG's & the Jamstack.
Now if you wanna get an in-depth understanding of many aspects of Eleventy, treat yourself to Andy Bell's "Learn Eleventy From Scratch".
Watch Ben Myers (Some Antics Web) teach Alex Trost (Frontend Horse) Eleventy in this vod of a live stream. This is great because questions are asked and answered!

Also, join the Eleventy Discord! The people there come to learn and help each other with eleventy. I promise, it is not stack overflow-esque! People join everyday and it has quickly turned into the focal point of the eleventy community.

Join the Eleventy Discord

we are really super nice!

Edited on the 30th Sept. to fix some typos

Using parameters in your eleventy includes with nunjucks macros

2021-08-10T00:00:00Z

Heads up: I know this is much longer than it needs to be. Sorry. It's just how I am with text. But you can easily navigate to the parts that interest you by using the outline - just click on the headline!

One of the reasons I ever felt the desire (and needed) to learn PHP was because I wanted to not repeat myself. I wanted to be able to use complex markup structures without having to copy & paste it, increasing the risk of making mistakes and most of all not being able to update the structure without significant expense. The current zeitgeist very much pulls us into handling all of this with javascript, because it is currently the only way to give us the feeling of working with encapsulated, self-contained pieces of code. Markup, Style and even a bit of self-contained functionality make up components that allow us to have a lego-like experience. What's not to love?

It's about DX.

But not everybody wants to (or is able to, for that matter) hand over all of the control needed to create this DX to JavaScript. To me, SSG's always brought much of the value to my table that I originally got from working with PHP (which is ironically also the purpose it was intended to serve originally, as the Hypertext Preprocessor). Now obviously PHP does much more than that and it exceeded its original intentions and capabilities by far - but needs of developers can vary greatly. I mainly just wanted to be able to reuse markup.

Why markup reusability is important

I believe most people reading this just wanna get to code examples - but bare with me, because I have a hot take on encapsulation and reusability. Many of the challenges that utility CSS approaches and to a certain degree even css-in-js solutions partly want to solve is a DX where you feel more in control over how the styling of your markup looks. As a CSS developer, this is not a challenge I face.

I very much follow the BIOS approach: BEM, ITCSS, OOCSS & SMACSS. I combine parts of all of these methodologies together because I believe they all go together really well. But what this does is create long and verbose classnames. This is not an issue that I face on the CSS part of things, or on the JS part of things for that matter (data-attributes ftw) but instead I need to tackle it on the Markup side.

An example

Look at this monster:

<li class="experience-timeline__events-item">
   <article class="experience-timeline__entry vers--major is-expanded" data-timeline-event="">
      <div class="experience-timeline__entry-type vers--job" aria-hidden="true">
         <svg height="28">
            <use xlink:href="#icon-event-type-job"></use>
         </svg>
      </div>
      <div class="experience-timeline__entry-text">
         <small class="experience-timeline__entry-meta">
         <time>2016 - 2021</time>
         </small>
         <h2 class="experience-timeline__entry-title">Sr. Frontend Dev. &amp; UI/UX Designer</h2>
         <small class="experience-timeline__entry-meta">
            <svg height="13" width="12" aria-hidden="true">
               <use xlink:href="#icon-organisation-marker"></use>
            </svg>
            easyname GmbH
         </small>
         <small class="experience-timeline__entry-meta">
            <svg height="13" width="12" aria-hidden="true">
               <use xlink:href="#icon-location-marker"></use>
            </svg>
            Vienna, Austria
         </small>
         <ul class="experience-timeline__entry-tags">
            <li class="tag">HTML</li>
            <li class="tag">(S)CSS</li>
            <li class="tag">Brand</li>
            <li class="tag">JavaScript</li>
            <li class="tag">Performance</li>
            <li class="tag">React</li>
         </ul>
         <div class="experience-timeline__entry-action"><button class="button" type="button" aria-expanded="true" aria-controls="timeline-event-2-details" data-timeline-event-expand-button="">
            <span class="button__text" data-timeline-event-expand-button-open="" style="display: none;">Show more</span>
            <span class="button__text" data-timeline-event-expand-button-close="" style="display: flex;">Show less</span>
            </button>
         </div>
         <div class="experience-timeline__entry-details" id="timeline-event-2-details" data-timeline-event-details="" style="height: 299px; opacity: 1;">
            <div data-height-wrapper="">
               <p>Working with the people at easyname was pivotal for me. I entered the company at a time where neither frontend development, nor design was considered an integral part. I was brought in also with the intention to improve on this. I had the great privilege of joining a diverse team handpicked by Stephanie Anderson. The team kept growing and kept being expanded by extraordinary individuals.</p>
               <p>I had the great privilege of joining a diverse team handpicked by Stephanie Anderson. The team kept growing and kept being expanded by extraordinary individuals.</p>
               <div class="main__heading-wrapper">
                  <h3 id="some-highlights">Some Highlights</h3>
                  <a class="main__heading-link" href="#some-highlights"><span aria-hidden="true">#</span><span class="sr-only">Section titled Some Highlights</span></a>
               </div>
               <ul class="list--horizontal">
                  <li class="list__item">
                     <span class="tag theme--dark vers--large">
                        <svg aria-hidden="true">
                           <use xlink:href="#icon-shine-marker"></use>
                        </svg>
                        Created VPS Product Landingage
                     </span>
                  </li>
                  <li class="list__item">
                     <span class="tag theme--dark vers--large">
                        <svg aria-hidden="true">
                           <use xlink:href="#icon-shine-marker"></use>
                        </svg>
                        Engineered the UX of new Products &amp; Features
                     </span>
                  </li>
               </ul>
            </div>
         </div>
      </div>
   </article>
</li>

There is a lot going on. This is not such an abnormal thing. It contains all sorts of stuff: Nested BEM components, state-classes and versioning-classes, Code intended for Screenreaders only, SVG and data--Attributes to allow interfacing with JavaScript. Things are getting pretty wild and complex. I cannot tell you without looking at the CSS what elements and modifier this block is accounting for. Making just the HTML readable enough so that it is easily reusable with some classes would negatively affect other parts of the DX.

I believe that markup is the most important driver in the need for encapsulation. Because CSS already is able to do it - if not with classes, then with Methodologies. That doesn't mean that we don't need scoped styles, we do. But I personally believe that the highest level of complexity ultimately comes from the markup and this is also where abstraction can serve as a valuable reducer of said complexity.

Now let's get to the actual stuff.

What are Nunjucks macros?

Why great question. Here's what the docs have to say:

macro allows you to define reusable chunks of content. It is similar to a function in a programming language.

Now I love nunjucks but I do feel like the docs are a big reason for why it hasn't risen to the popularity it could rise to. The example in the docs for macros looks like this:

{% macro field(name, value='', type='text') %}
<div class="field">
  <input type="{{ type }}" name="{{ name }}"
         value="{{ value | escape }}" />
</div>
{% endmacro %}
{{ field('user') }}
{{ field('pass', type='password') }}

Alright, this does give us parameters. But it looks kinda weird. That is because you also need to take a look at nunjucks import, if you wanna get the full experience. What does it say about imports?

import loads a different template and allows you to access its exported values. Macros and top-level assignments (done with set) are exported from templates, allowing you to access them in a different template.

What this means, is that we can extract and edit chunks of nunjucks code, markup in our case, in separate files and then import them wherever we want to use it!

Making a simple macro in eleventy

I have these tags everywhere on my page. But I designed them to be available in two sizes and in a dark variety. For this I proved my .tag class with two theme/state classes (however you'd like to think about it).

I often use prefixes to indicate what the additional class is doing to the class, so .ctx-- for marking a context and .vers-- to indicate that this is supposed to be a different version of the same thing, often implying that maybe even the markup structure is slightly different. And of course .theme-- to signal that this will just have a different visual variety but be the same in all other ways.

In the case of my tag, the two classes that I need to be able to add to the .tag are .theme--dark and .vers--large. In my _includes (depending on your configuration) I added a new file called tag.macro.njk. I personally like making sure somehow that I immediately understand that something is a macro, so I add this to the filename. But you could of course put them in a subfolder or go about it however you like, this is just how I like to do it. This is what the markup looks like:

<span class="tag">Tag</span>

Great. Now, let's turn this into a fully featured component that I can reuse however I want. First of all, I need to make sure that I can change the text here, the most basal usecase. In order to do this, need the macro tag from nunjucks:

Defining a macro

{%- macro tag(params) -%}
    <span class="tag">Tag</span>
{%- endmacro -%}

Note the safe syntax here. The little minus strips the leading and trailing whitespace. When working with eleventy and when mixing markdown and nunjucks, this is sometimes just needed to produce any output at all. I have run into some strange issues with stray </p> tags. But these issues can often be resolved with the minus.

As soon as we have this, we can import it anywhere we want and pass something to it, like this:

Importing and using a macro

{%- from 'tag.macro.njk' import tag %}
{{ tag({ text: "Banana" }) }}

Yes, imports are also relative to your configured includes folder in eleventy, which makes this extra super nice to use, even in extra-super-deep nested collection items.

Whatever you pass into the parameter is gonna be available inside the macro. I personally like this way of doing it but you can do it differently too. This just feels rather clean to me. Your content becomes available in your macro and you can use it like this:

using the passed content

{%- macro tag(params) -%}
    <span class="tag">{{ params.text }}</span>
{%- endmacro -%}

With this as our starting point, let's add all the other stuff there too. In my case, sometimes the tags need to be able to show an SVG icon (all of which I have included on the page and are available to be <use>'d.) and I also need to be able to set the classes I need. This is how my final macro looks like:

the final result

{%- macro tag(params) -%}
    <span class="tag {{ 'theme--dark' if params.dark }} {{ 'vers--large' if params.large }}">
        {%- if params.icon -%}
            <svg aria-hidden="true"><use xlink:href="#{{ params.icon }}" /></svg>
        {%- endif -%}
        {{ params.text }}
    </span>
{%- endmacro -%}

I can use the full power of nunjucks within macros, including ifs, loops, etc. Macros can do much more, for example you could encapsulate variable values and import them as well.

A different approach!

Stephanie Eckles uses a different approach with which you can achieve the same thing, by setting variables before the include. This is taken from her example:

{% set html %}
<div class="centering">
  <span>Feeling Centered</span>
</div>
{% endset %}
{% include "demo.njk" %}

This doesn't pass the html variable to the include, but because it was defined before, it is still available at the time when the code of the include gets evaluated, so working with it inside this code is still available. This is a fantastic approach - it depends on what you want!

This is a big deal.

The moment I realized that this was possible, I felt like a big block was finally lifted. A big reason for why, even as someone who just writes presentational, vanilla JavaScript, frameworks like React or Vue look appealing to me is the idea of the Encapsulated piece of Markup that can be abstracted and reused. Nunjucks macros in eleventy are giving me this experience. And there even are examples of libraries using this technique to provide their authors with encapsulated, reusable chunks of markups, like for example the gov.uk Design System¹.

A more complex, eleventy-ish example

On my work-experience page I list all sorts of entries. Every single entry is just a singular nujucks macro. In eleventy, I have set up each entry to be a collection item with no permalink. This allows me to edit them individually. Their contents eventually get passed to the macro that renders them accordingly. Here's how that code looks:

<ol class="wrap-as--full-column  experience-timeline">
    {%- for era, events in collections.orderedTimelineEvents | groupby('data.era') -%}
        <li class="experience-timeline__era">
            <time class="experience-timeline__date">{{ era }}</time>
                <ol class="experience-timeline__events">
                {%- for event in events -%}
                    <li class="experience-timeline__events-item">
                        {{ experienceTimelineEntry({
                            class: event.data.class,
                            id: event.data.order,
                            major: event.data.major,
                            type: event.data.type,
                            title: event.data.title,
                            organisation: event.data.organisation,
                            time: event.data.time,
                            location: event.data.location,
                            tags: event.data.eventTags,
                            details: event.templateContent | markdown
                        })}}
                    </li>
                {%- endfor -%}
            </ol>
        </li>
    {%- endfor -%}
</ol>

This feels great to look at lol. I am not sure why but this feels really satisfying to me. Some things noteworthy here is nunjucks groupby('data.era') which sorts my collection based on this front-matter value and the | markdown filter.

Be a bit cautious

If you are like me, then you are are in love with eleventy's capability to mix markdown with templating languages. This just makes all the difference to me. And with macros, even more complex situations are easily solvable. But there is a bit of a caveat - I believe because of the order of how the rendering is handled, nunjucks renders first and then markdown renders. This can make for some weird things, like your code being escaped because it treats it as four spaces code syntax. If that happens to you, you can disable it in your .eleventy.js:

const markdownConfigured = markdownIt({ html: true }).disable('code');
eleventyConfig.setLibrary('md', markdownConfigured);

This will fix that issue. But, I still encountered some other strange behaviour that I couldn't fully debug: Stray <p> and </p>'s. In the DOM inspector this looks just like additional paragraph tags, but looking into the source code reveals that there were actual stray paragraphs opening and closing tags flying around. At that time, I was using this complex nunjucks component in a .md file with templateEngineOverride: njk,md. I could fix it by turning the file into a .njk file and applied a | markdown filter to its contents. This might not work for all situations, but it worked in this one.

Conclusion

Write macros. Lol.

Minimal SASS & eleventy Setup

2021-06-21T00:00:00Z

I'm a big fan of sass and until native nesting is available to us I will keep using it. Now sass offers much more than just nesting. I also use it to manage media queries and settings. So naturally for this site I also wanted to use it.

CSS Nesting Module

fresh from the w3c's CSS Working Group

In this small little article I want to share how I set up my SASS compiling. Now this follows an established way of using CSS, which is via <link>. There are more options of course but here, everything will be setup to end up with actual CSS files.

Gulp is awesome.

Usually I go for something like Gulp to do this type of job for me. I am a big fan of Gulp and unless your development flow involves around JavaScript Files and you do need something, whatever it is done, Gulp is probably the right thing for you. But for this project, I wanted to find out how far I could go before I needed to expand my toolchain beyond what was already available to me with eleventy and npm.

I once opened an issue in the gulp repo on github and I phrased it horribly. I love gulp. Pls don't come for me, gulp people.

The SASS Compiler

Sass has come a very long way since it gained popularity. From my own subjective timeline I would deduct that it probably gained the majority of its popularity in 2013, but it got actually started in 2006 already. As a preprocessor, it compiles .sass/.scss files into CSS files. This means that we'll still write regular CSS, plus some additional awesomeness.

There are many compilers available nowadays, but it's recommended to use the Dart Compiler, as both the Ruby and the Node Compiler are deprecated. Here, we'll be using the dart-sass compiler as well.

I don't want to spend too much time on how to install sass and what watching/compiling exactly does. There is plenty of information on the sass website available.

Compiling your stylesheet

With the sass compiler installed, running commands in your terminal will allow you to compile your files into css files. For continuous work we'll probably want the files to recompile whenever you change them:

More about the Dart Sass CLI

sass-lang.com

sass --watch src/_scss/style.scss src/css/styles.css

This does exactly what you think it might. All the sass lives inside _sass and it will all go to css.

The prefixing of the sass folder with the _ underscore is for my personal sake only. That way I can easily identify folders that won't exist in the final output. Also, my input directory is src and my output directory is dist. Replace with your own settings accordingly, or set it to eleventy's defaults, if you haven't overwritten them in .eleventy.js.

Now with the compiled file we just need to make sure that we include it in the final output.

Include the compiled CSS with .addPassthroughCopy

The eleventy approach is very simple and gets the job done:

eleventyConfig.addPassthroughCopy('src/css');

Now eleventy will include this folder and its contents in its final output. Everytime something changes in this location, eleventy will rebuild.

But this can lead up to some undesired side-effects. You may see a message like: You saved while Eleventy was running, let's run again. (1 remain). So I opted for something else.

Include the compiled CSS manually

Instead of going for gulp immediately, I wondered if I could achieve what I wanted to achieve with npm scripts alone. So I made two scripts (is that the correct terminology?) in my package.json:

"scripts": {
    "sass:watch": "sass src/_scss:dist/css --watch --update --color",
    "sass:build": "sass src/_scss:dist/css --no-source-map --style=compressed"
}

The sass compiler now saves the compiled files directly into into the output folder (again, in my case that folder is dist - your might be site or whatever you have specified), plus some flags that are appropriate for watch and build tasks respectively.

Another article on how to use Sass with eleventy

jkc.codes

Tell browsersync to inject your changes

Before we get to the actual automation, which will tie everything together nicely, one thing needs to be said about your dev experience. If you keep it like this, any changes in your css/scss will not trigger a rebuild, when your site is running. You'd have to manually reload your page every time. But luckily Browsersync (which eleventy uses for this) options are easily accessible from within .eleventy.js.

eleventyConfig.setBrowserSyncConfig({
    files: './dist/css/**/*.css'
});

This tells Browsersync to watch for changes to be injected (or to cause a full reload) - great, this is exactly what we want. That way, browsersync will inject changes from your compiled css files.

Add some Automation

Now to tie it all together, we need some additional help. Here is how all my scripts (again, is that the real term? It feels wrong.) look like in my package.json:

"scripts": {
    "eleventy:serve": "eleventy --serve",
    "eleventy:build": "eleventy",
    "sass:watch": "sass src/_scss:dist/css --watch --update --color",
    "sass:build": "sass src/_scss:dist/css --no-source-map --style=compressed",
    "clean": "del dist",
    "start": "run-p -l clean sass:build sass:watch eleventy:serve",
    "build": "run-s -l eleventy:build sass:build"
}

Note that I have also added a clean task. For this I use the npm package del, which... deletes stuff 🥁.

I use the package npm-run-all all here, after some help I got from Sam Richard on the eleventy discord. You can run things sequentially (one after another) without it. For example, for the build, you could instead write npm run eleventy:build && npm run sass:build. But the repetition of the npm run felt so super counter-intuitive to me that I went for npm-run-all instead.

run-p will run your scripts in parallel, where as run-s will run them sequentially.

Now when I want to work on my site, I just run npm run start from the terminal and it all works as expected!

I am not an automation wizard. I got to this point with some help from people at the eleventy discord. But I thought that the final result and the lessons learned to get there were worth sharing.

Very simple Patterns with SVG

2021-06-20T00:00:00Z

On this website you can see these simple shape compositions everywhere. I do like using very simple graphical elements to create some form of... let's just say illustration. I rarely make things like these without encoding some form of meaning into its units.

In Figma, I created these little "diagrams" where these shape compositions are filled with some patterns. They would serve the purpose of visually communicating what types of tasks I was doing at a given employment on my work-experience timeline:

Early Attempts

I had some idea of implementation in my head when I was putting them together in Figma, but I didn't think it all the way through. I knew I just needed to somehow set background-images for individual elements. I soon came to realize that this was in fact not as easy as I thought it would be.

Firstly, Figma couldn't export them properly as svg. Or I did something wrong - in any case, exporting them did only work if I would export them in a non-svg format, like PNG. So for the time being, I kept them in PNG. But obviously that didn't look nice. Plus, the diagrams themselves featured a little caption. I knew that I didn't want to make a picture of text that would just as well live as real text, so I started looking for alternative ways.

the CSS property fill

css-tricks.com

I first followed the idea of setting the background with just CSS. There are some great pattern creators that use the versatility of gradients as background-images. But it's not possible to define a background-image in the fill property. It can only accept color-values but it can also accept links to <pattern>, with url(#id-of-the-pattern-element), as I found out from css-tricks.com.

Hello yes, this is pattern

I have tinkered with really small things in SVG, but it mostly involved masks or background-images set with CSS. So the <pattern> element was entirely new to me! In my opinion, it works rather intuitively.

MDN SVG Patterns Tutorial

developers.mozilla.com

<pattern> elements should go into <defs>, according to MDN. It does make sense, they are defined to be referred to. The element itself needs dimensions, set with width and height and an id so that it can be referenced with url(#) in fill. Now you can also intervene how the defined elements relate to its available geometry, with patternUnits and patternContentUnits (in other words, this will affect how the pattern fills its element, when being used). In my example, setting patternUnits="userSpaceOnUse" had exactly the effect that I wanted.

Example on patternUnits and patternContentUnits

Using an image file as SVG pattern

This is what I did first; I exported all of my patterns from Figma (which is a little story for itself) and set an <image href="" /> within my <pattern>. Here's an example of how that works:

See the Pen MWpRerQ by Thomas Michael Semmler (@thomassemmler) on CodePen.

This worked great! But, on helloyes.dev, users can change the accent color. And the patterns have the pink hardcoded into them. Now I could have exported the patterns with different accent colors from figma and then change the href's in the <pattern>'s, but that would have been quite a lot of work and it felt... wrong.

Another solution might have been to overlay the images with maybe a pseudo-element with the accent-color as background and then maybe work with a filter - but that felt even more wrong. So I decided to just try to recreate the patterns with regular SVG.

Using SVG shapes as SVG Pattern

This works exactly like you probably expect it to work: Instead of putting using <image> you just put any other SVG in there! Check out this example:

See the Pen ExWJyqz by Thomas Michael Semmler (@thomassemmler) on CodePen.

The pattern itself is a rectangle that is being tiled along wherever it is being used. By setting its dimensions you define a coordinate system on which you can relatively place your shapes. Now I can also use the custom property that contains the potential override as the fill with inline style. You can see more examples on this website. You can either just look into the sourcecode or look at it on github. If you change the color of this website, the patterns as used on the work page for example will change accordingly.

Here's one weird thing that might happen to you to - I am used to writing self-closing elements without a slash, as I'm used to in HTML5. But in SVG, <rect /> is the correct syntax, because XML (I am assuming!). I even posted a stack overflow lol, because I just couldn't think of what was going on here. But I eventually found out.

What about more complex patterns?

For the more complex patterns that, even if they don't look that complex would be rather difficult to hand-code (at least for me), I used figma. Especially when there are diagonal lines that go from corner to corner, a visual interface will be very handy. For this case I prepared my pattern in an artboard and then copied the SVG from Figma and then proceeded to take out everything that I didn't need.

Honestly, I was rather surprised how intuitive and easy this was. I love the result. I think its amazing that this is possible. I hope someone finds this helpful somehow. Also, all of this started with these patterns that I found on github (for figma). I made them available as a public figma library and you can play with it. Maybe I'll also make them available as SVG patterns on github, because maybe that'd help someone even more?

Is it too late to start blogging?

2021-06-09T00:00:00Z

I've read blogs, consumed podcasts and read articles on the web industry since 2010. Now I decided that I wanna take part in all of it.

Betterridge's Law

I don't think it is really too late. It took me rather long to get here, because I ultimately always thought that I had nothing of value to share. And as the community iterated and evolved, what was being shared was often not what I could relate to. I was concerned with other things - things that I decided were not interesting for the broader community.

Plus, and I am sure that I am not the only one observing this, as a person grows in their profession / in their craft, what they deem helpful and valuable changes in relation too. What was once useful to me has long since become part of me. In that way I forgot entirely, that not only is the industry specializing more and more but there are people entering to face challenges that I faced long ago. And I might be able to be of a little bit of help here. Plus, when I taught Beginner Courses in HTML & CSS at SAE Vienna I realized how powerful it can be to reintroduce yourself to the basal elements that make up the platform of your craft.

Blogging as a Portfolio

Now that I've talked a lot about the why, I'd also like to take some time to talk about what I had planned to put on here. I've only recently started tweeting rather frequently. It's all just opinions. But I mostly only put those out there as a marker. Often what I wanted to express is done in a few tweets but more than often it feels like I wasn't able to convey what I wanted to convey. This is where I do crave some long form writing.

In Addition to more fully formed opinions I also intend to use the blog as a documentation of code-patterns, as well as specific solutions to specific problems that I encounter while I work. I also do this for myself - I would like to be able to revisit the learnings and my thought processes. But it might also be helpful to other people!

When it comes to design, I truly to believe that the pixels don't matter, so I won't be making tutorials or dos & don'ts. Design is pretty much covered in my opinions part. In a way my writing is intended not to serve as a portfolio as well. I've come to understand that portfolios don't show much besides pretty images. As designers it is beyond trivial to make something pretty. These are not the challenges that we face and this is also not where we work. If a portfolio is intended to demonstrate how someone works then it cannot be a portfolio of pretty pictures. Instead I am gonna probably put on some case studies of previous projects - a Format where I hope to better be able to convey what actually goes on.

Me and the keyboard

When I was 12, I spent one entire summer just writing. Poems and short and long-form stories. My head was always filled with processes of world-building. German was always my favorite subject and writing essays was one of the few homeworks I actually did do. Nowadays when I am unleashed on a comment section, a chat or just a <textarea> I will go wild. No, not to misunderstand - I am not a keyboard hero, but rarely take the time to compress my thoughts, when it comes to text.

Future Features

Editing of text is definitely a weakness of mine. Some students shiver at the thought of structured writing of essays I love it. The blog goes live with barely anything out of the ordinary - dare I say it goes live without some features that you might expect. But developing all of what I want and what I have planned for the blog (or for helloyes.dev in general that is) would have required me probably a month (or more) of time to work on it. So in the spirit of small, sustainable steps I instead decided to get things out as they are done, instead of waiting for an ominous "everything is done"-feeling. The blog is intended to evolve and grow over time.

Some of the planned features are:

RSS-Feed
Web-Mention Integration
Varying Post-Types (comments, reposts, replies, etc.)
code-highlighting

Yay.

I'm excited! I am curious to see where all of this will go. If you find an issue, I would really appreciated it if you took the time to let me know. Thank you for reading!