Riot: Riot 4 roadmap

[GianlucaGuarini]

Recap

It's almost one year that we didn't release updates about Riot v4 so I think opening a new roadmap issue (closing the old one https://github.com/riot/riot/issues/2283) is the cleanest way to keep our community updated regarding the upcoming news.

Riot v3

Riot v3 is feature complete and bug free so we will update the source code just in case of security vulnerabilities. All the enhancements and the yield problems submitted by some users will introduce breaking changes so I would like to keep the current API/behavior stable as it is and move forward.

Core Contributors

Please see here

Riot v4

Riot and Simulacra.js will join forces

Riot 4 will use Simulacra.js as default rendering engine.
Simulacra.js is currently one of the fastest and smartest rendering engine available and its creator @daliwali is now a riot core member. Dali will actively be part of the riot 4 rewrite and we started already working on a new parser/compiler.

Components Structure

The riot components structure will be a bit refreshed but it will not be a radical change. We will avoid the current ambiguities in favor of a cleaner and nicer structure.

Old

<my-component>
  <h1 if={ title }>{ title }</h1>
  <ul>
    <li onclick={ onClick } each={ items }>{ value }</li>
  </ul>

  var goodbye = 'goodbye'

  this.on('mount', function() {
    console.log('mounted!')
  })

  onClick() {
    this.title = goodbye
  }

  <style>
    :scope {
      color: red;
    }
  </style>
</my-component>

New

<my-component>
  <h1 if={ title }>{ title }</h1>

  <ul>
    <li onclick={ onClick } each={ item in items }>{ item.value }</li>
  </ul>

  <script>
    var goodbye = 'goodbye'

    export default {
      onMount() {
        console.log('mounted!')
      },
      onClick() {
        this.title = goodbye
      }
    }
  </script>

  <style>
    :root {
      color: red;
    }
  </style>
</my-component>

New Ideas

We got many new ideas for the rewrite but we need to test them first so you will be informed when the compiler will be in a functional prototype state.

Release date

At moment we don't have any fixed release date, we only know that a full rewrite of the framework in 2 of us (working only during our spare time) will take quite some time. We will inform you about a plausible release date when a first prototype will be released. Please donate to our open collective campaign if you want to actively support the development of the new Riot.js major release

API changes 🚧

• [ ] Complete rewrite of the compiler simplifying the sourcecode and the parsing
• [ ] Switch to Simulcra.js as default rendering engine
• [ ] Remove riot-observable in favor of callbacks lifecycle methods
• [ ] Remove this.tags from the tags instances in favor of ref https://github.com/riot/riot/issues/2360
• [ ] Add support for shadow DOM or at least support the :root selector instead of :scope
• [ ] Remove riot.csp.js in favor of a single version compatible for any environement
• [ ] Cleanup the readme file removing dead links to tutorials or old riot stuff
• [ ] Simplify the mixin logic allowing only object
• [ ] Make the use of <script> and <style> obligatory
• [ ] Remove the shouldUpdate method
• [ ] Drop the use of each={ items } in favor of each={ item in items }
• [ ] Update the API simplifying the arguments overload issue for many riot methods

✌️

[gr0uch]

I'm excited to contribute to the next major version of Riot! One of our goals with this is to keep the number of breaking changes as few as possible, but we still want to remove stuff that should be deprecated or is too complicated to use. Also the introduction of a new rendering implementation should make Riot faster than any of the mainstream frontend frameworks out there.

[dharmax]

Good luck, fellows!
Riot is my favorite FE framework so far. Glad to see you are keeping it alive!

[millette]

I noticed you closed a couple of PR since they would break compatibility with v3. v4 isn't coming out any time soon, so I thought, maybe call this roadmap v5 and have a small interim v4 to include the PRs on yeild and such.

Thoughts?

[ShiMeiWo]

Do we have to use export default{} on v4?

[swimmerben]

great stuff although as a side note I think the "smarter DOM updates strategy" link is broken.

[alexssung]

Thanks for your great work. Riot may not have the hype of React or Vue, but it is my favorite front-end library and I'm glad to see you guys continuing to improve it every day.

[jpeter06]

Nice :-). I have been following riot since long and used in two projects
and very happy with the results. Glad to see this evolution.

Jpeter

El 8 ene. 2018 6:28 p. m., "Alex" [e-mail] escribió:

Thanks for your great work. Riot may not have the hype of React or Vue,
but it is my favorite front-end library and I'm glad to see you guys
continuing to improve it every day.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riot/riot/issues/2515#issuecomment-356035015, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABojfhx0-Zo6sqDrnEsD_dAPfvXR3pCNks5tIlBKgaJpZM4RVvUy
.

[toby-farley]

riot-observable is at the very core of how my applications work. Would I be able to use RxJS to keep that functionality? I use riot.js in part because there is no shadow DOM. Would it be an optional functionality or would it switch to shadow DOM only?

[jfbrennan]

Looking good, thanks for the update.

_My two cents:_ forget Shadow DOM and focus first on Custom Elements.

[sujeetbuddiga]

Riot.js is our favorite framework, we have used it to develop our MVP. We also plan to use Riot.js in our live app as well.
Hope the latest version remains simple as well without need of any extra tooling.

All the best to the team 😄 , going forward we also plan to contribute to the favorite Riot.js both in code and funds.

[damusix]

Nice! Can't wait to see how benchmarks match up to other frameworks 👍
Will there be a callback for when tags are mounted? EG:

riot.mount('*', () => { /* stuff... */ });

// or

riot.mount('*', { onMounted: () => { /* stuff... */ }});

I seem to always need to do something that depends on all tags mounted.

@toby-farley you can always import riot-observable and not have

[jonaspm]

Great news! Keep up the good work guys!

Riot.js has been very pleasing to use since version 2.x !

[ShiMeiWo]

Remove riot-observable in favor of callbacks lifecycle methods

I think that it means "Riot tags are no longer to be inherited from observable. But you can listen them via callbacks lifecycle methods." ... Is it right?

[jonaspm]

Make the use of in .tag files (as the old/new examples demonstrate in the original post?

Your second guess is right :)

[dharmax]

Question: would change detection now use Proxy and perhaps eliminate the need to call this.update ?

[GianlucaGuarini]

Question: would change detection now use Proxy and perhaps eliminate the need to call this.update ?

yes but without Proxies

Will riot continue to allow you to use riot.tag to register tags in pure JS? Or was this statement only directed towards the currently allowed behavior of omitting in .tag files (as the old/new examples demonstrate in the original post?

the new parser should be ready so you can check the specs from the readme file. In riot 4 the <script> tag will be mandatory to wrap our components javascript logic

[ShiMeiWo]

Question: Can I use <script src="my-tag.js"> or/and <style src="my-tag.css"> in my-tag.tag file like Vue.js @4?

[a-lion]

I recently started learning Riot.js and working on Andrew Van Slars excellent, but old, Riot.js videos.

I really like what I've seen from Riot.js. There's a big project I want to start, but I still have concerns. Since it is obvious from this roadmap that the team is still working hard to bring Riot.js to the next level, it would be good to see these concerns addressed (for example, "_x_ was a valid concern and here's how we are repairing it in version 4"; "While we understand _y_ may be a concern to some, because of _reason_ it is not a high priority for us").
(A) It seems that Riot.js have been present for some time, but has not gotten a lot of users. Why might that be?
(B) Would be nice to see the Riot "Cons" in this addressed - https://medium.com/tldr-tech/vue-js-vs-riot-6392807ce5e6

[gr0uch]

HI @a-lion,

A) There are not giant corporate sponsors like Facebook or Google so there is a lack of developers paid to work on this full-time and no budget for marketing, conferences, etc. and it doesn't have the name recognition to land jobs by putting it in your resume, whereas React will. Its popularity has less to do with merit than socioeconomic factors.
B) It seems that most of the Riot cons are about performance and API. Since the new compiler will turn Riot tags into bindings for the underlying rendering engine, it's performance will be roughly equivalent (really, really fast in the JS framework benchmark). There will be no need to call update nor use observables, it will Just Work™.

[dharmax]

Hi @daliwali , @a-lion
i would totally use riot for any size of project. And i did and was very happy with my choice.
i didn't run into any performance issues, btw.
i'd talk about one issue i encountered, in my current project: i currently using webpack 3 and typescript; there's a problem with the tag files source mapping - it is useless. It isn't much of a problem in a small project, because if you don't minimize/uglify there's no problem debugging the bundle-x.js .
Note that in a big project i wrote about a year ago, i used it under jspm as a bundler/package-manager and it was fine.
Would love to see this issue addressed and tested.

[a-lion]

• @daliwali
  Thank you for such a great answer!
  I knew that Riot didn't have any corporate sponsors, but didn't account for that to impact popularity quite as much as it appears to have. (But it totally makes sense)
  I particularly appreciate the JS framework benchmark link! I prefer empirical evidence whenever it's a viable option. Understanding that this is being built in hobby time, is there a timeline for v4's release? Is there even a git branch available for v4 development? (v2's name doesn't correspond, next is 154 commits behind and hasn't had a commit in over 6 months, & dev is even with master)

• @dharmax
  Thank you for sharing your experience! Hearing about positive experiences from someone who's got some hands-on experience definitely increases my confidence.
  Source mapping can definitely be important in larger apps. I'm not seeing any open issues for source mapping, did you ever file an issue about it?

[dharmax]

@a-lion as a matter of fact, i didn't open such an issue, because i don't know what to relate it to: webpack or riot. @GianlucaGuarini - can you advise?

[GianlucaGuarini]

@a-lion

is there a timeline for v4's release?

Riot 4 will likely not support IE9/10/11 so we have no hurry. Riot 3 is just fine and feature complete. Use it if you like it. Riot 4 will be released during this year (Summer?) but not anytime soon

is there even a git branch available for v4 development?

Riot is not a monorepo project our current focus was on writing a brandnew parser that looks great so far but I would like to test it better having 100% coverage.

@dharmax

the current riot compiler supports sourcemaps. Please open an issue if you need help this topic is the wrong place for your issues

[uptimestar]

Hi. As a users I have some suggestions, all related to being close to standards.

• Use HTML imports and templates with polyfills dynamically loaded if needed from public CDN. (the rest of the spec is a mess, those two work fine)
• Call it slots not yield.
• Suggest a dash in tag name as is standard.
• Give a flux example to data binding ( I use fluxify )
• Deprecate router, there are many. (I use Framework 7's router)
• Keep up with SSR with an example.
• Keep up with 'local' CSS/Sass/Style. Can you do variables from another Sass file?

Thanks for a great working lib in any case! Nothing is even close. Here is how I use it, 3 tags:

• https://github.com/appthings/jbake-mobile/tree/master/www/comps

On home page of that link, I build them to .js with gulp in that project and has video demo. Happy to test your new stuff and/or provide example app based on your specs so I help with an example tutorial. You current tutorial is a bit hard kitchen sink, I think just a simple: here is html before and here we put some dom in a tag.

Cheers, Vic

[jfbrennan]

What is the technical cost of supporting IE11?

IE11 can be and is used by Windows 7, 8, and 10 users. And, unfortunately, it will be supported by MS until they expire Windows 10 support in 2025.

Riot should 1) support IE11 until the community agrees the numbers are low enough to drop it or 2) make it polyfillable so the community can get support if needed.

[ShiMeiWo]

@jfbrennan
I suppose that Riot@4 needs es6-promise, proxy-polyfill and so on if we want to use @4 on IE11

[jfbrennan]

If IE11 can be guaranteed to work (with or without polyfills, I'd settle for polyfills if I had to) then Riot 4 will be a big success. Possibly _the_ best solution out there for doing UI components (at work we prototyped with 12 of them, so I've had good exposure).

If not, it will absolutely fail to get adoption and that would just be a real shame.

I loathe, despise, condemn, and in any way possible hate IE and every single version of it, but the reality is millions of people use IE11 and we need to be able to support them...at least for another 18-24 months is my estimate.

[tooolbox]

Excellent, great news!

First, I use Riot because of its dead-simple syntax that mirrors basic HTML and JS. I hope you stay faithful to that in v4, and I can still introduce this lib to my friends with the confidence that they'll be productive after reading only a page or two of documentation.

Second, someone commented that there's a million routers out there. When v4 comes out, if you decide to drop the router, it would be great to list your suggested routers in terms of what fits with the Riot design and philosophy the most.

Third, as covered in https://github.com/riot/riot/issues/2484, I would like to request a canonical state management solution--again, something that fits with the Riot design and philosophy. Minimally, having the hooks present to be able to use something like Vuex or Monx would be great.

[adrianmiu]

Is the file-size of any consideration in the development of v4?

[ShiMeiWo]

@adrianmiu
https://github.com/riot/riot/issues/2283#issuecomment-284549660
The file-size looks promising.

[jpodwys]

@ShiMeiWo @adrianmiu

I believe @GianlucaGuarini made that comment before he decided on simulacra. Just to temper your expectations, simulacra is ~5k, according to their own website. (The latest release is 4.7k GZIP + min.) While I anticipate riot 4 will be very small, I think it's safe to assume it will be ~6k and hopefully < 10k. Still tiny :)

[jpodwys]

@GianlucaGuarini BTW congratulations on making riot very simple to learn. Of all the front end component libraries I've used, it has the smallest learning curve.

[ShiMeiWo]

I wish Riot tags were more testable and @4 will support export statement at last. I hope that the exported functions are exposed to any test suites.

[GianlucaGuarini]

@ShiMeiWo that's the idea and the new riot parser is 99% ready ;) https://github.com/riot/parser/tree/dev

[matthewblott]

@ShiMeiWo yeah I've really had to hunt for a solution for testing, biggest issue for me.

[ShiMeiWo]

Can I ask about IE11?
I think it is reasonable that @4 drops the support of IE11, but there are some people using IE11 as we know. I want to know what will we need the polyfills to use @4 on IE11.

[GianlucaGuarini]

Ehy guys I have a few updates for you:

1. The new riot parser is stable and it seems to work perfectly
2. I am working on a brand new riot DOM module (riot-dom-bindings) heavily inspired to simulacra - I am really impressed by the performance gained by using this strategy.
3. Once the dom bindings will be complete and stable I will work on the new compiler to transform riot tags into dom bindings objects
4. Once the compiler will be ready I will finish everything creating the new riot public API

It's quite a lot of work and I am doing everything by myself alone without any help. I hope to find some new core contributors to help me speeding up the whole development process.

✌️

[ckcollab]

Thanks for all the hard work! @tooolbox mentioned they'd like some kind of RiotJS "canonical state management solution."

What is the RiotJS position on that? Currently in v3 I just use an observable to track state, what would be the preferred way to do that in v4?

[TheNavigateur]

I don't like the export default boilerplate. It should be implied. That's one of the beauties of riot.js so far compared with other frameworks - minimalistic & convention implied over unnecessarily repetitive configuration.

I have about 37 tag files in my project so far, and it'll likely become more, and I _don't_ want to have to add export default 37+ times when it's already working automatically as-is.

Otherwise the performance gains you're aiming for are noble and appreciated.

[dharmax]

i concur with @TheNavigateur; "export default" will hinder the elegance i like so much in riot.

[osv]

this is better

 onMount() {
        console.log('mounted!')
      },

than

 this.on('mount', function() {
    console.log('mounted!')
  })

But common, why we need export default?

[PierBover]

Congrats on joining forces with Simulacra! I will be eagerly waiting for Riot 4!

I've been using Vue and React for a couple of years now and I'm desperately looking to simplify the front end dev process.

