I made https://poemd.dev/ as an online markdown scratchpad that supports GitHub Flavoured Markdown and stores all data in the URL. This means there are no accounts to work with and everything is basically stored in bookmarks if you choose to.
The persistence model makes documents somewhat sharable, but I do find Open Graph previews to be mixed. In Messenger it renders the whole URL, which is quite long due to encoding, and that kills the conversation view.
Having worked in ecommerce on both merchant and SaaS side I can explain why they may have and as a customer you will basically never see it applied.
From an engineering point of view, yes you can save so much packaging for the company and optimise for a delivery to be in fewer boxes, which is a fun problem to solve.
From a retail operations point of view the cost of packaging and shipping is negligible and why it’s so often discounted. The real costs though are labour.
Your pick and packing staff are basically all judged on throughput so if someone spends 5 minutes to pack an order in 1 well fitting box they will be fired if everyone else can pack 5 orders in the same 5 minutes.
Generally speaking your packer station is set up so they either have a terminal showing their packing list, a tub of goods to pack for one or more orders, and stacks of different sized boxes.
The stations usually get messy quickly with papers etc all over the place. It’s not a place for precise work and speed is valued above all. In describing the work station I didn’t even mention scanning, taping and labelling of the package that has to happen in the same space too.
Some may argue it’s possible to be both fast and precise, but I would argue it’s not sustainable over an 8 hour shift.
Finally, similar to why potato crisps/chips have so much volume is that inefficient, or spacious, packing is generally better for transport as you are less likely to have goods damage each other from being too tightly packed together.
That’s why IMO generally things are packed sub-optimally from a space use perspective but actually optimally from a convenience and speed perspective.
Part of the problem is discoverability. As the library gets larger, without adequate time invested into docs or standardised naming to enable faster code-based search, people can end up writing their own functions when one already exist. Often these are not discovered unless PRs are reviewed by someone that either wrote or has experience with a reusable function.
I think the topic of having/not-having children should be treated like politics and religion in polite conversation, to be avoided.
Unfortunately there is quite the philosophical, ideological, and even dogmatic schism between the two sides.
Like another post I read, if you do have to enter a debate about it, it's probably a more useful exercise to ask each other what it would take for their stance to change.
In researching for this reply I see that it's joining a somewhat crowded field https://en.wikipedia.org/wiki/Comparison_of_document_markup_...