[kasey_junk]

HN is perhaps the most user friendly site I go to with regularity.

The idea that a website needs to be “rich” to be usable is one of the dumbest things the industry has convinced itself of in the last 20 years (following only ‘yaml is a smart way to encode infrastructure’).

[ASalazarMX]

To be fair, it's not as much user-friendly as it is simple, and simple tends to be easier to understand.

For example, if it was more user-friendly, it could have links to jump between root comments, because right now very popular top comments tend to accumulate most interactions, and scrolling down several pages to find the next root thread requires effort.

[howenterprisey]

Is that not what the "prev"/"next" links do?

[Terretta]

User on this account since 2010, 12K karma, and I just learned what next does.

TY!

[ASalazarMX]

Duck me sideways, they were always there, but I was blind.

[smitty1e]

Compulsive over-engineering is by no means an IT-centric problem.

It takes substantial wisdom to arrive at an 80% solution and cease fannying about.

[xyproto]

And the people that brings this wisdom also brings few or no metrics that are appreciated by management.

[fisf]

The people who push the other direction also bring few or no metrics. I.e. there is often no reason to add <bag of features>, except a customer (who didn't buy the product yet) mentioned them as nice to have during initial sales talks.

[laputan_machine]

I prefer YAML to JSON for our infra. I know some people do not like the whitespace.

What do you prefer?

[ElectricalUnion]

JSON:

* doesn't encode Norway to false;

* most formatters for JSON are deterministic.

* doesn't deserialize into arbitrary objects;

YAML, in in constrast...

* YAML is insecure by default and will deserialize into arbitrary objects;

* YAML knows that there's no such thing as wall clock time, there's only number of seconds since midnight;

* YAML has 22 ways of writing true or false, and the parser will silently replace your "strings" with false.

* There are 63 ways of writing multi-line strings;

* A truncated YAML file is still a "valid" YAML file.

https://noyaml.com/

[hombre_fatal]

IMO the solution to YAML-as-config is a strict subset of YAML.

JSON is one strict subset, but one that makes smart trade-offs for strictness and machines like error detection and syntax-typed types.

We decided on a different subset of YAML for our users that were modifying config by hand (even more strict than StrictYAML). Some of the biggest features of YAML are that there is no syntax typing, and collection syntax is simple (e.g. also true for JSON, false for TOML).

For example, a string and a number look the same. This seems bad to us developers at first, but the user doesn't have to waste 20 min chasing down an unmatched quote when modifying config in a <textarea>. Beyond that, it's the same amount of work as making sure the JSON is `"age": 20` instead of `"age": "20"`, one just has noisier syntax.

I think the StrictYAML docs have a great breakdown of the advantages: https://hitchdev.com/strictyaml/why-not/

We decided against TOML because nesting is too confusing. https://github.com/toml-lang/toml/issues/846

[withinboredom]

Declarative code. CSS is better than YAML for describing a desired state.

[jjeaff]

Not on mobile.

[manojlds]

Thanks for the downvotes everyone, else wouldn't have even known there were so many replies to my comment.