I would like to request a canonical state management solution--again, something that fits with the Riot design and philosophy. Minimally, having the hooks present to be able to use something like Vuex or Monx would be great.

I imagine @tooolbox is referring to MobX (not Monx), and I agree. Any viable front end solution these days has to offer a router and a store for managing central state. After experiencing the tight integration Vue offers with its router and Vuex it's obvious this is the way to go IMO.

@GianlucaGuarini I don't have time to contribute with code, but I'd love to contribute working on the documentation.

[tooolbox]

@PierBover I was actually referring to Monx, because I "ported" it to work with Riot a little while back.

But yes, MobX is a far more popular option. 😄

[PierBover]

Is TypeScript support considered for v4?

[TheNavigateur]

TypeScript support would be amazing, with the following conventions:

my-tag

would create the class MyTag, so that static variables like:

static myVariable

inside the tag's script would be accessible globally like MyTag.myVariable

Otherwise, the this inside methods etc. would simply behave as expected (as they already do).

The code outside of methods could continue to behave like a constructor, as it currently does.

However I would like instance variables declarations outside methods to also be supported, e.g.:

car : Car

alongside statements like

this.car = new Car();

I'm not sure how feasible this is.

i.e. the script of

<my-tag>
   <script>
       car : Car
       this.car = new Car();
   </script>
</my-tag>

would automatically imply:

class MyTag {
    car : Car;
    constructor(){
        this.car = new Car();
    }
}

That's how I see it, anyway. Riot already supports method declarations, so I don't see why instance field declarations would be too much of a stretch.

[damusix]

@gianlucaguarini I can help. How can we get in touch?

[damusix]

I think providing a series of libraries maintained by riotjs core team and affiliates would be nice. Things such as router, state management , etc. I use Observable as state manager and it gets the job done (way simpler than redux, mobx, flux), but router I think can be improved.

Also, testing. Can you build something around JSDOM for simple tag testing? Cant seem to get it to mount correctly on an empty DOM. Id like to be able to run my tests inside an alpine docker container without needing chrome or phantomjs.

[GianlucaGuarini]

@damusix please check https://github.com/riot/riot/issues/2571#issuecomment-380924239 - I am currently still working on the dom-bindings expressions. I am making progress on it and I guess I will be soon ready to start working on the new compiler

[avimar]

Amazing work guys! Some things that would be cool:

