> (last comment - Jun 28, 2020) This isn't really an up to date of view on where we are and where we would like to go. We have some tentative plans to improve how we communicate the 'roadmap' in the future. We'll update when we know more.
> Honestly the roadmap for the near future is the same as it's been since Svelte suddenly got much more popular without a corresponding increase in maintainer resources: fixing bugs. Developing exciting new features is going to take a back seat to dealing with the huge backlog of issues for the time being.
> [...] if you do this on a github repo i'm involved with because you're dissatisfied with the help that was given freely and patiently by other contributors, i will make a mental note of who you are so i can ensure you never get my help, ever
So are you saying that you're concerned by the lack of a detailed vision for Svelte, or that you're concerned with the behavior of the primary maintainer of Svelte?
My main concerns as a "technology buyer" are (from what I found online with a rapid search): lack of funding, currently only two main committers (the original author not among them), project apparently in bugfixing-only mode, and the original author online attitude.
From an outsiders perspective, that's fair enough. However, Rich's time and focus as well as a number of other maintainers is currently on Svelte-Kit, which gets a commit around every 6 minutes at its peak, and at least every hour otherwise. Rich is ridiculously active.
I've seen some of the GitHub issues that Rich is referring to in those tweets. They're almost always cases where someone is asking for some feature or change in Svelte and the core contributors disagree that it fits with the design and vision of the project.
Then the OP tags Rich in the hopes that he will swoop in and and override the decision. It's almost always more of a tantrum than a real request for help.
As far as project progress, most of the recent work has been on SvelteKit, but I've been using Svelte for about a year now and it has steadily gained features during that time. It's definitely not in bugfix-only mode.
In [1]: def c():
...: return (1 in ([1,2,3] is True))
In [2]: c()
...
TypeError: argument of type 'bool' is not iterable
It seems related to CPython bytecode compiler implementation, the two functions are parsed in a different way, parentheses make the compiler go on a different path... but I'd like to understand why, without diving into CPython source code :) Anyone?