3 ms·

If you want to do "the right thing" – implement your proposal as a library, AND convince people to use it on its own technical merits. Then when everyone uses i

If you want to do "the right thing" – implement your proposal as a library, AND convince people to use it on its own technical merits. Then when everyone uses it (because it's so obviously "the right thing"), you can start asking if anyone wants your library to be built into the language. But that's not what you're doing. You're gunning for becoming the standard from the start – you are trying to convince people to use your draft implementation based on its status as a proposed standard, instead of them using it on its own technical merits. Ditch the status, and see if anyone still wants it. -- Yes, reactive UI won – just fine, without having signals in the JS standard. Because not having signals in the language was never an actual problem holding back reactive UI development in JS. Your proposal does not "bring down complexity". It simply moves the complexity from UI libraries into the JS standard. In doing that, you forcefully marry the ecosystem to that particular style of complexity. Every browser vendor will need to implement it and support it... for how many decades? And to what end? Unlike e.g. promises that are useful on their own, your proposal isn't nearly ergonomic enough to allow building reactive UIs in vanilla JS. Users will still need to use libraries for that, just like they do today. You're just moving one piece of such libraries into the standard, without building the case for why it's needed there. -- Your proposal spends pages selling the readers on signals, but that is not what you need to sell. We already have many implementations of signals. You need to sell why your (or any) signals implementation needs to be in the JavaScript standard. You have one tiny "Benefits of a standard library" subsection under "Secondary benefits" but it's just ridiculous. You're basically saying that we should add signals to JS because we've added (much simpler or more needed) things to JS before – is that really your best argument? And... "saving bundle size"? You want to bless one implementation of a complex problem to save what, 5KB of this: https://cdn.jsdelivr.net/npm/s-js https://cdn.jsdelivr.net/npm/s-js Sorry, just – nothing about this makes sense to me.

jonathanlydall 3y ago
I think you’re right, I don’t see how building this into the base library makes some things possible which weren’t before. I think that the Promise API was not the actual thing people directly wanted (and on its own had no compelling reason to be added to the base library), but a standardised Promise API was needed in order to add the hugely useful async/await keywords which are unachievable without changes to the language. I am however a big fan of a really good base library (it’s one of the things I love about working with .NET), but they should be focussing on functionality with the broadest reach (as in most encountered by average JS devs working on day to day tasks), e.g. things like better tools for working with dates and times.
- klabb3 3y ago
  > I think that the Promise API was not the actual thing people directly wanted (and on its own had no compelling reason to be added to the base library), but a standardised Promise API was needed in order to add the hugely useful async/await keywords which are unachievable without changes to the language. In JS, the async syntax is largely syntactic sugar around chaining promises with `.then()`. Promises alone fixes callback hell and brings structure and scoping to multi-stage async operations - at least to the extent possible in such a dynamic environment as JS. There are only a couple minor additions relating to the main entry points, microtasks and interactions with the runtime, to make the main async/await experience we enjoy today. This is actually a good thing, when you can build abstractions on top of other core constructs, without affecting the rest of the language too much. There may absolutely be analogous syntactic ergonomic constructs on top of signals, reactivity or observables - whichever is sensible - that could be layered on top to compose really powerful user-facing features in the future. So the success of promises and async is a still a supporting story, in my view. A lot more research and scrutiny is needed, but it’s certainly one of the top interesting ideas.
klabb3 3y ago
I don’t have a dog in the fight. I also don't see yet any mainstream support behind the proposal. So I don’t get why it has to be so heated? The main benefit is interop. Same with promises. You can implement all of promises with custom callbacks - in fact it’s trivial. But competing implementations don’t typically land on API compatibility simply because they’re solving the same problem. That causes a fractured ecosystem. Maybe interop could be important with signals? I think they should argue that, if so! > Users will still need to use libraries for that, just like they do today. Yes? But you reduce the lifting by the libs - ideally enabling a class of vanilla use-cases which can be made demonstrably improved. You could say querySelector was unnecessary because you can do it in lib. Or filter, or map. Standardization can cover std-lib like features too no? Doesn’t mean I am in favor. I think you should always default to no unless strong and consistent proven benefits. But why not have good faith arguments for what problems this will or won’t solve. For instance, if hypothetically let’s say react or svelte has a different model that cannot possibly use these signals, then that’s probably a sign it’s not good. My philosophy with proposals is balancing the curiosity and honest inquiry with a grumpy defensive inquisition before saying aye. Flaming though is really not helpful. > You're basically saying that we should add signals to JS because we've added (much simpler or more needed) things to JS before > saving bundle size Yes, I agree these are weak arguments.
troupo 3y ago
> implement your proposal as a library, AND convince people to use it on its own technical merits. That is almost literally exactly what happened: most major JS frameworks (except React) converged on Signals. > Because not having signals in the language was never an actual problem holding back reactive UI development in JS. Oh, but it did hold back reactive development. There are many limitations on current implementations of signals precisely because there's no proper support for many things in the language. > You need to sell why your (or any) signals implementation needs to be in the JavaScript standard. That is why it is: - a proposal that - calls for input from implementers, users, library developers etc. > Unlike e.g. promises that are useful on their own, But the exact same thing happened with promises: everyone had their implementation, there was no need for a proposal to add that specific API to the standard library. Deferred (the precursor to Promises) existed for several years before Promises. Here's the full history: https://samsaccone.com/posts/history-of-promises.html https://samsaccone.com/posts/history-of-promises.html And yet, 15 years later here we are

jonathanlydall 3y ago

I think you’re right, I don’t see how building this into the base library makes some things possible which weren’t before. I think that the Promise API was not the actual thing people directly wanted (and on its own had no compelling reason to be added to the base library), but a standardised Promise API was needed in order to add the hugely useful async/await keywords which are unachievable without changes to the language. I am however a big fan of a really good base library (it’s one of the things I love about working with .NET), but they should be focussing on functionality with the broadest reach (as in most encountered by average JS devs working on day to day tasks), e.g. things like better tools for working with dates and times.

klabb3 3y ago
> I think that the Promise API was not the actual thing people directly wanted (and on its own had no compelling reason to be added to the base library), but a standardised Promise API was needed in order to add the hugely useful async/await keywords which are unachievable without changes to the language. In JS, the async syntax is largely syntactic sugar around chaining promises with `.then()`. Promises alone fixes callback hell and brings structure and scoping to multi-stage async operations - at least to the extent possible in such a dynamic environment as JS. There are only a couple minor additions relating to the main entry points, microtasks and interactions with the runtime, to make the main async/await experience we enjoy today. This is actually a good thing, when you can build abstractions on top of other core constructs, without affecting the rest of the language too much. There may absolutely be analogous syntactic ergonomic constructs on top of signals, reactivity or observables - whichever is sensible - that could be layered on top to compose really powerful user-facing features in the future. So the success of promises and async is a still a supporting story, in my view. A lot more research and scrutiny is needed, but it’s certainly one of the top interesting ideas.

klabb3 3y ago

I don’t have a dog in the fight. I also don't see yet any mainstream support behind the proposal. So I don’t get why it has to be so heated? The main benefit is interop. Same with promises. You can implement all of promises with custom callbacks - in fact it’s trivial. But competing implementations don’t typically land on API compatibility simply because they’re solving the same problem. That causes a fractured ecosystem. Maybe interop could be important with signals? I think they should argue that, if so! > Users will still need to use libraries for that, just like they do today. Yes? But you reduce the lifting by the libs - ideally enabling a class of vanilla use-cases which can be made demonstrably improved. You could say querySelector was unnecessary because you can do it in lib. Or filter, or map. Standardization can cover std-lib like features too no? Doesn’t mean I am in favor. I think you should always default to no unless strong and consistent proven benefits. But why not have good faith arguments for what problems this will or won’t solve. For instance, if hypothetically let’s say react or svelte has a different model that cannot possibly use these signals, then that’s probably a sign it’s not good. My philosophy with proposals is balancing the curiosity and honest inquiry with a grumpy defensive inquisition before saying aye. Flaming though is really not helpful. > You're basically saying that we should add signals to JS because we've added (much simpler or more needed) things to JS before > saving bundle size Yes, I agree these are weak arguments.

troupo 3y ago

> implement your proposal as a library, AND convince people to use it on its own technical merits. That is almost literally exactly what happened: most major JS frameworks (except React) converged on Signals. > Because not having signals in the language was never an actual problem holding back reactive UI development in JS. Oh, but it did hold back reactive development. There are many limitations on current implementations of signals precisely because there's no proper support for many things in the language. > You need to sell why your (or any) signals implementation needs to be in the JavaScript standard. That is why it is: - a proposal that - calls for input from implementers, users, library developers etc. > Unlike e.g. promises that are useful on their own, But the exact same thing happened with promises: everyone had their implementation, there was no need for a proposal to add that specific API to the standard library. Deferred (the precursor to Promises) existed for several years before Promises. Here's the full history: https://samsaccone.com/posts/history-of-promises.html https://samsaccone.com/posts/history-of-promises.html And yet, 15 years later here we are