I'm surprised about the negativity in the comments. I'm happy someone is testing alternative approache. If they're wrong, they just wasted a bit of their own capital. If they are right - we might all benefit. You've got to treat technology as means to an end, not a religion that requires conformity.
People got so stuck on JS for decades that they've forgot that HyperText in HTML is there for a reason. It was always supposed to be more than just UI descriptor markup.
It is JS who is out of place in web. A little script in form of DHTML that grew into becoming a cancer that it is now.
And I feel a lot of Tailwind’s flak comes from people who never used it.
Having used inline styles in the past, there is no comparison to tailwind. Tailwind is a good and productive, though certainly not ideal tool. But it’s miles ahead of whatever else has been produced by css frameworks, in terms of productivity and maintainability.
Approximately no one outside of HN only wants text emails.
And the argument that anything beyond plain text is a waste and ruins everything applies to literally every single medium out there where the written word is conveyed: webpages, magazines, printed flyers, books, etc. It's laughable to think that all formatting of any kind beyond ASCII is a waste.
If it were up to HN readers, the entire world would be so ugly and boring.
I love how there are thousands of internet forums, but you're a heavy participant on a forum that is so militantly text-only that emoji are silently removed from user-submitted content. It's almost like the policy you are arguing against has important effects on conversation quality that you don't understand or that you don't want to admit because your paycheck depends on email messages' being rendered as HTML.
>Approximately no one outside of HN only wants text emails.
Approximately no one outside of HN even knows that plain text is a thing distinct from HTML. Among those that do, many probably couldn't give an example from their digital experience of a place where user-submitted content must be plain text. (They can navigate those places just fine, though.)
Given how long dang has been claiming that someday we won’t have pagination and everything will be fast, I’m guessing whatever arc garbage runs HN just couldn’t handle emoji 17 years ago or whatever and that’s what we are stuck with.
Basically, I don’t think it’s militantly text-only, it’s just shit.
It's good to be vigilant against hypocrisy, but there is such a thing as being too focused on possible hypocrisy.
What HN does, i.e., allow comments to contain a couple of carefully-chosen formatting options, is not a realistic option in email whereas because of a history of decades in which email clients could render only plain text, asking email senders to send plain text is a realistic option at least in some situations.
In other words, HN's designers were not restricted to a choice between plain text and full HTML, but in email we basically are (because there is no central authority in charge of email).
Agreed. If things look good then I enjoy looking at them more, and life is to be enjoyed. But more importantly, it's wrong that plain text is always the best way to communicate. A picture is worth a thousand words (often), and a good layout can make things easier to read.
It's more funny than that. Everyone wants text documents as well as rich documents as well as applications but no one wants a single file type to do all 3.
They totally do, but there is no single file type which supports all the formatting you might occasionally want, like math or floating text boxes or images, at least no format short of PDF.
And which is editable, quotable (important for email, even Gmail keeps messing up quoting parts of numbered lists), efficient, implementable, and not a security liability.
So we keep choosing formats that support the subset of features that our current problem needs.
Email multipart messages containing a "safe" subset of HTML has solved some problems adequately, and when it doesn't always work, we include a link to a web page, so you can show it in a real browser, or we attach or embed a PDF.
It gets quite hilarious when we take the design goals, technological difficulties both foreseen and experienced, insights picked up, compare the "end" results with the goals and then compare the excuses with what should have been possible technically.
As we cant blame anyone specific, I would have to conclude we did everything wrong and had very poor excuses for it.
A complete embarrassment. I find it rather entertaining but offer no solution.
Why doesn't HN or reddit or most social media format messages in html like email? Email has been doing it for years. People would love it! Images, colors, tables, etc in every message!
If only it was a simple logo. My HRs send emails with a full blown wallpaper on top, which stretches the inbox on a smaller screen so much that horizontal scroll appears, and text below it also overflows. Or when I disabple dynamic content, then they manage to create links inside the graphical buttons with no alt text, invisible without the picture. And these are people whose main job are emails. Sigh...
Meaning the 'plain' text is Html-formatted to look plain and there are tracker links and probably tracking pixels too.
Real plain text should be just like something a human being typed.
Also, ignoring the general scamminess of hubspot, the linked article says html mail is MORE likely to be flagged as commercial. The article, in fact, is entirely pro plain text.
I just checked, and they don't. It's certainly plain looking and without fancy styling/formatting, but they do send content-type text/html. The links and tracking pixel images are why they need HTML, I guess.
There's an account setting somewhere to always send plain text emails and do not send HTML. I don't know where the setting is, I enabled it many years ago. Been happy with that.
Did you actually scroll through all the way? Some emails send both plain text and HTML. I looked through mine and indeed saw text/html for most Amazon emails (including AWS). Some AWS emails like ACM cert renewals were text/plain. Though like someone else said here, you may have changed a setting in your account preferences. The default is still HTML.
They aren’t talking about HTML attachments. HTML email is typically sent as a multipart/alternative email with one text/plain component and one text/html component. An email with attachments is a multipart/mixed email.
Tracking pixel in an email? I thought nobody had done that in decades because major webmail clients pre-cache all images to prevent leaking user IP etc.
The clients also need to focus on this. Apple Mail on iOS uses plain text variant to show snippets, but if you try to expand the email, it only supports HTML, without a fallback to plain text. This is often the case on slow internet.
The post you're responding to probably meant in the event of alternative HTML+text emails. Obviously if the email is plain text-only it won't invent HTML to show the user...
It doesn't matter if we get rid of The Agile. If you make The Agile go away, there will be something else, equally horrible.
The internal incentives in hierarchical organizations is to balloon the management, which suffocates the bottom of the pyramid. That's just how the world works, for most people, not just SWE. The Agile is horrible because corporate management makes everything horrible.
If you don't like it work in a small, carefully selected startup, or make your own company. Otherwise just accept that you're just a corporate drone and you have to endure the shitty corporate system to pay your bills. At least you get paid decently, because there's not that many people to replace you like in other professions.
I disagree. Merge conflicts are just a fact of life, and line-granularity has good usability properties (displaying and editing). `git` has issues, but I don't see merge conflict granularity being an issue, especially when project enforce consistent&automatic formatting.
I agree however that while Pijul is technically very interesting, it doesn't seem to have any killer features that would overcome the cost of switching to a niche version control.
I was reviewing a PR today and have to disagree with you. There was a single value change in a jsonl test data file. This is nightmarish to read in regular git diffs, as the change gif thought was happening was (with text wrapping) an full page worth of json rather than identifying it was a single word change. And because it is jsonl, the file could not be split into different lines without altering it’s semantics.
I don’t think it’s unreasonable we could be a little smarter here.
JSONL and line-oriented version control are never going to play nicely together.
Imagine doing code review in a language where every function had to be written on one line!
The two techniques I use to dodge this:
1/ Switch from JSONL to a list of objects then pretty print it to be line oriented.
2/ Compress the test data to discourage viewing it altogether, and make people describe what’s being changed rather than leaving it up to the diff to show it.
I can believe that they can come with that... but `man diff` doesn't mention it at all, I can't find any description of the diff/patch format that mentions it, and I've literally never seen it. I do frequently get multi-megabyte single-line diffs though, which amount to just one or two characters changing.
Other tools exist, of course, but if you're going to be shipping around stuff that `git apply` or thousands of other tools can handle, it has to be in "the" standard format.
This is an area where it should be easier to build tools for that. I have tools for diffing k/v and structured formats but they are local on my machine. Being able to publish those to Gitlab, github and bitbucket would be great.
Edit: Worst is diffing yaml files, you really need a stable way to parse those.
To contrast tech workers against working class, and redirect resentment. It's not billionaires that turned the system against working class. It's the nerds at Google that make six figures, duh.
