Readit News logoReadit News
tcoff91 commented on GraphQL: The enterprise honeymoon is over   johnjames.blog/posts/grap... · Posted by u/johnjames4214
rbalicki · a day ago
1000%. There's almost no reason to use GraphQL unless you take advantage of data masking + fragment colocation.
tcoff91 · a day ago
I have that with URQL+gql.tada.

What else does relay give me that URQL does not?

tcoff91 commented on GraphQL: The enterprise honeymoon is over   johnjames.blog/posts/grap... · Posted by u/johnjames4214
maxcan · a day ago
Can you elaborate? I've used URQL and Apollo with graphql code gen for type safety and am a big fan.

What about relay is so compelling for you? I'm not disagreeing, just genuinely curious since I've never really used it.

tcoff91 · a day ago
Try gql tada it’s much better than graphQL codegen
tcoff91 commented on GraphQL: The enterprise honeymoon is over   johnjames.blog/posts/grap... · Posted by u/johnjames4214
timcobb · a day ago
> The main problem GraphQL tries to solve is overfetching.

this gets repeated over and over again, but if this your take on GraphQL you def shouldn't be using GraphQL, because overfetching is never such a big problem that would warrant using GraphQL.

In my mind, the main problem GraphQL tries to solve is the same "impedance mismatch" that ORMs try to solve. ORM's do this at the data level fetching level in the BE, while GraphQL does this in the client.

I also believe that using GraphQL without a compiler like Relay or some query/schema generation tooling is an anti-pattern. If you're not going to use a compiler/query generation tool, you probably won't get much out of GraphQL either.

In my opinion, GraphQL tooling never panned out enough to make GraphQL worthwhile. Hasura is very cool, but on the client side, there's not much going on... and now with AI programming you can just have your data layers generated bespoke for every application, so there's really no point to GraphQL anymore.

tcoff91 · a day ago
URQL and gql.tada are great client side tooling innovations.
tcoff91 commented on Stacked Diffs with git rebase —onto   dineshpandiyan.com/blog/s... · Posted by u/flexdinesh
1718627440 · 10 days ago
I guess I never had complex trees from such an action, just a bunch of parallel branches, but I would say splitting and picking commits from different branches is not exactly hard with git either. Also you can also see them in git, but they won't have change ids of course.
tcoff91 · 9 days ago
I know how to do everything in git that I can do in jj but the thing is I would never bother doing most of these workflows with git because it’s way more of a pain in the ass than with jj. I work with version control in a totally different way now because how easy jj makes it to edit the graph.

Within a day of switching I was fully up to speed with jj and I never see myself going back. I use colocated repos so I can still use git tools in my editor for blaming and viewing file history.

Sure even rebasing a complex tree in git can be done by creating an octopus merge of all leaf nodes and rebasing with preserve merges but like that’s such a pain.

tcoff91 commented on Stacked Diffs with git rebase —onto   dineshpandiyan.com/blog/s... · Posted by u/flexdinesh
1718627440 · 10 days ago
The last one is always available via `git checkout -` and if you want to do more you can do `git checkout @{4}` etc. . It will also show up in `git log --reflog`. I honestly don't see the problem with naming things. Typing a chosen name is just so much more convenient than looking up the commit hash, even when you only need to type the unique prefix. When I don't want to think of a name yet, I just do "git tag a, b, c, ..."

I also tend to have the builtin GUI log equivalent (gitk) open. This has the behaviour, that no commit vanishes on refresh, even when it isn't on a branch anymore. To stop showing a commit you need to do a hard reload. This automatically puts the commit currently selected into the clipboard selection, so all you need to do is press Insert in the terminal.

> It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.

I don't think that needs to be implemented like this. The only thing you need to do is recording the list of commands and program a resolver that outputs the inverse command of any given command.

tcoff91 · 10 days ago
Yeah but in jj every time you run ‘jj log’ you see all your anonymous branches and you can rebase all of them at once onto main in 1 command.

When I’m exploring a problem I end up with complex tree of many anonymous branches as I try different solutions to a problem and they all show up in my jj log and it’s so easy to refer to them by stable change ids. Often I’ll like part of a solution but not another part so I split a change into 2 commits and branch off the part I like and try something else for the other part. This way of working is not nearly as frictionless with git. A lot of times I do not even bother with editor undo unless it’s just a small amount of undoing because I have this workflow.

Git is to jj like asm is to C: you can do it all with git that you can do with jj but it’s all a lot easier in jj.

Deleted Comment

tcoff91 commented on Stacked Diffs with git rebase —onto   dineshpandiyan.com/blog/s... · Posted by u/flexdinesh
1718627440 · 10 days ago
> Also, anonymous branches are SOOOO much better than git stashes.

You can do anonymous branches in Git as well. I use both for different use cases.

tcoff91 · 10 days ago
The UX around anonymous branches in git is not nearly as good as jj though.

Also git has no equivalent to the operation log. `jj undo` and `jj op restore` are so sweet.

tcoff91 commented on Stacked Diffs with git rebase —onto   dineshpandiyan.com/blog/s... · Posted by u/flexdinesh
jhhh · 11 days ago
Last time I saw this claimed (maybe from steve's tutorial?) it was just autosquash. Do you have another example?
tcoff91 · 10 days ago
https://ofcr.se/jujutsu-merge-workflow

With `jjui` this strategy takes only a few keystrokes to do operations like adding/removing parents from merge commits.

It's so nice to have like 4 parallel PRs in flight and then rebase all of them and all the other experimental branches you have on top onto main in 1 command.

Also, I cannot even stress to you how much first-class-conflicts is a game changer. Like seriously you do NOT understand how much better it is to not have to resolve conflicts immediately when rebasing and being able to come back and resolve them whenever you want. It cannot be overstated how much better this is than git.

Also, anonymous branches are SOOOO much better than git stashes.

tcoff91 commented on Covid-19 mRNA Vaccination and 4-Year All-Cause Mortality   jamanetwork.com/journals/... · Posted by u/bpierre
llmslave · 11 days ago
Vaccines benefit the population, at the expense of the individual
tcoff91 · 11 days ago
Not getting measles, polio, etc… seems like a pretty big benefit to the individual.
tcoff91 commented on Stacked Diffs with git rebase —onto   dineshpandiyan.com/blog/s... · Posted by u/flexdinesh
hansvm · 11 days ago
> introduces some mental friction in walking away???

I don't think it's just mental friction. Suppose you've learned git well enough that everything you do in it is automatic and fast, and the things which aren't fast by default you've built aliases and tooling for over the years. Yes, starting from ground zero you might want something like jj, but at the current point in your life you're not starting from ground zero. Switching to jj means learning another tool to achieve similar outcomes on your workflows.

tcoff91 · 11 days ago
But with jj there are better workflows that aren’t really doable with git.

u/tcoff91

KarmaCake day1582March 15, 2015View Original