It’s a subjective question, but in one of the zero-installs projects I definitely remember that when I added a couple of particular GUI libraries there suddenly a very, very long list of new files to track, since those maintainers to keep things decoupled. I wouldn’t stop using that library at that point (there were deadlines), but I would definitely try to find something lighter or more batteries-included next time.
There can be a tiny project with just one dependency that happens to have an overgrown, massive graph of further transitive dependencies (a very unpleasant scenario which I would recommend to avoid).
With zero installs turned on, such a codebase could indeed qualify as “big repo”, which I think would reflect well its true nature.
Without zero installs it could be tiny but with a long long lockfile that nobody really checks when committing changes.
> Personally I store vendored dependencies in a submodule
I don’t like the added mental overhead of submodules, and so prefer to avoid them when possible, which I guess is a subjective preference.
Since this is, coneptually speaking, the matter of package management more so than it is the matter of version control in genetal, I prefer to rely on package manager layer to handle this. I can see how your approach could make sense, but honestly I would be more anxious about forgetting something when keeping vendored dependencies up-to-date in that scenario.
Your approach could be better in a sense that you can spot-check not just the list of changed packages, but also the actual code (since you presumably vendor them as is, while Yarn checks in compressed .tgz files). Not sure whether that justifies the added friction.
Scala could be one example? When I upgraded to a newer version of the standard library (the Scala 2.13 or Scala 3 collections library), there was a tool, Scalafix [1], that could update my source code to work with the new library. Don't think it was perfect (don't remember), but helpful.
Then you might find Talkyard interesting: https://blog-comments.talkyard.io — reminds of Disqus, in that it's threaded, best first (optionally). (I'm developing it.)
> showing some CORS error
In my case, I found it annoying when cookies gradually stopped working, and eventually I had to make the software use custom HTTP headers instead of cookies.
> Seems that mostly spammers comment
The more interesting the contents of the blog is, the more real humans will like it and post comments? (if they can find it)
But a "Our company posts something each day, even if nothing has happened" blog, or AI fluff, attracts only spammers?
Could one say that humans are trained very differently from AIs?
If we (humans) make confident guesses, but are wrong — then, others will look at us disappointedly, thinking "oh s/he doesn't know what s/he is talking about, I'm going to trust them a bit less hereafter". And we'll tend to feel shame and want to withdraw.
That's a pretty strong punishment, for being confidently wrong? Not that odd, then, that humans say "I'm not sure" more often than AIs?
> I like the distinction between liking and disagreeing
Me too :- ) I'm thinking that if something gets 10 upvotes, and sth else get 10 upvotes and 10 disagree votes, then more often it's the latter that's more interesting to read?
There's also an Unwanted vote, for things that are too off-topic or rude etc, similar to how downvotes work here at HN.
Slashdot's vote system I like too :- ) (Maybe the vote system could be pluggable in the distant future.) — There's also half implemented Do-It votes and Do-Not votes, for ideas and upcoming Joint Decision topic types.
> commets ... and the links under "Old plans" return 404
Oh, thanks! Hadn't noticed. They work from here: www.talkyard.io/pricing (the www subdomain), but from the blog-comments and education subdomains, all those "Old plans" links are broken. (So I'll need to point the links to the www subdomain.)
> I would suggest a general revision of the copy on this page,
The pricing page? If you want & have time to write a bit more, that'd be interesting.
(Or if you're too short of time, I guess I can ask someone who works with UX & pricing)
> and removing all the "later" features.
Hmm, someone else has mentioned this too. Maybe there can be a "Show-later" checkbox, default un-ticked.
> The pricing page? If you want & have time to write a bit more, that'd be interesting.
I suppose my main criticism was about the "later" features. It comes off as dishonest to mention features that may be implemented at some point in the future on a page meant to inform potential customers about what they would be paying for _today_. So I would suggest to only promote fully-working features, and leave future features for a roadmap page linked elsewhere.
Other than that I would say that there are a lot of asterisks and clarifications that might confuse users. The page looks overloaded with information that is not well structured IMO. It's also mentioned that a credit card is not needed for the trial, but then you will email users about how to pay. Maybe this should be clarified on this page? And there are minor visual details like inconsistent font sizes, font weights, and parenthesis usage (e.g. why is "Idle blogs" between bold parenthesis?).
It seems that you're not a native English speaker, and that's fine (neither am I), but I would suggest hiring someone who is, and has experience in writing technical documentation to revise your entire site, so that it can have a more professional appearance. These days LLMs can also be helpful with this, as long as you set their tone and review their output.
> It comes off as dishonest to mention features that may be implemented at some point in the future
Thanks, good to know. (Will fix)
> a lot of asterisks and clarifications that might confuse users
Yes! People email and ask about the pricing more often than I thought.
> It's also mentioned that a credit card is not needed for the trial, but then you will email users about how to pay. Maybe this should be clarified on this page?
Hmm. Yes, there could be something about "if you want to continue after the free trial".
> It seems that you're not a native English speaker
That's right
> but I would suggest hiring someone who is, and has experience in writing technical documentation to revise your entire site, so that it can have a more professional appearance. These days LLMs can also be helpful with this
Ok :- ) First, all the LLMs, then a human I guess.
Thanks for all the ideas. Sorry for the late (8 days) reply.
Just started reading The E-Myth Revisited, hopefully that, plus the sleepiness problem being mostly gone, can put things in better order.
> Though I would suggest a general revision of the copy on this page, and removing all the "later" features.
Now done — all "Later: ..." features are gone, and I did a general revision of the copy on the pricing pages, based on what you wrote, and based on Gemini's and ChatGPT's feedback (when I copy-pasted the HTML into the AI chats — they had many pages feedback).
> These days LLMs can also be helpful with this
They were amazingly helpful. Thanks for suggesting! I'll ask them to review the whole website, like you suggested, some time later too.
And no amount of good doctors can make you change your lifestyle. At the end of the day, a ton of doctor advise is ways to change your lifestyle, and that takes personal effort.
They aren't going to care about any of the advice in the article about not posting slop -- finding a job is (of course?) more important to them.
Can't really say they are doing anything wrong, maybe I too would have? ... Just that large scale, doesn't work
reply