How many of those languages are declarative, or domain specific?
There's no use comparing CSS and assembly. It betrays a shallow understanding of CSS. Points to ponder:
- Assembly is superlatively imperative while CSS is the opposite. The difference can be jarring for some. It's commonly felt in day-to-day frontend work that switching to CSS (declarative) from almost anything else (imperative) -- JavaScript, PHP, etc. -- requires a significant mental shift, though it does get easier with experience.
- Lot of the vocabulary and concepts used in CSS come from outside the computing world, namely design and publishing. It's somehow a rarely shared factoid, but it's a hint at how too far away from Kansas we are to be making fair comparisons.
- A pervasive mistake that coders make (and unfortunately a lot of CSS teaching material out there too) is to approach CSS as a set of explicit, atomic instructions -- a fair coder-y assumption, but a bad mental model that leads to frustration. Understand that these instructions can affect one another; some switch entire layout algorithms[0] in a given scope, changing how other instructions behave (predictably).
I am pretty comfortable with CSS, enough to find tailwind useless. I've done front-end work exclusively too (not anymore). Just because one has the skill doesn't mean they can't acknowledge the stupidity of it. People bash CRUD code not because they can't write it, it's just boring and sometimes wrong too (crud API, don't get me started on that)
Alright, if you say so. But what stupidity do you mean? What do you mean offload it to figma etc? Why is it dumb to write code for... the job CSS is built for?
design should be visual, you should not have to write code for it.
Even if you write code for it, you should be able to write code in a way that express your high level thinking, something similar to constrain layout in mobile dev. CSS has 4 levels of overlapping features so far and every new layout model comes out are slightly better but still a little bit off. The newer features like variables have bolted-on syntax that looks like garbage, nobody understand CSS grammar anyway (does it even have one?)
Given how convoluted CSS is despite how little it has to do, I consider it a poorly designed programming language, if you can call it that.
So how do you deliver design on the web, if not without code?
Remember that designing for the web is not like designing for print, where the dimensions of your canvas, and the amount and nature of your content, are known quantities. A web page is expected to accommodate every possible device, agent and viewport -- watches, phones, tablets, laptops, desktops, TVs, screen readers, ebook readers, etc. * portrait and landscape orientations * browser window sizes -- and content that can change by the minute and whose size is unknown until all of it has arrived on the device.
Think about all these conditionals and variables, and how much instruction you need to provide, efficiently, for making it all look as good as possible, to the browser/agent. Doesn't all this seem like the necessary purview of a domain-specific programming language?
>Why is this so weirdly prescriptive about inline event handlers?
>> Even in a single file, inline event handlers are not a good idea. One button is OK, but what if you had 100 buttons? You'd have to add 100 attributes to the file; it would quickly turn into a maintenance nightmare.
What's so weird about this? This practice, known as event delegation, has been a known Good Practice for decades. One event listener attached to a common ancestor element of 100 buttons is more memory efficient than 100 event listeners. Even jQuery, which makes it temptingly ergonomic to give 100 buttons an event listener each, prescribes the event delegation pattern in their documentation.
Edit: Sorry I just read the section; now I'm dismayed the MDN article is not prescribing/recommending event delegation. However I did find other MDN articles explaining it:
If this is about staging partial file changes, then I think this is where git GUIs especially excel. It's typically a matter of selecting and deselecting individual lines of change. The concept and term "hunk" (to mean a group of lines, and honestly "chunk" would've been a better choice) never shows up. Pretty intuitive and foolproof.
I've used Git Cola on Linux and Github Desktop on Windows. Both free.
For the TUI inclined, lazygit [1] and magit (emacs) [2] both have quick and intuitive ways of handling this. They're also both wonderful companions to the git cli for day to day version control.
You can reopen the window you're missing with ctrl+shift+n, the same way you open a formerly closed tab (only that's not n, that's t). I do agree it's irritating this isn't made more plain.
Just adding this here: I created a multi-window management addon Winger[0] which lets you treat windows as 'tab groups', and it has a stashing feature (windows <-> bookmark folders / tabs <-> bookmarks) similar to Tab Stash. Despite the ostensible scope overlap, I know there's at least one person (not me) who uses both, setting Winger's stash home folder to be the same as Tab Stash's to achieve a manner of integration.
>You aren't "programming the presentation logic", you're configuring the browser.
Under-appreciation of frontend skills in action. Do you think of "presentation logic" as an oxymoron?
I think many people can't see HTML, CSS and even SQL of backend land as programming languages, because they don't think declarative Domain Specific Languages (DSLs) count, don't think of their specificity and limitations as design strengths, and because each one is super easy learn to start but the rest of the enormous iceberg is so often ignored.
No, I don't. I consider presentation logic to be the browser code parsing those configurations. Many people "can't see" HTML, CSS, or SQL as programming languages because they aren't programming languages. When you write markup, database queries, and styles you are factually not programming. This is fine, it does not devalue those skills in any way.
That being said, to my knowledge front-end developers generally are JavaScript programmers. I consider front-end developers to be programmers.
There's no use comparing CSS and assembly. It betrays a shallow understanding of CSS. Points to ponder:
- Assembly is superlatively imperative while CSS is the opposite. The difference can be jarring for some. It's commonly felt in day-to-day frontend work that switching to CSS (declarative) from almost anything else (imperative) -- JavaScript, PHP, etc. -- requires a significant mental shift, though it does get easier with experience.
- Lot of the vocabulary and concepts used in CSS come from outside the computing world, namely design and publishing. It's somehow a rarely shared factoid, but it's a hint at how too far away from Kansas we are to be making fair comparisons.
- A pervasive mistake that coders make (and unfortunately a lot of CSS teaching material out there too) is to approach CSS as a set of explicit, atomic instructions -- a fair coder-y assumption, but a bad mental model that leads to frustration. Understand that these instructions can affect one another; some switch entire layout algorithms[0] in a given scope, changing how other instructions behave (predictably).
[0] https://www.joshwcomeau.com/css/understanding-layout-algorit...