spion

This is fascinating, but I'm not sure this is the reason (or a good excuse for?) why software estimation is a mess right now. If you look at standard industry practice, the concept of "probability" rarely enters the discussion at all when estimating.

I've personally had great success with three-point estimation. [1] As far as statistical methods go, its pretty simple - yet it tends to work surprisingly well. To my knowledge however, none of the popular software on the market has any of the tools needed to do even something as basic as this, at least out of the box.

There is a whole set of tools out there for probabilistic modeling, and if we're serious about estimation, we should start talking about them.

[1]: https://en.wikipedia.org/wiki/Three-point_estimation

I think the reason it wasn't talked about before is because React used to be better / have less unnecessary complexity than it does today. The front-end pain has grown by an order of magnitude since.

I don't think HTMX addresses the fundamental problem of organizing (HTML) code into components, and/or the full-page-render / partial split. There is code duplication to ensure that every URL can render both fully server-side and update correctly client-side when e.g. hx-push-url happens (which most well built SPAs were able to do even before SSR, albiet somewhat slowly and poorly)

edit: Another problem that most front end frameworks seems to have stopped focusing on is building actual applications, i.e. things you would approach with https://localfirstweb.dev/ tools. HTMX can't help there at all.

You can use the "dropping a hash" method (patio11 has used this). As you progress your work, you publish a hash of it using a service trusted by everyone to correctly identify the researchers and timestamp their hashes.

If someone publishes the paper, you can then publish the files that resulted with the dropped hash and therefore prove you had certain progress of the work at a certain time.

relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387 and which shows that a symbol based protocol was the kind of approach that could've worked from the start.

See `Symbol.keyEquality` - although that still shows what I feel is a misunderstanding about the direction at which the protocol should work. I don't want to be creating new types of maps and sets, I want existing ones to have controllable key equality. If it was for new types of maps and sets, I'd just implement a new Set class independent of JS builtins and be done with it. (Its not like the built in Set offers any rich features that I'd have a hard time replicating anyway)

Protocols (traits) should really be the cornerstone of TC39 work, IMO. They'll help with JavaScript's serious ecosystem compatibility issues.

While that could help, I don't see why records and tuples are necessary. We added symbols precisely to deal with this issue in a backward compatible way. We could add symbols for set/map protocols using `equals` and `getHashCode` which would enable any objects to get set/map deduplication functionality. Those implementation could then be the mechanism how its implemented for records and tuples.

If this is a bad way to do it, then why isn't TC39 working on a better way to implement protocols / traits in JS?

Maybe its worth looking into land value tax again.

Do they force 2FA only or phones as well? If its just 2FA there is an option to use a TOTP application (e.g. andOTP for Android)

Which they can fix by updating the lock file.

A JS standard library would be a drop in the bucket compared to the size and complexity of the DOM libraries and implementing a usably performant JS engine.

Yes it should be done carefully. There are also plenty of examples of how this can be done well, done by experienced engineers. For example, the Dart starndard library (https://dart.dev/libraries - core [1], collection [2] and async [3] in particular) is a very good model that would fit JS fairly well too (with some tweaks and removals)

[1]: https://api.dart.dev/stable/3.2.4/dart-core/dart-core-librar...

[2]: https://api.dart.dev/stable/3.2.4/dart-collection/dart-colle...

[3]: https://api.dart.dev/stable/3.2.4/dart-async/dart-async-libr...

Switch to a "softer" interpretation of "*" that rather than blocking unpublishing of every version, allows unpublishing as long as one version is still available.

A softer interpretation is possible. "*" should mean that the dependency cannot unpublish all packages and must have at least one version available.

A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them

AFAIK, gene links have only been found for persistent cough and shortness of breath, but not other long covid symptoms.

Protection from vaccines has ranged (IIRC) from none to about 50% reduction in probability

> well some guy named 'somedude82' in an unpopular HN post compared it to npm

It implies that the JS ecosystem is well known for behavior just like the InfluxDB example - its the benchmark example of such behavior. That was my point.

> The state of the art has advanced.

Here is where I have the most fundamental disagreement. My position is: "It hasn't advanced significantly because the JS ecosystem wants to restart every time it gets difficult". Well ok, its a bit more complex than that (external pressures from React and other driving force libraries / frameworks), FOMO and all that - but at the end of the day, the actual progress has been very slow.

> This discussion has had the exact opposite effect for me.

I'm sorry about that, and if I think about it I guess discussion didn't do that for me either. In fact if I look at my hacker news history, I was probably arguing the opposite side quite a bit until 2-3 years ago. For me it was probably trying out Rust. Which isn't to say I think Rust is perfect (I'm still not sure that it makes sense to spend any effort thinking about memory management in the vast majority of cases, even with a compiler helping) but it provided a very interesting high-contrast point of comparison for me.

> I honestly think css-in-js solutions that inject styles into the document head at runtime like Styled Components and Emotion were never really sustainable or performant, and server components just revealed the inadequacy of these techniques.

Sure. But here we have one that happens to be used by most popular UI toolkits. Forget about Mantine, it feels like MUI is in every other project.

Now again anecdotally, outside of the JS community, the approach and attitude of maintaners would typically be:

- how do I make this extremely widely used package have less issues with minimal backward compatibility breakage

- can I additively introduce features that are not prone to the issues

not "I'm starting over"

Just in the article comments there are 5 other people pointing out a variety of issues with the author's new favorite choice. And they're all kinda right - all choices have tradeoffs. That's precisely why only dedication to compatibility and continuity can grow any one of them into something that is still sensible to use while acknowledging its limitations.

This is IMO a more sensible approach to software engineering

- Start with an approach that is significantly stronger in a certain aspect

- Acknowledge its limitations

- Work to ameliorate those as much as possible

P.S. the article about Emotion is also an example of how React's "no wait, this was always a bad idea because <X>" (where X in this case was concurrent mode) is causing rippling breaking changes. Again, this is their prerogative and at the end of the day, they have their own priorities internally at Facebook. But that's not necessarily healthy for the wider community.

Also FWIW, InfluxDB's approach to breaking changes has been compared to "a random npm library" https://news.ycombinator.com/item?id=37206194

> The only data either of us have is anecdata, which is why we're kind of at a standstill here.

This discussion has been also been useful for helping me pinpoint what exactly is different about JS when I'm working with it.

I'm still hoping I was at least somewhat convincing, because I don't think this is a problem that can be tackled without wider acknowledgement from the JS community.

> You don't think you're maybe contorting yourself to make some of these arguments work?

First of all, I still prefer TypeScript to Python when it comes to language features. So no, I'm not defending my favorite language here - if anything, I'm "attacking" it.

Secondly, I don't really think in terms of defending favorite languages - they all come with strenghts and weaknesses and I think that its important to talk about and acknowledge both aspects even for languages we really enjoy. That's the only way for languages to move forward and improve.

That said, being embedded into an ecosystem for a long time makes us used to its strenghts and desensitised to its weaknesses. This in turn makes it harder for us to really see the ecosystem's standing compared to others.

I'm trying to provide a perspective as someone who has worked in the ecosystem for a long time and has recently started exploring other options.

Are JS package managers better than Python's? Certainly. If you took a sampling of various tools and libraries in Python, would you be far more likely to have them work together than a sampling of various tools in JS? Absolutely.

I'm a relative beginner to Python compared to JS/TS, but I had a chance to work with it more recently. I had no trouble dealing with pip, venvs and poetry. Yes, there were challenges and annoyances but at least it was possible to overcome them with sufficient knowledge. I agree though - Python has long ways to go to improve this.

However, if I compare this with my previous JS experience, its a different order of magnitude. No amount of knowledge would've made styled components work with next's app router - I simply had to start over and make different choices for my SSR framework and UI library (the alternative was to help with Mantine's migration away from Emotion). So what do I do with my other, already well-developed side project that uses Mantine and Next pages router? I can continue to use the pages router, but for how long? Who knows - its not like there is any kind of concept of LTS or even any kind of thought on that topic when it comes to Next.js anyway (e.g. https://github.com/vercel/next.js/discussions/41906)

At the end of the day, IMO the main difference is attitude. There is broad acknowledgement in the Python community about their problems and they're considered important to solve. I don't see anything like that in JS - compatibility and providing continuity is just not something most authors want to think about. Innovation is (still) priority #1

I realize its hard to make a convincing statement about frequency/magnitude/probability/attitude though. Similar examples will exist across ecosystems. What kind of data would convince you that the situation in the JS ecosystem is bad enough that it warrants a priority shift in the community?

One last bit

> You certainly could've submitted this during the RFC on hooks. There was a lengthy discussion before the design was finalized (which another commenter mentioned when you posted that comment to HN).

There were RFCs submitted. My conclusion from that entire discussion was that the React team proceeded the way they've decided anyway without providing very convincing explanations and the priorities they had didn't align with most of the community. I believe this is in line with how other Facebook OSS works. React has largely been built with internal clients and their needs in mind. Additionally there seemed to be the desire to continue to be "iconclastic" and innovative and power through criticism in a similar manner that the initial React release did.

That's all perfectly fine, but in my opinion its not what the community needs, and we'de be better off moving on to other solutions (e.g. Solid, Svelte). But more important than that, we need to move on to a different mindset, because without that mindset change we're likely to go through the same problems over and over again.

> I disagree with your characterization of async in JS. First of all you're tossing in a bunch of fringe concurrency techniques to distort history. There have been three mainstream ways of doing concurrency in the three or so decades that we've had JavaScript (in the following order). Callbacks (which is the primitive we were originally given from the browser and node emulated, e.g. addEventListener), promises (which have been standardized incredibly well, e.g. Bluebird promises still work after all these years), and async/await syntax which is a nice layer of syntactic sugar on top of promises that every language with promises eventually adopts.

I am (was) one of the maintainers of Bluebird. I'm well aware of the exact state of the node-dominated ecosystem at the time. Promises weren't much more popular than the "fringe" libraries you're describing, and (err, res) style callbacks largely dominated in the ecosystem. And yet it didn't matter - promises got standardized, even though the node community largely disliked them. Very different from the Rust process.

> Your definition of stability must be wildly different from mine then. Every time I have to install a python library on a new machine I audibly groan.

I'm aware that the python packaging story sucks. However there is broad awareness and strong desire to fix this. There is standardization work to get the ecosystem into a state that is largely coherent. There is much less such desire in JS: the thought of coming up with a "standard component interface" for example (i.e. a cross-framework compatible way of writing components) would be met with ridicule. (Note that I don't mean web components - I mean a common interface in the "trait" sense)

The Python article you linked itself admits "expirienced people will know what to do, this is not for them". Well that's not the case in JS - its actually really easy to get a combination of tools that simply will never, ever work with each other, just because they weren't designed with any common interface or compatibility in mind - regardles of how experienced you are. For example, at some (relatively short) point in time around 2019/2020, react-native simply didn't work with pnpm, because it assumed that packages installed together will have access to the same node_modules, so some of the packages dind't have the correct dependencies listed; pnpm being strict dind't provide the unlisted ones, which mean react-native was broken. (Later pnpm added a mode just for this sort of brokenness, but these sort of limitations pop up all the time)

> JS is in a particularly difficult position because it runs in both the browser and the server, and because it's built on web standards and TC39 uses design by committee (there's no BDFL supervising JS).

There's been plenty of time to fix things. Its not just about the ability, its about the general attitude in the community and our priorities. Before things get better, we have to admit they're really bad, and that we need to focus more on compatibility, continuity and colaboration instead of ignoring them in the pursuit of the latest "innovative" idea.

This is not the definition of backward compatibility I have in mind. Backward compatibility also includes "continuity", that is the new features flow from previous design.

React has been redesigned 2 times and now with server components its even less of an extension of previous ways of doing things.

Building 3 different frameworks where the old way to write code still works but nobody builds on top of that in any meaningfully useful way is a very minimal definition of "backward compatibility"

The problem isn't just react though. Most libraries in JS land just don't prioritise interfaces, compatibility and colaboration, instead opting for a "I'm just gonna build my own thing and not care about anything else out there" mentality.

Lets look at that Rust comparison and see how the equivalent situation looks like for JS. Before async-await, Rust had a variety of libraries implementing something close to Futures. They all largely standardized on the Future trait from the futures crate, which made it possible to write compatible library code that could build on top of any of them. There was a bit of an issue with compatibility as the trait essentially moved into std and some compatibility shims were needed, but after that a lot of the ecosystem adopted it and its possible to write runtime-independent code

In contrast in JS land, we had callbacks which were not even values, Promises (which had a working group that actually cared about compatibility), monadic Futures, observables, thunks, event-based interfaces, a variety of libraries. This came to be dominated with node-style callbacks, and then what got standardized were promises which instantly made most of the library ecosystem incompatible with the standardized syntax.

Both ecosystem have had these challenges, but to me it seems clear that the Rust community approached it with more care and thought on average.

Going beyond async-await, we can see similar patterns in the rest of the ecosystem. We have:

- half a dozen different component frameworks and not one has thought to define an compatible component interface that anyone could implement.

- 10 different popular libraries for manipulating standard library collections, but not one common protocol or trait (other than iterable and concatspreadable) that would make them largely work with other custom collections (e.g. MobX reactive collections or similar)

- 5 different popular bundlers and 10 older ones, but not one common trait, interface or standard for writing bundler plugins

- at a certain point, we had 3 different ways to define monorepo workspaces between npm, pnpm and yarn

So for a variety of reasons we have a very "internally incompatible" ecosystem. You can barely get components to work together, and what works together today is almost guaranteed to break tomorrow.

