Hacker Newsnew | past | comments | ask | show | jobs | submit | Degorath's commentslogin

As someone trying to compete in this space: will ERSC make the change/commit their unit of code review? It's one of the pet peeves I have with GitHub et al.


Yes. Stacked diffs are table stakes.


Well, stacking is one thing, doing it well is another (see github) ;)

But that's good to hear.


Thought I saw that announcement on LinkedIn a few weeks back already!


Yes, he joined a few months ago, this is just getting it onto the site :)


Does it support jujutsu natively?


We are very interested in this. If anyone can put us in touch with the JJ maintainers we would love to chat!


Unfortunately I wouldn't know how to do that.

But just saying that I would probably argue against any new forge at my workplace if it didn't adopt the jujutsu model for changes. While agents can wrangle git better than 90% of developers, jujutsu just works much better for both.


While all of the points you brought up are valid, I've hated every react native app I've ever had to work on. Not because of react native itself, but because they usually take random react developers to work on these apps and the structure they create is absolutely horrible to work with (compared to, for example, native apps).

What was your experience on that aspect with Flutter?


I agree. RN has historically attracted a lot of web developers who treat mobile like a React website, and the result can be terrible. But I've seen exactly the same architectural problem in Flutter: huge widgets, mixed responsibilities, state everywhere, and very little separation of concerns. The framework doesn't protect you from bad engineering.


Ah, that's a shame to hear. I would only like to add that at least for Android apps that I've been "hanging around" (my team never really worked on them), the teaching materials that are provided have generally made them a lot more pleasant compared to the RN stuff.


No framework prevents bad engineering. If a tool is rigid enough to make messy code impossible, it becomes too limited to build anything non-trivial.

Aren't you conflating framework design with dev discipline? You can write a monolithic disaster in React, native iOS, or Flutter with equal ease. Bad architecture usually happens when devs copy-paste habits from web or imperative paradigms without adapting to a declarative model.

Flutter actually gives you great primitives for clean code. UI components are lightweight config objects, so breaking a huge screen into tiny, modular pieces has virtually zero performance penalty. Its state model naturally separates logic from rendering, making it easy to isolate business logic into testable layers. Plus, the built-in analyzer catches anti-patterns like memory leaks at compile time.

all the tools to enforce separation of concerns are there, imo


The case of RN is different: it's made from a web point of view and applied to mobile. Therefore, it's not per se about the framework, but rather a coincidence that mobile and web are two completely different worlds. Hence, it's quite normal to see abominations when you allow people who are used to the web to do mobile development.


I was forced to migrate from pure native development to React Native and Redux is one of the stupidest things I ever witnessed. Or at least the way the previous devs setup that thing, because it’s so easy to make costly mistakes with it.

I lost so many days of my life profiling and debugging to figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated


Redux is great and it solves exactly that problem.

You create a selector. You use the selector in a React component.

The component re-renders when the selector outputs a different value, with the usual reference equality caveat.

Does it get any simpler than that?

However, yes, I have seen most developers use Redux incompetently.

They would use actions like "setOrder" instead of "itemAdded", defeating the purpose of a state machine from the start.


They might have been using Redux before it did a major API change in the form of slices.


That would be about 7 years ago, when Redux Toolkit released in 2019.


There's simply a ton of teams that also never updated. My previous team was not using RTK and our redux setup was extremely confusing to me (a backend engineer).


That's probably right. Lots of people migrated from Redux onto other state management libraries.


> figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated

Could you explain how this comes from React Native and/or redux?

I have used Angular with redux (ngrx) and redux made it quite obvious what changed what and why


Bit late to the thread, but I'm building a EU native jujutsu forge that optimises for productivity and ability to deliver your features faster.

I saw that tons of companies are still on GitHub, using their unproductive tools that have no vision to how they work together and I want to do something about it.

The landing page will be up soon, but for now I am actually looking for a cofounder with a technical product management or engineering management background (the multitasker hustlers that know tech), so do reach out if that sounds interesting to you!


My experience is that in companies that rely on this flow, these assumptions are generally hashed out during design doc review/discussions. I have never had it happen to me that I need to discard the rest of the stack for an assumption that did not hold. From another angle, if I fear that this might be the case, I hold off on sending parts of the stack to review until I am sure of the assumption holding OR I instead have a "workspace ball of mud" from which I can `split` out well-formed commits. I found this to be an incredibly productive workflow.


Not sure if it makes you feel better, but it seems there's at least a few startups trying to get a jujutsu-native forge going, by people who have seen and used the way Google's (and other big tech's) systems work.


Indeed, and I happened to have been part of the creation story for one of them :) https://lobste.rs/s/ghdv6w/i_see_future_jj#c_nx6flj (not otherwise affiliated, though)


That's really cool! I tried getting on board with ERSC, but the timezone difference proved too much :(. At least it gave me the kick to try and build my own company, though!


That's wonderful! Good luck.


Jujutsu makes the author-side of it all fairly nice, indeed. But the reviewer-side has been so horribly abandoned by github that it has been frustrating me for a long while now.


A JujutsuHub.com business opportunity presents itself. How many tokens do you have?


Already working on that!


I would like to add that CachyOS also supports Niri, a scrolling tiling WM. As someone who long had "papercuts" from floating WMs I've had great success with it and even prefer it to something fully tiling like hyprland.


Depending on the country, it's not even that difficult to fire in the EU... (e.g. Estonia and Poland)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: