Ractive 1.0?

[Jeff17Robbins]

Description:

We are depending on Ractive for a production application -- when can we get to a stable API?

Ractive is excellent, and we want to see it continue to progress. That said, I was kind of expecting to see a Ractive 1.0 come after Ractive 0.9.X, and with that expectation I was hoping to see some stability around the API and Mustache syntax.

If instead of Ractive 1.0, we are continuing with Ractive 0.10, I'm wondering when we can get to some stability? I ask because we have an application in production that depends on Ractive, and breaking changes are getting costlier for us. I'd like to be able to keep up with new Ractive releases, and I think our testing contributes to Ractive reliability, but if, for example, [RFC 0.10] (https://github.com/ractivejs/ractive/issues/2947) breaks existing Mustache syntax, we won't be able to keep up as readily.

Again, we don't want to hold up progress, and that RFC has some truly great ideas about regularizing filtering and sorting that I like a lot. But I thought I should put the question out there:

When ought we target getting to a stable Ractive 1.0?

[evs-chris]

The main core of Ractive should be pretty stable at this point. The only mustache syntax that's maybe in danger after 0.9 is the index on iterations e.g. {{#each list: i}}. I think everything else has been mostly decruftified. Beyond that, there's some planned potential breakage in transitions, adaptors, and decorators.

Now, 0.9 should be pretty stable and will be actively supported until 0.11 comes out. If we go according to my personal roadmap, 0.10 or maybe 0.11 would be the last release with any sort of major-ish breaking changes. Again, those breaks would likely only happen in the areas mentioned above. Then it would be 1.0 and any further breaking changes would go to 2.0.

Does that sound pretty reasonable, or should we shoot for 1.0 next with breaking everything else in 2.0? Either way, we are now branching "major" versions, so maintenance on them is much much simpler than it has been in the past.

[Jeff17Robbins]

We can live with maybe breaking iteration indexes. 😃 We counted about 50 of 'em in our templates -- not the end of the world to edit.

I understand waiting until transitions, adaptors, and decorators are decruftified prior to nailing down Ractive 1.0. We aren't using any of those (thanks to 0.9's nice cross-instance link() feature, no more Ractive-Ractive adaptor required.) So, selfishly, you could cut a Ractive 1.0 prior to fixing those, but it isn't crucial to us.

What is important to us is reaching a stable API and Mustache syntax at some point in the foreseeable future. It sounds like we are close!

[JonDum]

As a side note, keeping Ractive < 1.0 may be doing more harm than good. Many clients I've dealt with were concerned with me using a framework that wasn't even 1.0 yet. It screams unstable and risky to the layman.

Maybe it's time to just bite the bullet and 1.0 it for public perception.

Do the breaking changes for non-core functionality in 1.1, 1.2, 1.n and save 2.0 for a major rewrite if it ever happens like the massive clusterfuck that 0.7->0.8 was.

On May 1, 2017 1:25 PM, "Jeff17Robbins" notifications@github.com wrote:

We can live with maybe breaking iteration indexes. 😃 We counted about 50 of 'em in our templates -- not the end of the world to edit.

I understand waiting until transitions, adaptors, and decorators are decruftified prior to nailing down Ractive 1.0. We aren't using any of those (thanks to 0.9's nice cross-instance link() feature, no more Ractive-Ractive adaptor required.) So, selfishly, you could cut a Ractive 1.0 prior to fixing those, but it isn't crucial to us.

What is important to us is reaching a stable API and Mustache syntax at some point in the foreseeable future. It sounds like we are close!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ractivejs/ractive/issues/2949#issuecomment-298423001, or mute the thread https://github.com/notifications/unsubscribe-auth/AALtsM_tz_XdYdPHy7-synWay265XoC8ks5r1j-tgaJpZM4NNTl- .

[Jeff17Robbins]

How do folks feel about Semantic Versioning? Summary:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

If Ractive follows this convention, then breaking API changes require a MAJOR version change.

That was my only reason for thinking it OK to stall on Ractive 1.0. But @JonDum raises a very important point. The time might be right to focus on a production-worthy Ractive 1.0, and save the filter/sort upgrade along with other breaking changes (adaptors, decorators, etc) for an eventual 2.0. I don't think I'm describing any major change in how the work gets done, or when the work gets done.

It is mostly a choice as to whether or not we follow Semantic Versioning.

UPDATE

I read this on the Semantic Versioning page:

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

We (LiveData, Inc.) are using Ractive in production. We're hoping other people are, too! I think the time is right to get to a Ractive 1.0 release!

[dagnelies]

