Hacker Newsnew | past | comments | ask | show | jobs | submit | icedrift's commentslogin

And the mistakes AI makes don't carry the same code smells juniors make. There are markers in human code that signals how well they understood the problem, AI code more often looks correct at a glance even if it's horribly problematic.

Mainly because it isn't semantic and breaks accessibility features. If you find yourself writing layouts like this you're probably ignoring a bunch of useful stuff like <aside> <article> <menu> etc. Unless you manually configure it yourself, screen readers won't know what's important to read, tabindex won't know where to jump around, and form fields won't know what values to offer.


> isn't semantic

It's certainly better than calling everything a div.

> breaks accessibility features

I don't know if I'd call it breakage to just... not use them where they should be used. Of course if a real tag exists that adequately matches the author's intent, that should be preferred over a made-up one.


> I don't know if I'd call it breakage to just... not use them where they should be used.

Accessibility only has 2 states: "Working" and "Broken", there's no third "I didn't bother".


> It's certainly better than calling everything a div.

It's not. For semantic purposes <my-element> is the same as <div class=my-element>. So on the surface they are equivalent.

But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available so <my-aside> rather than <aside class=my-aside> so in practice it is probably worse even if theoretically identical.

Basically divs with classes provide no semantic information but create a good pattern for using semantic elements when they fit. Using custom elements provides no semantic information and makes using semantic elements look different and unusual.


> But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available

This article is written for web developers. I’m not sure who you think you are addressing with this comment.

In any case - the argument is a weak one. To the extent people make the mistake you allege they can make it with classed div and span tags as well and I’ve seen this in practice.


> But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available

You could say the same about divs. I’ve seen pages where everything is a div. No paragraphs, no headings, no tables, no lists, just divs.


I've seen <span class=italics>, and it made me want to break things.


That is a strawman. I never said everyone who uses classes perfectly uses semantic elements.

My point is that if you are using <div class=my-element> you don't have to change your .my-element CSS selector or JS selection code to improve your code to <p class=my-element>. If you are using <my-element> it is much more work to change your selectors and now you have two ways of doing things depending on if you are using a native semantic element or a div (either a tag selector or class selector). You have made your styling code depend on your element choice which makes it harder to change.


> For semantic purposes

But semantic purposes are not all possible purposes.


> > If you find yourself writing layouts like this you're probably ignoring a bunch of useful stuff like <aside> <article> <menu> etc.

> It's certainly better than calling everything a div.

Yes but it's worse than <aside> <article> <menu> etc. as the comment you are replying to mentions.


There's nothing dangerous about SSHing into an untrusted server unless you're using the same keys for everything.


Remote resources only get your public key. It’s meant to be shared! Hence the word “public.”

The threat is having a private key stolen, in which case, having multiple keys can mitigate the amount of damage a threat actor can do. However, to steal your private key would involve a successful attack against your client, not against any server you might have given the public key to.


There is also the threat of the server sending a data sequence that exploits a vulnerability in your terminal. It has happened before, but it’s rare.


Always encrypt your SSH private key! It shouldn’t be so easily stolen.


Super cool. I can't justify investing time in it at the planned pricing but I'll keep an eye on it if they can hack together a more competitive VPS option.


Speaking for my friends in their mid to late 20s, if you have a reasonable plan to get to a point where you can invest in your future as opposed to simply burning every last drop of income on mandatory expenses like food, housing and insurance I agree. When you can't foresee a way to get there you lack economic agency, economic nihilism is a rational response.


Per Atrioc


I've been got


If you come from immense privilege (growing up in an 8 figure household), have good health, and rich relationships and that isn't enough to curb your existentialism that's ok, but I find it hard to take this piece seriously as this is written like it's targeting the average financially stable worker. It strikes me as out of touch at best.


Oh boy another template shipped in a single commit; complete with "For now, do this" and "In production you would do this" comments


This was extracted from my production apps including (apflow.co).

I stripped out the business logic and keys, then pushed it as a clean starting point.

The "in production you would" comments are guides for where to add your own config.

Single commit because I didn't want my app's git history in an open source repo.


Thing is Kindle hardware is significantly better and cheaper. If you don't mind tinkering get a kindle and jailbreak it to remove ads and add koreader.


I've had both. Kobo is fine hardware-wise. And light years better on software than Kindle. One huge example: I have 1000+ books in Calibre. Took the time to tag them all into their respective categories. Kobo recognizes those tags and my book collection is sorted. With Kindle, I'd have to sort by hand on device. It ignores Calibre tags.

For this feature alone, I'd never go back to Kindle. Sure, I might be able to replicate it with jailbreaking + KOReader. But the Kobo worked this way out of the box.


How so? Just looking online, the prices between a Kindle and Clara BW is minimal (the Clara BW is actually cheaper). I don’t see how the hardware is better when they use the same exact screen…


> Kindle hardware is significantly better and cheaper. If you don't mind tinkering get a kindle and jailbreak it to remove ads and add koreader.

Because Amazon were increasingly locking-down their systems - and also because they are all-round shits - I decided to abandon the ecosystem having been a customer since the days they only sold books.

I have owned two Paperwhites, two Oasis devices, and a Kindle Scribe. I sold all of them last year and bought a Kobo Libra Colour.

I get WAY more joy from reading on the Kobo. I love buying books from the Kobo store (yes I know they also have DRM) - and I'm buying and reading WAY more on the Kobo than I was at the end of my time with Amazon.

Every time I buy yet another book on the Kobo Store I feel the thrill of sticking it to the horrible, anti-user shits at Amazon.


Try actually using a Kobo reader sometime.


Onyx violate GPL with their linux-based OS. I'd go Kobo or remarkable over them for that alone


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: