amoerie

Aren't we losing something there too though. I always respected a company with a product that had "things figured out" and pushed their product in conjunction with a way of working that was well researched and proven to be optimized.

I'm not convinced companies always need software tailored to their workflows, and could benefit from adopting worn-path workflows instead.

Long story: because changing identifiers is a considerable refactoring, and it takes coordination with multiple worldwide distributed partners to transition safely from the old to the new system, all to avoid a hypothetical issue some software engineer came up with

Short story: money. It costs money to do things well.

Ironically, your answer is very well compressed.

As a radiology software developer: please please let JPEG XL become a thing. I sincerely hope this might make Chrome change its mind. JPEG XL is a game changer for 16 bit lossless images. The technical landscape for these kinds of images today is barren.

Codeberg being faster might be a side effect of not being very popular yet.

I've been working on a large React + Mobx codebase for nearly 3 years now, and it's still holding up surprisingly well. Mobx is really well designed and plays nicely with React. I haven't encountered anything more appealing than this combo yet (Admittedly I haven't tried Vue yet)

Can you write declarative reactive components with regular dom? If that wasn't an issue, why wasn't React immediately designed that way?

Something a colleague once showed me: if you open PowerPoint and try to add a video to a slide, it also lets you record your screen. You can draw a rectangle anywhere and start recording. Finally, you just save the video and discard the presentation.

What you are describing is exactly how mobX works, if I'm not mistaken.

I can attest to the genius that is MobX. Having worked on a frontend project built with RxJs + React for nearly two years, I feel like I have kept all of the benefits of reactivity and discarded a lot of complexity and learning curve that mostly came from RxJs.

The API surface of MobX is a breeze, and it kind of pushes you into the pit of success.

I helped maintain (and later started rewriting) a medical web platform that used XSLT for it's HTML exactly like you described. It was powerful for sure, but a nightmare to maintain, extend or add to.

This in house framework was written before the advent of major web frameworks (at least in C# at the time) so I can understand where it came from. In fact, I still consider it an impressive feat of engineering. But XSLT to this day makes me shudder..

Generally, try the following steps:

- turn off strict flags, turn them on again after everything compiles in non strict mode - ensure you have the correct typings for the libraries you're using. Some libraries include them, others require a @typings/xyz dependency. (E.g. React and ReactDOM) - try to hunt down the root errors. Much like C# or Java, one error can lead to hundreds of compilation errors down the line, but fixing the first root error can also make all of them go away in one fell swoop. - try to keep things simple and non dynamic. Typescript is very flexible and powerful, but think twice before you use crazy constructs. - enable emitOnError. It will allow you to test while you refactor, even though typescript complains. - ask yourself: if it works and typescript does not compile, is it because typescript can't understand or is it because typescript is seeing possible issues you've not taken into account? - don't think of typescript as something to get around of. Think of it as a helping hand that will guide you in your daily work and prevent a whole swath of runtime errors, but it needs to be fed with information about your data structures and libraries to work properly.

I found React to be very nice for interactive HTML mockups. But if it's mostly CRUD, just server side rendering is probably the fastest road to a working product.