Before adding the newest fad features, maybe the should go back and add old fads that they missed.
One big fad from 50+ years ago that I'd welcome is folders. I don't want to just have all my repositories appear in a flat list ordered by time since last update. I want to make folders so I can organize repositories by topic--just like I have my repositories organized in my computer.
We started out not knowing what anything should look like, we didn't even know what computers were suppose to do. Everything had to be envisioned and implemented. Different approaches were taken for a lot of things. Eventually we just know how something should work. At that point it can be abstracted away.
Similarly lots of things should stay in JS. If we've experimented and evolved to the point where we know how something should work we should grow beyond modules and have build in methods for it.
It is happening but much to slow in my opinion.
Say, we have a Date API, are week numbers a thing or not? Are they an unpredictable poorly understood thing? Does it bother anyone if the API supports it?
Everything should be able to migrate up and down from the metal to the highest level of abstraction depending on how much we use it.
edit: There is no point shipping [table] sort magic to the client on every page view that needs it.
It seems like you're simultaneously saying "sorting doesn't belong as a language function in JavaScript" and "we shouldn't ship a sorting routine to the client," which seems...odd. If the page view needs sorting, then isn't that the use case where we can most say that there is, in fact, a point to "shipping sort magic to the client"?
(Also, you can do an HTML table sort in about 10 pretty short lines of code[1], so this seems like a kind of weird hill to die on.)
JS should have an array sort function. HTML should have sort-able tables. We know what they look like. We shouldn't have to pump up our pages with a bazillion lines of js just to implement something entirely obvious.
IOW: If there is a table it doesn't hurt to be able to sort it by default.
The example is great! 10 lines... no wait... 30 lines... then you have something that... or no wait, it sorts numbers alphabetically. The cursor is wrong. There is no accessibility. The little arrows are missing ▲ ▼ did I pick the right ones? They look bulky, better add another span inside the th? Oh I clicked the th twice now the text is highlighted.
Why should I need to implement this myself? I'm not inventing anything new? I don't want to be dealing with colspan but we all know how it should work? I know its wrong but I usually leave out the <thead>, tables render just fine without it but when something generates tables like that the script needs to be re-examined to figure out why it doesn't work. There is some unknown number of other ways to break it.
A default implementation could deal with some common units out of the box. Monday could go in front of Tuesday, 50 cm could be smaller than 1 m, $100 could be bigger than $20. Just the simple obvious stuff. For everything else something like <th sort="foo"> with: foo = (a,b) => a.length - b.length
List items are a bit less obvious but I'm sure we can think of something sensible. Perhaps sorting by child class?
Not wanting to start a discussion about graphs vs trees for organizing, but in my opinion simple folders are great to fulfill basic needs. I cannot imagine a book having no table of contents and just a list of tags with numbers indicating relevant page numbers.
That is just dumbing yourself down in favor of machine classification or search algorithms while a simple solution exists for this problem for higher order classification and context, which tags alone fail to provide, even with sorting.
I think it depends on your goal. If I want to browse new chicken recipes, I am going to open the table of contents, find the section on poultry and start flipping through recipes. On the other hand, if I want to cook a chicken curry, I am going to go to the index and look up curry, then find the relevant page.
Folders are great for when you don't know what you want and just want to browse or explore based on broad topics. Tags/indexes are better when you know basically what you want, and you just need a way to find it or items similar to it.
Al entry should go in a single category, chapter or folder. The index should provide a useful overview. Tags you may have in any amount. More is usually better.
A tag with a single entry is useful. Chapters should never have a single entry.
With limited entries of text or code you can just have them all on one page. Slightly more requires a folder or category system. If you have even more you need tags you should also keep the categories (everything must sit in a single category), If you have even more you need categories, tags and search. Trying to use one of those for the wrong volume just creates clutter.
This so much. Another pet peeve of mine: GitHub is terrible for the workflow that Git was originally designed for. Specifically, the issue that there's no good way to review patch series. The key here is presenting a series of patches as a whole, but allowing reviews on individual commits of the series.
This is my second or third biggest problem with GitHub. If I want to submit a patch—the thing that Git was made for—I cannot use GitHub to do it. Assuming one has already gone through the "create a GitHub account" step, my closest option is to go to github.com to create a completely unnecessary on-GitHub "fork", go back to my local copy to add that remote and push to it, and then go back to the github.com and click around to submit a pull request.
Pull requests in Git were designed for trusted, frequent collaborators. I.e., project maintainers that are routinely syncing with one another. It's not supposed to be the preferred mechanism for ordinary contributions, and certainly not for drive-by contributions.
My biggest gripe, though, is that the on-GitHub fork from the first paragraph will live on in my namespace forever, unless I manually prune it. And even if I do prune it, I still have no way to control the fact that GitHub has silently set up a social networking timeline to broadcast a centralized index of all this activity to anyone and everyone, without asking me, and without a way to manage the stuff that goes into the timeline, control who it's shared with, or turn it off completely.
Not really. You cannot comment on the commit message itself. And, if I'm not mistaken, changes made in one commit that are undone in a subsequent commit won't show up even if the files view if filtered by commit.
Also, it's difficult to tell which comment is associated with which commit.
I don't think I ever factor in commit messages into my code reviews. I may look at the commit history if I want to see how they experimented implementing the feature, but I only care about the end goal and the code I will be merging in at the end.
The issue is that Github actually discourages reviewing by commit because it makes it difficult to do so. Though there are those who are only interested in the overall diff, there are others who want to be able to maintain a clean and informative history via version control. When the review system makes it difficult to ensure that's the case, then then version control history cannot be maintained.
Precisely. We're in a vicious cycle where most people using Git don't use what ought to be Git best practices for most serious large scale projects (clean history with self-contained logical commits and good commit descriptions) because GitHub makes it so difficult to do this. And to be fair, GitLab really isn't much better in this department.
And there isn't enough pressure on GitHub or GitLab to clean up their act because most people don't even know what they're missing. And so the cycle continues.
If you use squash and merge this won't be a problem, you will have a "clean history with self-contained logical commits and good commit history", and intermediary commits won't matter anyway.
Some features take more than a single logical commit to implement. Looking at the git mailing list, I see patch series containing anywhere from 1 to 10 commits (with some as many as 15 commits).
Also, having a single commit touching many parts of the code makes it harder to revert due to a greater chanche of conflicts with other commits.
I’ve recently switched from GitLab to Github enterprise due to a job switch. I am shocked at how bad Github enterprise is to navigate. It seems like I regularly have to depend on the search function to find the repo I want.
Yay! There's one thing I would absolutely love about having a blockchain in GitHub: The transfer fees.
If everyone had to pay $1 to submit an issue and/or a pull request, open source projects would get a lot less "support spam" :)
Also, it would certainly help if people need to wait 10 minutes for their last comment to be accepted into the network before they're allowed to comment again.
> If everyone had to pay $1 to submit an issue and/or a pull request, open source projects would get a lot less "support spam" :)
I dunno, that seems odd. Do you not want to know about bugs in your project to make it better? I realize people will submit a bug b/c they can't figure out how to implement something but that is worth being aware of real bugs in the code.
Now if you could "tax" the "+1" spam culture, I'd be all aboard that
Thats possible now, right. If they supported it more I’m not sure how much value over just encrypting blobs. I wouldn’t trust github’s clients or servers to do it for me.
Keybase's remote helper (which does the crypto) is open-source, so if github did something similar you wouldn't need to trust them. That's the value of e2ee -- you don't need to trust the intermediaries, whether they start misbehaving, are forced to hand over data, get hacked, etc.
There was this one guy, whom was a cryptocurrency fanatic but not a developer, who tried to convince me to get involved in a "blockchain code database for developers". I told him that Git uses a blockchain, and he simply couldn't accept that a blockchain has been used for years on something that isn't cool or possible to monetize.
It's pretty funny how people still think that a blockchain is this magical thing, yet I'm pretty sure anyone on HN is capable of writing a blockchain in an an hour or two. Maybe even less than that.
> Such features are only conducive to drama and anxiety
Great point. I haven't used a social network yet that didn't result in me becoming at least a little addicted at one point or another. In high school, I was constantly on Twitter, seeking the dopamine rush from those likes and retweets. Getting out of there has done wonders for my personal life.
I didn’t really get the impression here that Jared wanted a social network. He just wanted a better mechanism for discovering good quality and interesting projects. Popularity is often one good signal.
I'm not sure Github stars were/are ever an indicator of "good quality" or even "interesting".
And I think the Web Development community could do with a decent break from "new" as well. What would be great is if we could just prune some of the gajillion frameworks and libraries already out there, and spend some time to make the ones we keep decently robust and elegant.
GitHub stars suffer from the same problem as likes on Twitter or Facebook. A social network would actually need three separate kinds of positive interactions:
- a like ("I want to let the creator know I like this.")
- a share ("I want my followers to know about this.")
- a bookmark ("I want to be able to find this again later.")
Most social networks only have the first two. GitHub, even worse, only has one. (I personally use stars exclusively as bookmarks, btw.)
Yes, exactly. I'm more likely to star a small project that I find interesting even if flawed because I don't want to lose track of it. I don't really understand why I would need or want to star React or Nodejs for example. There is zero chance I lose track of those projects.
For me, this is a positive thing. With this, I can find some niche things that I can't find otherwise. People star it because it provides some value to them.
I wouldn't "like" project that are broken or half done, but I star it if it can solve my problem.
On the other side, when somebody stars my project I will invest more energy into it because I see that it is useful to somebody else, not just me. Most of my projects are sparsely tested, because usually I'm the only user and it is not mission-critical. When it's broken I usually know where. When I see starts appearing on my project I add more tests and handle edge cases better, so new users have a better experience. If they would only bookmark it, I wouldn't know if somebody wants to use my software. And they would also have a bad experience, and maybe drop it after evaluating as a piece of crap.
I hate to say that I actually like that idea. I'm swamped in random notifications for weird parts of the repo I don't care about. I'd really like a "high # of comments and reactions/loc changes" feed.