• Onclick handlers, especially if I could pass args, like in moon:
  e.g. I currently have this code: <a onclick={switch.bind(null,'home')}> and it would be so much nicer to not have that clutter of .bind(null that I have to recall.

• Some sort of sugar for ref values? Once I have a ref to a form field I don't want to call this.refs.myField.value... although, you may want to do something else with it.

• Transition support built into loops: for animating added or removed elements. (It's not that hard to apply animations to tags.) I know, long discussion here: https://github.com/riot/riot/issues/1858

[GianlucaGuarini]

@avimar thanks for your feedback and congrats for moon. I will focus on less features for riot@4, I want to create an elegant piece of software that can be extended easily but that will not be bloated by default like many other libs.

For your first point, the arguments via event handlers, the new compiler should be able to handle it. Honestly at moment I have completely other priorities I will need to solve.

[TheNavigateur]

Default is absolutely critical to a "convention over configuration" interface, which is the cornerstone of why riot has been more attractive than other frameworks for a number of people.

If the philosophy of "default" is discarded (forcing the end user to always provide boilerplate, often repetitive) then I'm afraid riot's appeal would likely die altogether. I'm almost certain you don't want that to happen. If I'm right, then I'm pretty sure you would be eager try to honour the original philosophy (and hence original appeal) of riot.

[matthewblott]

I agree completely with @TheNavigateur. I'm a backend dev really who has limited experience with front end - exactly why Riot appeals. I see Riot as the 'Rails' of front ends (I really think you should sell it as this) - very easy to get started and be productive quickly.

[jfbrennan]

@GianlucaGuarini the Riot 4 project board looks a little sparse. Could the community help identify remaining v4 tickets and get those into the project and begin helping complete the work? I think there's a lot of demand for Riot 4 and it seems close to the finish line, but hard to tell. How can we help finish?

[jfbrennan]

Seems like there's some push back with the new export default requirement - yeah, I prefer not writing code too - but before we push back we should be asking what's the cost, e.g. How many kb are needed to make that requirement go away? What's the execution cost if Riot has to solve that? What about compilation time?, etc. I don't like the requirement, but I also don't mind such a tiny thing if it means I get a smaller, faster Riot.

[ShiMeiWo]

Perhaps, we can write this style too:

<my-component>
  <h1 if={ title }>{ title }</h1>
  <ul>
    <li onclick={ onClick } each={ item in items }>{ item.value }</li>
  </ul>

  <script>
    var goodbye = 'goodbye'
    var tag = {}

    tag.onMount = () => {
      console.log('mounted!')
    }
    tag.onClick = () => {
      this.title = goodbye
    }

    export default tag
  </script>

  <style>
    :root {
      color: red;
    }
  </style>
</my-component>

[TheNavigateur]

@jfbrennan What if it can be even smaller & faster without it? There's a slippery slope which I can preface by saying: there is a "dev" cost to optimize, as well as the load/execution time. That "dev" cost is the initial, and perhaps only prospective lasting, appeal of riot - and I think for very good reason: I would argue that a far bigger factor than fraction-of-second execution times, for both developers and end users, is time-to-complete features.

So I would argue that the approach should be to optimize the dev cost up front, then optimize the hell out of the framework to suit - it's unclear that you might even get a smaller & faster framework that way, and in any case probably far better than adding a dev cost up front based on assumption.

[jfbrennan]

That would be great. Is it?

[vinyll]

I'm getting to use Riot on some serious projects now and love its simplicity.
I do have some 2cents-suggestions, after considering others', comparing to what's available and showing this to other users:

• <yield from…> should be called <slot name…>
• Component HTML should (optionnaly?) be wrapped into a <template> tag
• Magic should be deprecated. opts explicitly this.opts, { text } explicitly { this.text }, each={ item in this.items }, onclick={ this.onClick }, this.onClick = (event) => {…
• <style> should be scoped only when <style scoped> is used

I'm really excited into the idea of a Riot v4, you've done an amazing work so far!

[Sam-Hepworth]

I am amazed by the purity of Riot and Simulacra. Well done! Vue has a concept for computed properties that I would like to propose as a candidate for the Riot roadmap. I have experimented with a different implementation of computed properties, but you can probably think of a much better one... http://dejongh.dk/wiki/doku.php?id=programming:functional_layout

[jfbrennan]

@GianlucaGuarini how's v4 going? Release date in sight? How can the community help?

[GianlucaGuarini]

@jfbrennan I am working on the new compiler but I am currently alone doing it in my spare time (I work full time). I am sorry I can't give you a date because there is still a huge amount of work to do.

That's what I have already done so far:

• new parser
• new dom-bindings
• setup for the new core

[drnkwati]

What is the technical cost of supporting IE11?

IE11 can be and is used by Windows 7, 8, and 10 users. And, unfortunately, it will be supported by MS until they expire Windows 10 support in 2025.

Riot should 1) support IE11 until the community agrees the numbers are low enough to drop it or 2) make it polyfillable so the community can get support if needed.

I totally agree here. I was even considering IE 10 should not be left out.

Bravo! riot developers for this awesome framework.
Thanks guys

[cekvenich]

I hope that riotJS 4 never happens - since I love riot 3. But fyi:
https://twitter.com/chriscoyier/status/1068565718571106304

[GianlucaGuarini]

I lock this thread because it got enough feedback from the community. I am hardly working on the new major release that will happen anytime during 2019. Stay tuned and thank you for your great ideas

[GianlucaGuarini]

Riot.js@4 was just released thank you for your feedback