Why do front end developers like to write their HTML/Component markup like this:

<div
id="test"
class="test"
>
Test
</div>

That lone > bracket absolutely irks me! Looks ugly! I prefer the Android style:

<div
id="test"
class="test">

<span>Test</span>
</div>

👌clean

This is one of my complaints about xml based anything:
It‘s practically impossible to make it look nice.
No matter which style you use, it‘s always an ugly mess.

And not all frontend devs have to deal with this crap. I certainly don‘t have to, anymore.

Easier to switch lines that way

Probably because it's easier to add new attribute later.

@daniel-wu I mean, I can see that, but that doesn't do anything for me, it's just saving a few keystrokes. I can live with that

As much as that lone bracket irks you, having an unclosed indent is like torture for me

I couldn’t give a shit

@phat-lasagna same, as long as it comes out as valid html, you always can run a formatter over the stuff with whatever you like

Oh my formatter does that automatically. Do you have any recommendations for settings against that? (I’m VSCode)

<div

class="a trillion classes"

aria-attribute-1="..."

aria-attribute-57="..."

data-attribute-1="..."

data-irrelevant="..."

>closing bracket with text immediately after</div>

-

It irks me when the HTML thinks there's a bajillion leading spaces in a text node because I tried to make the the markup more readable in my editor.

@eo2875 not really, i just use whatever's default on vscode 😅

The whitespace in the inside of an element with just text is dangerous tho'.

@eo2875 Hello, VSCode. I'm Eclipse.

@MadOgre You won't like Python then.

Okay now put a single element inside the multiline one, and realize why the closing angle is on its own line.

@c3r38r170 I work with it every day among others and I want to fire it into the sun

@lorentz That's why I have that empty line between the last attribute plus closing tag and the single element. I've seen this in some Android code bases and I thought that was a good practice

@OzzyTheGiant Hmm, I think a blank line with no significance wrt. logical grouping is more jarring than a line with just a ">", but I could work with this.

@lorentz Some other reasoning behind this is for scoping out elements quickly while scrolling. Best practice usually dictates that components should be kept small, but most people don't do that, nor practice separation of concerns (all those callbacks inside the html 😒), so if I'm scrolling through a really long component, it's nice if elements are separated by lines.

Ah I will tell you! As someone obsessed with syntax HEAR ME OUT!

The goals:
1. Ease of readability (my eye at least focuses easier to blocked segments of code)
2. Minimize git commit line changes easier to identify and make diffs.
3. Ease of element edit when adding removing attributes.
4. Easier multi line edit with multiple cursors.

Well these are the first that come to mind, but to me it’s not about preference or beauty but it’s about how practical it is.

I have a counter complaint, buddy.

@KALALEX @KALALEX as a newbie I spent a large amount of time on best practices as a front-end dev, so I’m enjoying this conversation. Thanks.

Do you write your code blocks like this:
if (condition) {
statement }

or like this:
if (condition) {
statement
}
Basically what @Kernel said.

@hack my gripe is only with <> characters. If it was braces or brackets that would be far better in my opinion, as those characters are bigger and stand out more.

Besides, in the Python world, devs don't even use any form of enclosures and the readability is far better than other languages, to my surprise. I think Python's formatting standards would benefit other types of code. Which is why I now try to use larger indentation, more empty spaces where it makes sense and where lines are really short, I try to condense them to one line, for example:

If (is true) return "something"

No braces, but two empty lines with that line in between

@hack the second opinion…

@OzzyTheGiant Python can't have multi-line lambdas because of its debilitating lack of delimiters.

@vintprox I should have started from 0 you are correct, sorry 😢

@KALALEX my comment wasn't directed to you, but OP.