Indeed, from a perception POV a 1.0 would indeed be helpful. I know, it's just a number, but it might influence people's early decisions.

[fskreuz]

Sub-1.0 is normally classified as unstable. As stable-looking as it is, Ractive still falls under that category, hence the version. Probably if we can get a consensus that Ractive is sufficient as it is right now (considering the remaining issues of course), we could publish a 1.0 soonish and start following semver to the letter.

Speaking of which, there are plans to auto-publish and auto-version Ractive depending on test results (if something's added, if something breaks, etc). This is why there's been cleanups in the build and tests department lately. However, the tool will publish it as 1.0 on the first run (as far as I've read). We just want to make sure it's stable to actually declare it 1.0 before adding that tool in.

---

I'll add this thread to this collection where we respond with "When it's done" 😄

• https://github.com/ractivejs/ractive/issues/2077#issuecomment-136003028
• https://github.com/ractivejs/ractive/issues/416#issuecomment-34593364
• https://github.com/ractivejs/ractive/issues/2477#issuecomment-204708302
• https://github.com/ractivejs/ractive/issues/2389#issuecomment-186343319

---

By the way, I'm also in favor of a 1.0 although I only use the basic constructs and have been writing components in the same way since 0.4. 😄

[evs-chris]

I've gone back and forth on cutting 1.0 next a few times. I've even considered making 0.9 1.0 instead. That's one of the reasons I went ahead and broke some of the cruftier APIs that had long-standing issues, like merge.

How does this sound for a plan?

• Get 0.9 out and let it get a bit of exposure.
• Go ahead and break iterative indexes on edge in whatever way they'll be broken.
• 0.9 is a little chunky, so get post-0.9 edge to drop a bit of weight. I'd be happy with 30k off the minified build.
• Cut 1.0 somewhere around end of summer/fall (in the northern hemisphere).
• New features, like iterative sorting and filtering, are semver minor, so they can come out in 1.1, 1.2 etc.
• We could flag transitions and adaptors as unstable so that they can be broken, or we could just push them into a 2.0.

[Jeff17Robbins]

Since weight loss is semver minor, couldn't that happen after rel 1.0? (Or are we feeling @Rich-Harris svelte-envy? 😉)

Otherwise, the plan sounds good to me!

[fskreuz]

Svelte belongs to a different league 😉 Here's the actual competition:

[Jeff17Robbins]

I'm not opposed to shrinking Ractive. But I don't see a reason to delay rel 1.0 for that.

[sabob]

Svelte belongs to a different league

Does it scale for large projects? For example, looking at the Crud example, it outputs, 500+ loc. As a project grows it could end up with more kb than having a runtime...

[fskreuz]

I'll leave that to @Rich-Harris to answer 😉 .

[Rich-Harris]

It's a good question that we need to do a better job of communicating the answer to. I'd answer it in a few different ways:

• Some of the code is shared between components (methods, and helpers like detachNode etc) — if you compile using shared: true (which happens automatically if you're using a build tool integration like svelte-loader or rollup-plugin-svelte) then all that stuff gets deduplicated, reducing the incremental cost
• The output is designed to be relatively readable, but it minifies really well
• Nevertheless it's true that in theory there's a crossover point where the size of the generated code exceeds the size of library+templates. But by the time you get there, you really ought to be code-splitting (loading components asynchronously, e.g. based on the current route), and code-splitting works much better with Svelte than traditional UI libraries (because traditionally, even the smallest chunk has an immovable dependency on the library itself)
• Code size is only one of the project's goals — it's also about performance, developer experience (as a compiler, you can really go to town with helpful error messages and warnings, such as using fuzzy string matching to say 'did you mean this other thing instead?' like in Elm), features (it's so nice never having to say 'no' to good feature ideas, because there's literally zero impact on people who don't use them) and so on
• There's more we can (and will) do to reduce the generated code size, such as smarter handling of whitespace, or using innerHTML if there's a big chunk of static markup where it doesn't make as much sense to generate it programmatically. In general, code size will trend downwards as the compiler develops

Of course, there are always trade-offs — in Svelte's case the trade-off relative to Ractive is flexibility. You can't do this.observe('some.nested.property', ...), or use adaptors, or have {{#with ...}} blocks, or various other things. Those make sense with Ractive, which has a do-what-I-mean philosophy. Svelte, because it relies on static analysis, is more do-what-I-say, and so ends up being much stricter.

Sorry for hijacking the thread 😬

[paulie4]

I agree with @Jeff17Robbins that shrinking the codebase could be a semver minor increment, like 1.1, so it doesn't have to hold up 1.0.

[evs-chris]

Next version will be 1.0 🎉.