I think that if we recognize this is a problem collectively, there may be a way out. There is very high interest in some maintainers for doing this, especially those that care about compatibility. This is because one-sided care is not enough - the side you want to be compatible with has to care and prioritize it too. Those maintainers could decide to form a sub-community that prioritizes compatibility and continuity amongst them, as well as a promise to their users.

The recognition has to be more widespread than just in maintainers though, as frameworks that have done this before (e.g. Ember) have been largely left behind due to hype propping up the latest shiniest thing.

You can't use more than one context in React classes

"React" has been around for 10 years but in practice its been 3.5 different frameworks

- the original

- the class version (still close enough to original)

- hooks version (largely a whole different concept and "compatible" only superficially while the rest of the ecosystem starts writing incompatible things)

- server components, and `use`, which monkey patch fetch and already broke half of the ecosystem.

And no, hooks are still far from perfect and are infact very unintuitive and awkward to pretty much anyone who hasn't used React.

Additionally, there were designs possible to evolve from class components, its just that the React team cared more about

- "innovation",

- "functional" aesthetic preferences

- enabling a DCE compiler

rather than compatibility and continuity

Example design that would prioritise compatibility and continuity while still enabling all the current features of hooks: https://news.ycombinator.com/item?id=35192312

Again, this is _not enough_ attention to backward compatibility and stability in other ecosystems, even older ones like Python.

My point is that this sort of thing doesn't happen so lightly in other ecosystems. And the "you don't have to use it" excuse isn't used when the project clearly wants to move in that direction:

- others will jump on the feature and use it. you might not have to use it but libraries you depend on may decide otherwise and rewrite

- you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general.

- you will slowly see bugs being neglected if they're not about the new and shiny.

- there is no equivalent of useContext for class components

So the word "supports" here carries very little weight in practice because the rest of the ecosystem constantly rewrites.

here is a sample of well-meaning maintainers franatically trying to deal with situations like these and maintain some semblance of compatibility https://phryneas.de/react-server-components-controversy

I've spent 12 years in the JS ecosystem. It really is that bad and it got significantly worse in the past couple of years. It was hard to see it however until I tried working in some of the newer ecosystems like Elixir, Rust, Go.

Things break all the time and a variety of tools and technologies just don't work with eachother. Making choices is like stepping on land mines - tomorrow the ecosystem might decide that choice was wrong and abandon all effort into it (e.g. next server components breaking most css-in-js libraries).

It doesn't have to be this way, there are ecosystems where this is not the case.

Despite that there is still a lot to like and enjoy. TypeScript is really excellent, building UI with things like tailwind can be a pure joy when you get into the flow, reactivity libraries like MobX / Solid and frameworks like Svelte largely make you feel like you're only writing business logic when managing state, etc. But overall the ecosystem is extremely "internally incompatible" for lack of a better word

I'm surprised they didn't mention SQL Server's "FOR JSON", which doesn't solve the problem they're solving entirely (n:n cannot be deduplicated AFAIK) but it can get you 90% of the way

https://learn.microsoft.com/en-us/sql/relational-databases/j...

(I can't help but wonder if this whole thing would be a lot better if SQL had a more first-class concept of sum types...)

What are you refering to, more specifically, from Codd's original paper?

IMO the title is actually pretty great. Yes its not very precise, but on the positive side its catchy and gets the point across quick.

Abstractions are not cheap and disposable. If 5 places use one abstraction, it takes at least (1) 5x the effort to dispose of them compared to changing one of those places.

(1) At least 5, because sometimes its worse. Example: lets say you are using a bad ORM which in addition doesn't expose its connection pool in any reusable way (most don't). You want to introduce a good ORM, but you can't because duplicating the size of the connection pool is too expensive. Additionally, because the ORM triggers events when objects are created and modified, and database state relies on that, you cannot use the other ORM for object creation and modification unless you replace them all at once. So you would have to refactor your code to introduce your own data access layer that has implementations for both ORMs, then switch over all at once.

In contrast, introducing deduplication later is somewhat easier. You can build an abstraction and test it with 1 or 2 of the existing parts of the code, then migrate the rest incrementally instead of all-at-once. It will also prevent some bad (expensive) aspects of the design due to the requirement that it must be incrementally adoptable (must be able to have a reusable connection pool, demand a more reliable change events system etc) and as a corollary it will also be incrementally removable.

If you don't mind, I'd like to propose an alternative list:

- Most of our abstractions are bad, even those we think are good. The good ones are largely already in our libraries (although even that isn't always the case unfortunately).

- Bad abstractions are a time sink.

- Writing code is also about communicating with other humans (on the team), so what they think about communication matters a lot more than what I think

You can also (surprisingly) ask ChatGPT for validation. The part of the LLM that activates when solving problems is going to be different than the one that activates when reviewing.