Riot: Riot next - roadmap to v4

[GianlucaGuarini]

Roadmap proposal for the future riot major release:

(__this list just a draft and it's going to grow__)

• [ ] Complete rewrite of the compiler simplifying the sourcecode allowing also sourcemaps
• [ ] Fix all the yield issues introducing the use of <slot> deprecating the <yield>
• [ ] Make the use of riot-observable optional
• [ ] Remove this.tags from the tags instances in favor of ref https://github.com/riot/riot/issues/2360
• [ ] Automounted components deprecating the riot.mount method
• [ ] Add support for shadow DOM or at least support the :root selector instead of :scope
• [ ] Make the tags options explicit avoiding to pick per default all the custom tags attributes
• [ ] Avoid the use of riot.csp in favor of a simpler solution
• [ ] Cleanup the readme file removing dead links to tutorials or old riot stuff
• [ ] Simplify the mixin logic avoid the use of es6 classes and functions instances
• [ ] Remove the shouldUpdate method in favor of a smarter DOM updates strategy
• [ ] Drop IE9/10/11 support
• [ ] Use new ES6 features like Proxies and template strings
• [ ] Drop the use of each={ items } in favor of each={ item in items }
• [ ] Reduce the source code simplifying a lot the api
• [ ] Update the api simplifying the core methods arguments handling
• [ ] Prefer a functional approach over the current objects extension strategy

We will track the progress here

✌️

[sourcegr]

some more points to consider

• Introduce one-time computed parameters, that do not change across updates. This can be accomplished with something like {= parameter =} and could be computed right before the mount event.

<div data-is="my-tag" bgcolor="red" mytitle="this is my name" productprice="30"></div>

<my-tag>
  <div style="background-color:{= opts.bgcolor =}">
    <h2>Page title: {= opts.mytitle =}</h2>
    <p>Product Price (Including VAT): {= (opts.productprice * CONST_VAT_PERCENT).toFixed(2) =}</p>
  </div>
</my-tag>

It is obvious that a lot of re-computation could be avoided, resulting in much faster overall experience

see also #2144

[sourcegr]

• allow HTML to be inserted, by using some special syntax like {! unescaped !}.

I believe we should avoid the {{ unescaped }} format because {{ ... }} is used by many back-end templating engines, like laravel's blade.

[fabien]

I would like to see some rudimentary support for transitions/animation, in the form of deferrable/async (Promise based) control of mount and unmount (perhaps even update).

Something along these lines, perhaps:

willMount() {
  return Promise.delay(500)
}

willUnmount() {
  return Promise.delay(500)
}

willUpdate() {
  return Promise.delay(500)
}

[sourcegr]

@fabien could you elaborate on this a little more?

[fabien]

@papas-source I'll try ... is this more clear (at the expensive of being a bit contrived)?

function fetchData() {
  // Code to fetch data asynchrously
  return promise
}

function performTransition(transitionName) {
  // Promise is resolved once transition completes
  return promise
}

willMount() { // called after the root is mounted, but before the mount event is fired
  return fetchData().then(function(data) {
     this.data = data
     this.update()
  }).then(function() {
     return performTransition('fadeIn')
  })
}

willUnmount() {
  return performTransition('fadeOut')
}

willUpdate() { // called after shouldUpdate, but before update event fires
  return performTransition('slideOut') // hide before update
}

didUpdate() { // called after update (but before updated event is fired - will wait)
  return performTransition('slideIn') // show once fully updated & rendered
}

[jakubrpawlowski]

I like all the ideas and upcoming features Gianluca. Please do not forget that many of us choose Riot over Vue due to size-first approach. The day Riot grows over 14KB my dreams will be crushed. Thank you in advance for staying committed to minimalism!

[GianlucaGuarini]

@jakubrpawlowski actually my idea is to drop the size of the lib down to 3kb again but we will see I just need time to work on it stay tuned

[sourcegr]

And something else, that is actually on the @tipiirai list of new features, and is a must have. Actually, I believe that it will make Riot a trully magnificent tool for creating reusable components.

The <yield> tag should run on parent context where the code resides and can contain complex constructs like loops and custom tags.

[aggre]

I think that Shadow DOM is the optimal answer for component based UI.
By trying component development like Riot using HTML Template, I'm thinking about what is necessary for Riot.

It is like this:
https://jsbin.com/moviqek/edit?html,js,output

[davidtai]

Hi! Riot is shaping up great.

We've been using Riot or a long time in our
projects and have even built a framework on top
of it. An issue our team runs into (especially while integrating third party
widgets) is converting everything to use riot's synchronous updating scheme.
Not everything converts nicely so we usually end up pushing a lot of
unnecessary updates or having to hack our way out of infinite update loops (most off the shelf widgets from our experience don't play nice with riot).

In addition, having multiple sources of streaming data, ajax requests, or waiting for
promises (such as with animations) can cause performance issues when updating.

I'm wondering if anyone has thoughts one way or another about adding the
ability to support scheduling asynchronous batched updates like React setState and
Vue's nextTick?

[rbatistajs]

Please add custom directive/attribute.

[GianlucaGuarini]

@davidtai I am not sure about all your performance concerns since you are using riot@2 in your components. Have you tried upgrading? Riot@3 is about 5x faster than the previous releases

[rongxike]

how's about "requiretags" ? something like requirejs ?
a full heavily requirejs is not needed, but at least we can have something easier to reference the tag files.

Ex:

<script src='test1.html' type='riot/tag" ></script>
<script src='test2.html' type='riot/tag" ></script>
<script src='test3.html' type='riot/tag" ></script>
...

<test1 />
<test2 />
<test3 />

<script>
  riot.mount('*');
</script>

We can have

<test1 />
<test2 />
<test3 />
<script>
  riot.mount('*', {
     tags: ['test1.html', 'test2.html', 'test3.html']
  })
</script>

[Joylei]

@rongxike

it's already there: riot.compile()

riot.compile('SOME_URL', function(){
   riot.mount('*')
})

or multiple urls

riot.compile(['url1','url2','url3'], function(){
    riot.mount('*')
})

[jakubrpawlowski]

Not everyone is on Gitter so I will just repost here a link that @richardtallent mentioned:
https://medium.com/@WebReflection/hyperhtml-a-virtual-dom-alternative-279db455ee0e#.j7ea4ao27

[sourcegr]

@jakubrpawlowski it is allready in the todo list, see the first post by @GianlucaGuarini

;)

[richardtallent]

Everything sounds good, with one exception -- dropping IE11 support. I use Riot on an intranet application, and while all of my users have Chrome available, IE11 is their default browser, so I can't drop support for it. I'd hate to get left behind on v4.

In corporate environments, Windows 7 and 8 are still common and likely won't go away until 2020 and Edge is only available on Windows 10, so IE11 is as high as those environments can support.

If the concern is IE11's lack of ES6 features, please keep in mind that over 50% of mobile browsers are still Android Browser 4/5 and iOS 9, which also have minimal ES6 compatibility.

I do all of my tag compilation server-side, so feeding the output of gulp-riot to babel isn't a problem as long as the resulting javascript runs in IE11.

[jakubrpawlowski]

I hear you, but punishing users of modern browsers (especially the ones on mobile) isn't fair either. Best solution imo would be optional pluggable polyfill for projects that need to support fetchless browsers as seen here (tip 8): https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7#.19shthvx4

[davidhewitt]

Will the yield / slot scope be changing to the parent tag's scope? I see yield in point 2 on the list but it's not clear to me if the scope is determined an issue or not. :)

[sourcegr]

@davidhewitt this is labeled, discussion, so we are free to share our own views/thoughts for the upcoming release

As you can see I made a comment about that :)

Feel free to upvote for it - allthough there is no guaranties that upvoted comments will pass ;)

EDIT: I linked to one other comment, the link is fixed now

[davidhewitt]

Ah cheers I did scan the thread but failed to read the quote in our post. Upvoted!

[PascalLeMerrer]

Droppping IE11 support would be a big problem for me. I work for a big company which just dropped IE8 in favour of IE11 and FF, for internal applications. It was a big move, as there are hundreds of them. In fact it's not totally finished yet, and wont be before a few months. If Riot V4 does not offer any solution to support IE11, I won't be able to use it any more for my professional projects :(

[foximoxi]

How about some inheritance between tags (events, methods, variables)?

<parent>
<script>
doSth() { }
</script>
</parent>

<child::parent>
<script>
this.doSth();
</script>
</child::parent>

[GianlucaGuarini]

@PascalLeMerrer of course there will be ways to support ie11 but not in the riot core. I would like to make riot4 completely web components compliant providing a simpler API with some utils web components don't provide yet. I guess the new riot compiler will output kind of Custom Elements scripts

[planeguy]

@PascalLeMerrer @GianlucaGuarini I'm good with a standards-compliant riot as long as there's a good, clear way to polyfill for ie11 (I'm in the exact same boat as you Pascal). What stuff would we need to bring ie11 up to snuff for riot4?

[GianlucaGuarini]

I decided that the foundation for the new riot major release will be the compiler and I am working a new draft release https://github.com/riot/compiler/tree/next

[syuilo]

+1 for dropping IE 9/10/11 support,
If you need IE 9/10/11 support, you can continue to use riot v3.x.

[MartinMuzatko]

Our company already gave up on IE 9 and below.

[sourcegr]

I decided that the foundation for the new riot major release will be the compiler and I am working a new draft release https://github.com/riot/compiler/tree/next

@GianlucaGuarini , I dont know if you would take any comments on this, but I couldn't help but notice the tag syntax...

As I can see, it has nothing to do with the existing Riot style. It is more like vue's or ractive's or maybe some other library, and I believe it has little to do with "Enjoyable syntax"

Again, I might be running fast here, but is this a final decision? What are the reasons the old - trully enjoyable - syntax was abandoned? Isn't there something that can be done to bring the old syntax back?

Just my 2c here... Riot's simple and elegant syntax is one of its STRONG points and the main reason a new developer decides to use Riot. We lose that, and we are just one more react-like spin. But apart from this, I personally would not LOVE to code in Riot any more :(

[sourcegr]

Also, I couldn't help but notice that @tipiirai 's experimental branch where he actually tried to rewrite the core, is no longer available. I mean the spin you refered to on the 3.0.0 version release notes, on the "what comes next" section, with these words:

@tipiirai is working on a brand new riot release experimenting new rendering strategies and big core improvements that will be part of [email protected]

What happened to that spin?

Thanks for your time and I hope I am not interfearing or anything, but I just LOVE Riot very very much and I am really concerned about it!

[fabien]

@papas-source I share your opinion, but I believe @GianlucaGuarini is not planning to abandon the current syntax at all. The example given only shows the automatically compiled result of the input tag (which does have some less-enjoyable handlebars-like syntax in it IMHO). In other words, I think the compiler will spit out the (to us) ugly React-like syntax for us ;-)

[sourcegr]

but I believe @GianlucaGuarini is not planning to abandon the current syntax at all.

well I really hope this is the case :)

The example given only shows the automatically compiled result of the input tag

@fabien, actually it shows the tag syntax as well... In the example, it implements a mustache-like-syntax.

[fabien]

@papas-source yes, I spotted that mustache/handlebars syntax, which I agree, is very ugly indeed. I've played with Ractive JS (http://docs.ractivejs.org/latest/mustaches) in the past, but I never really liked its syntax either. RiotJS was a breath of fresh air in that regard, although I can see how this syntax might solve some of the <virtual> issues from the beginning.

If you'd ask me, these mustache-like constructs should be optional, and available for use whenever non (html) tag output is desired. Otherwise, I think the current syntax should definitely be preserved.

[sourcegr]

@fabien, before Riot, I was a Ractive guy also. Then Riot came and made our lifes here very simple and happy (I am talking as the head of a dev team).

The syntax with {# also solves oneother issue, the if/then/else issue. But I believe it is a non-issue since we never had such a case And we have developed A LOT of small to medium sized apps based on Riot... And when something similar was needed, finding a workaround was really simple end very well readable.

Anyway we are talking thin air here, until @GianlucaGuarini sheds some lights on his thoughts ;)

thanks!

[planeguy]

@papas-source yeah, if anything was too complex than a series of s i'd just use code to flag if something is visible or not. I dunno the full use case for the {#if s unless there's some gross {#elseif mess you want to write, but i'd look more how you got into a situation where you have to write an big ugly if-else statement in your template before changing riot.

[sourcegr]

@planeguy sorry, but I am not a fluent english speaker/reader and I really cannot understand in full what your comment is about - but I think you agree with me, correct?

[GianlucaGuarini]

no panic guys.. riot@4 will be not released anytime soon there is still a lot of work to do and I may change some stuff as well but I plan to support the current riot attributes except for the show/hide. So please don't pollute this topic and use it only for posting constructive feedback that might help me in this design phase.

The the @tipiirai's experimental branch was deleted because after discussing with him and explaining my concerns about his new code we have found to have 2 different approaches and ideas about the future of riot. I have offered him to decide whether he wanted to take the lead on the project letting me maintaining riot@3 until his new code was rolled out or to just give me the freedom to develop riot@4 from the scratch thanks to my 2 years of full time experience on this project. @tipiirai decided for the 2nd option so I will be happy to code riot@4 on the top of es6 features and standard webcomponents API. At this point @tipiirai will be still part of the riot organization but I don't think he will participate actively to the project.

I have a long way behind me to riot@4 and the other contributors seem to be really busy as well but I hope I can count on them during the rewrite. All I can say is to be patient, I want to give to riot@3 a long term support at least until the end of this year and I want to design riot@4 on solid foundations starting from the compiler.

✌️

[sourcegr]

@GianlucaGuarini, thanks for the information!

Let me start by saying that I find riot3 to be much faster / better than riot2 but unfortunatelly its base code is so complex that when we fix something, something else breaks. I noticed this in the course of time for the latest bugs. Giving riot@3 a long term support, allthough mostly humble and meritorious, IMHO, is like trying to cure a broken leg with bandaid strips. We need a major release that will support many of the features we need, mostly the raw and yield scoping issues, with a clean code base!

Yes, I absolutelly agree with you when you say

I want to design riot@4 on solid foundations starting from the compiler

Solid foundations is really something that we need in order to make a good release. But I cannot understand what you mean with solid foundations if you built it around the mustache syntax... You will change this later in order to support the each directive, and there are BIG differences that will need to be addressed... For example, The each is INSIDE the tag, but the mustache wrapper is outside... And IMHO this is not at all solid. We will need to change allmost all the reg. expressions for one thing! Add to that the fact that an if statement could also be present... I hope you see the point here!

Once again, it this is any kind of test code from you trying out the hyperHTML code, it is fine. But, as far as I am concerned, Riot should be far away from mustache syntax... :)

You also seem to talk a lot with "I"
I may change some stuff...
I plan to support the current riot attributes...
I have a long way behind me to riot@4
I want to give to riot@3 a long term support
I want to design riot@4 on solid foundations

but you are not alone, we are here to help you with code, ideas, feedback...
We only need you to tell us what you think and - why not - share your vision and ideas, we might as well help you with all of these. After all, we the users who actually USE RIOT TO DEVELOP REAL WORLD APPLICATIONS, are the most capable of helping you out both in ideas and features.

I would also like to make a stametent. Sharing our thoughts and concerns, IMHO, is, actually, constructive feedback and not pollution. I am really sorry you see it that way, but pollution is surrely something that was out of my scope when I posted my opinion and expressed my worries.

thanks for your attention.

EDIT: And forgive my lousy english :P

[MartinMuzatko]

Hello.

I want to share my thoughts about the current roadmap and design decisions for Riot 4.

Current learning-curve
What I loved most, starting from Riot 2, was that there was almost no extra brain load required to learn how to use Riot. I had the feeling I did not had to learn new things, just for the sake of the library. The knowledge acquired through learning Riot and its tools was able to be re-used even outside of Riot.

With the current changes to Riot 3, and the fundamental shift of these very well justified and IMHO good design decisions, the ease of use suffered a little.

However in Riot 4, things lighten up a little more, as it seems. I very much favor the move from each={items} to each={item in items}. Also with the rewrite of the yield/slot mechanism, I very much look forward to having it a little simpler again.

I don't know why riot-observable should be dropped as mandatory. Since it has always been a very fundamental part of custom tags. I'd love to hear more about this decision and how you are going to fill in the gaps to still allow a tag lifecycle.

Custom attributes(directives?)
As @rbatistajs has mentioned: Are there any plans to allow developers implementing their own directives or extract templating mechanisms such as if and each from the core?

This would allow more flexibility, since smaller functionality doesn't have to be wrapped into components. I haven't found any arguments against that so far, so it would be great to hear your personal standpoint regarding this request @GianlucaGuarini

As always: thank you a lot for putting so much heart into bringing Riot further.

[sourcegr]

@MartinMuzatko, @GianlucaGuarini
The "Custom attributes" feature was requested in the past too!

1707

+1 for that

[GianlucaGuarini]

@MartinMuzatko I don't think custom directives will be part of riot@4 because we can solve all the rendering issues we had before by writing our custom render functions. Of course custom render functions will be a feature, but you will still be able to use our compiler to output valid riot code with our default directives
For example

riot.define('my-title', {
  render(h) {
    return h`${ this.opts.isBig ? `
      <h1>${ this.title }</h1>
     `:`
      <h2>${ this.title }</h2>
   `}`
  }
})

Or for example:

riot.define('my-values-list', {
  render(h) {
   return h`
    <ul>
      ${ Object.values(this.opts.items).map(value => `
         <li>${ value }</li>
      `)}
    </ul>
    `
  }
})

[tipiirai]

I feel the Moustache- like syntax is not the right decision for Riot and causes users to look for other options. It's against the decision to pick Riot in the first place: the natural and minimal syntax. With the added template language Riot loses it's competitive edge and becomes like everyone else.

[GianlucaGuarini]

@tipiirai ditto

I may change some stuff as well but I plan to support the current riot attributes except for the show/hide

I will support the current riot attributes syntax but I don't want to support virtual tags for loops or conditions so text tokens for the parsers are needed but not mandatory.

I guess the compiler will work like this for example:

<template>
   <ul>
      <li each={item in items}>{item}</li>
   </ul>
</template>

Intermediate state generate by a pre-parser/optimizer (hidden to the end user)

<template>
   <ul>
      {#each item in items }
        <li>{item}</li>
      {/each}
   </ul>
</template>

Output

  `
   <ul>
     ${ items.map(item => { 
          return `<li>${ item }</li>`
      })}
   </ul>
`

[tipiirai]

Nice. That's cool!

And show/hide can go.

[GianlucaGuarini]

@tipiirai show/hide = hidden attribute

[tipiirai]

Even better

[tipiirai]

And the goal is to target browsers with ES6 support?

According to can i use, that's 73% of browsers. Not a concern?

[GianlucaGuarini]

riot will outupt es6 files and will be written in es6, I guess i will provide a transpiled es5 version as well but it's not on the top of my priorities. I don't want to support legacy browsers anyway and I would like to use only js standard web components apis like customElements.define for the legacy browsers our users could still use riot@3

[tipiirai]

As a developer I would also love to drop legacy browsers. New tech is fun.

But we should talk about Riot and how it aims to be better than the alternatives. 73% browser support is bad. No serious business will ignore 23% of their audience. It's a definite no to Riot and definite yes to React and others.

[GianlucaGuarini]

No serious business will ignore 23% of audience and it's a definite

no serious business will keep using software that allows such vulnerabilities https://github.com/riot/riot/issues/2315 Strings runtime evaluation is not the right way to go this is mainly my main concern for now.

For all the rest polyfills and transpilers are more than enough

[tipiirai]

customElements.define: 58.33% of browsers.

[tipiirai]

Sure. XSS vulnerabilities are as critical as browser support. I think Riot should have the same support for browsers than the competition, which is IE9 and above.

If polyfills and transpilers do the job then good, but they should be part of the offering and the test suite if browser coverage is a priority.

[GianlucaGuarini]

@tipiirai if this component works on your browser riot@4 will do (webcomponents-lite)

[tipiirai]

It works. So the plan is to bundle webcomponents-lite inside Riot and include legacy browsers on the test suite?

[tipiirai]

For the record: webcomponents-lite is 80K when minified.

[GianlucaGuarini]

Even if it's not our job to tell our users what browser to support and how by bundling webcomponents-lite in a riot.legacy.js version seems to be a cool idea though i need to check it out

[tipiirai]

It is our job to tell our users what browsers are supported by Riot.

And seems most users will have to use the 100KB riot.legacy.js.

[GianlucaGuarini]

@tipiirai as i said before riot@4 will be not out in less than a year. Until then the browsers support for web components will be higher. I want to rely on the web components APIs providing a lighter and simpler alternative to polymer. This is my plan for now I might change many stuff during this process and I still need to test what's the best way to achieve my goals. @tipiirai many thanks for your feedback I will keep you updated here regarding the progress of my work once we will have something concrete to test

[GianlucaGuarini]

@tipiirai course as I already told you in private, if you don't like my approach I could leave you the lead on the new riot@4 version and I will only support riot@3 as long as it must be supported.

[tipiirai]

I'm asking these questions because I want to know what your approach actually is. Now I know a lot more about it: like Mustache syntax being invisible to the users. This sounds like a sane approach and hyperHTML virtual DOM seems very compact and functional.

Then I started asking about browser support, which is crucial feature for a UI library. Just like XSS vulnerabilities, like you mentioned. Now I understand that your approach is to include a polyfill inside Riot.

My wild guess is that everyone will need to use the heavy riot.legacy.js version, even after a year.

[jakubrpawlowski]

And seems most users will have to use the 100KB riot.legacy.js

All IE users will have to use it and yes that's the normal approach. Modern browser and mobile users will be rewarded with micro framework.
Guys, really, most of you make your users download jquerry and other bloatware and it's no issue but when we have finally opportunity to make a solid compact, minimalistic, mobile friendly project you start complaining.

I personally love Gianlucas vision and he has my full support.

[tipiirai]

I would design things differently, but I'm keeping my thoughts inside since I'm not in the lead. I let Gianluca host the project and really wish the new version can see the daylight some day, including full test suite for legacy browsers too.

What really concerns me are these passive/agressive and sometimes directly agressive comments on this community. It feels that there is no room for real discussion and technical debate here or you will be "punished" in some way. This will definitely kill Riot eventually.

[fabien]

While I have nothing against progress, and embracing native webcomponents in particular (it's something I'd really love to see!), I share some of the concerns @tipiirai raises.

I think @GianlucaGuarini has been doing a fantastic job, but it worries me a bit that he's practically the only one who knows all the ins-and-outs of Riot, especially the internals. I'd rather see a small core team cooperate on it, but for some reason that hasn't materialized.

I also applaud @GianlucaGuarini 's efforts in quickly fixing any bugs that have been popping up along the way. However, I sense hints of a fragile codebase lately, as seemingly small fixes on one front, increasingly introduce other side-effects. Perhaps this is just my impression though.

[sourcegr]

I will have to agree on everything @fabien said above, as you can clearly see in my previous comments on this thread.

Espesially the fragile codebase is a real problem and I am really concerned about the @3 branch and the future for it...

Let me share our milestone. We use riot in production in many-many projects, especially inside VPNs of globally respected companies. We really CANNOT AFFORD the apearance of bugs out of the blue! And actually, it is personal. I made the decision our team to work with riot, and right now, I am REALLY REALLY worried as to what the future holds. I am REALLY REALLY afraid that someone will find a bug in our code that has to do with riot, and I am REALLY SCARED that we will have to upgrade to a newer riot version, waiting for new bugs to show up!

Additionally, I too have the feeling, just like @tipiirai commented, that there is no room for real discussion or debate, since it looks like riot is now a one-man-show, and the attitude is regreatfully something like "take it or leave it". And this is something that made me really really unhappy :(

[GianlucaGuarini]

I will in future ignore these kind of sterile discussions and focus more on the project. Of course the riot community input on the api/bugs/improvements are always welcome but I don't accept critics on my behavior and/or on the way I am managing this project. The riot community is not aware of discussions/chats happened in private and it shouldn't either so so please stop being concerned about the stuff out of your business.

What's important now is to make an awesome riot@4 release and for this I need time and eventually donations (current amount 0$)

For the ones feeling not comfortable with this project I remember that there are tons of frontend frameworks out there and you can pick the one fits better to you (or your company) and/or has the friendliest maintainer

For all the others desiring a different project maintenance and the switch of the project lead back to @tipiirai please open a new issue and start the discussion there.

✌️

[sourcegr]

I need time and eventually donations

This is really funny, I once remember an issue where you said that money is not the issue at all, that you dont need money, but time. And of course, time will allways be an issue, if you decide to be cryptic, not share your thoughts and ideas and thus do it all by yourself; what you say about donations is just an excuse.

riot community is not aware of discussions/chats happened in private

I dont undersand what you mean with this, I for once had never a private discussion with you, and I believe it is irrelevant with the issue we are talking about here,. We ae raising concerns about

1. What the status of current Riot is (buggy, sloppy, with a spaggeti codebase)
2. What the future holds for Riot (unknown, only you know it)
3. How we feel as parts of this community. (well explained by me but I believe I am not the only one feeling that way)

For the ones feeling not comfortable with this project ... etc etc tec ... friendliest maintainer

You just confirm all the fears I expressed in my previous reply.

Nice job killing Riot @GianlucaGuarini

PS: What is pretty obvious, to me at least, is that you really have a thing with tipiraii. Nobody asked him to take the lead, nobody even proposed this! We just asked some things about the future internals and we got no answers but generic talk. Then. tipiraii shows up, asks a few questions, and there we have it, all explained...

[richardtallent]

I understand the frustration of disagreeing with what a library maintainer has planned, or not having enough understanding of what they want to do. I disagreed with the decision to move to web components (see above), even though I love the idea of web components.

But there are two important (and wonderful) rules of open source:

1. The maintainers don't work for the users. Gianluca is free to develop Riot however he wishes, he owes nothing to me or anyone else. Same with Tero and other contributors.

2. If you don't like the direction of a project and can't convince the maintainers, you're free to fork the code and do what you want, no hard feelings. We only need to collaborate to the degree that doing so is a net benefit to everyone.

If enough Riot users, like me, can't make the leap to v4 so soon, I hope some of them will band together and create a fork to continue to improve Riot 3, perhaps under a different name, leaving @GianlucaGuarini and others the freedom to focus on modern browsers.

Ideally, if that happened, it would be nice if they largely shared the same syntax (like React, Preact, and Inferno), so developers can move from one to the other as their needs change.

I don't have the bandwidth to help keep such a fork going, so I migrated to Vue.js. A bit tougher than Riot to learn (though still far easier than Angular), but it was the right move for me since I was a relatively new Riot user and only had about a dozen components to migrate. That said, I'll always be grateful to the Riot developers for creating such an easy to use library.

[sourcegr]

absolutelly agree.

but Riot has evolved to something greater than a personal project.

The head team is not a team, rather just one person that makes decissions
for Riot, without even accepting any kind of feedback or help even
suggestions from the community.

It would be better if the project did not split to different branches, and
I peraonally see no reason for this to happen. The team must need to
collaborate more but I am not sure this will happen.

Anyway, I hope for the best and wish the best.

The main concern, not for me personally (since the decission to migrate is
taken after this thread) but for Riot as a system, should be the timeline.
In one year - when he says it will be ready- given the @3 problems and
pitfalls and the rate javascript evolves , Riot will have to start building
its user base over again.

And let me take a wild guess, since everyone will have to use the legacy
version just to be compatible with IE, it will fail. All these newage
javascript developers, really have no idea on how much penetration this
trashbrowser has. Almost all corporate environments where they have a MS
backend, like sharepoint for example are practically forced to use IE.

[fabien]

Reading back through the whole thread once again, there's a few things apparent to me:

1. everyone part of this thread, or the community in general, wishes the best possible future for Riot, be it for professional ties or personal reasons, we all want Riot to succeed and evolve. If we had any interest in using any of the other frameworks out there, given how many there are, we would not have such a passionate discussion at all. It's precisely _because_ we care. I think it's hard to dismiss this core principle, and the reason why we are here expressing our concerns.

Jumping ship or forking away is not the solution we're after, nor something anyone has been talking about until things got heated eventually.

I, for one, am not giving up after this, and I think it would be foolish to let this escalate even further, despite the truth in anyone's reasoning.

1. as I expressed before, I'm very thankful for all the contributions made, and there's no denying that @GianlucaGuarini has been working extremely hard to keep us happy, and I think he holds his responsibilities high (often working on weekends to get a new version out).

But it's a delicate balance to maintain, partly because it all points back to him right now, with seemingly little benefit, despite all efforts. On the surface it might even appear that it's only fixes and critique (geared towards one person), instead of smooth-sailing and enjoyment - which is what Riot is all about, let's not forget.

A situation that is ultimately stressful for him, as well as us. I think the real discussion should be about how we can improve this situation, perhaps momentarily less about the technical details of how to implement v4.

Raising an issue, finding a bug or commenting on a project's future - those are all valuable contributions as well. A project is probably more about the community than the actual technology, just as much as we hope to empower people with the work we deliver based on it.

I care much more for a stable v3 release than any big leaps into the future of the web. This is something that ideally should happen in parallel, to cater for both the _present_ and the _future_ of Riot.

Which brings me to my last observation, after re-reading https://github.com/riot/riot/issues/2283#issuecomment-290472402 with the follow-up context and @tipiirai 's involvement in mind:

1. in hindsight, it's clear that there has been a discussion in private about this, and it's only now surfacing that this did not lead to a satisfying path forward for those involved.

When I take this statement:

I have offered him to decide whether he wanted to take the lead on the project letting me maintaining riot@3 until his new code was rolled out or to just give me the freedom to develop riot@4 from the scratch thanks to my 2 years of full time experience on this project.

it appears to me that we could have had such a parallel development and at least 2 people working on this project. Since v4 was more or less a clean-slate implementation of the concepts we care about in Riot, but taking the continually evolving JS landscape into account, it could very well be executed by other members of the project, and @tipiirai would've been a fitting candidate then.

@GianlucaGuarini 's 2 years of experience would have equally been of high importance, perhaps even more so, while maintaining riot@3 until we all feel comfortable using it without any hesitations.

With less stress on the day-to-day operations front (both for him, as well as us using Riot for our projects), I think v4 would stand a much better chance.

There's no doubt that working with shiny new technology is much more fun and brings many benefits, but I think we should not get ahead of ourselves unless we sort out the higher-level issues first.

[joepie91]

Hm. How will the auto-mounting work? I'm currently using riot.mount in a custom router implementation for mounting view components on-the-fly:

// ...

switchView: function(viewName, locals) {
    if (this.currentView != null) {
        this.currentView.unmount();
    }

    let viewElementName = `${this.viewPrefix}-${viewName}`;
    let newViewElement = $(`<${viewElementName}>`).appendTo(this.root);

    this.currentView = riot.mount(newViewElement[0], viewElementName, locals)[0];
    this.trigger("switched");
},

// ...

How would I implement this if riot.mount were to be removed?

[tipiirai]

I just wish I had time to run Riot since it's going to die with this attitude. I can see people leaving. Someone would have to listen to the users and their problems. There is no other way.

[planeguy]

@joepie91 We have a similar set up... would this suit your needs?

<div data-is="{viewElementName}" locals="{locals}"></div>

_edit: more useful_
your function would change the values on your state manager (if you have one) and then an update would get called in the riot component that houses your switching page

[damusix]

How about a callback, or an event after every tag has mounted?

riot.mount('*', (tags) => { /* Something to do */ })

or

riot.mount('*');
riot.on('tags-mounted', (tags) => {
    /* Something to do */
})

[dharmax]

Another proposal:
Support of "feature directives" - "tags" which aren't html tag, but mounted by arbitrary selectors. The tag-file should have an attribute "selector" in its encapsulating tag, and the riot.mount('*') will use it, if it was specified, instead of the tag name.

Example:

[JosephScript]

IE 11 is still supported by Microsoft and has no End of Support proposed yet. I would suggest maintaining IE 11 compatibility until it is dropped. It still has a large share of web browsers (more than Edge) https://www.w3counter.com/globalstats.php

Other than that, I am all for dropping IE 10 or lower!

[damusix]

@NukaPunk That's something Babel and Browserify can easily resolve. I don't see dropping IE11 for CommonJS / ES6 being a problem. From what I've tested, I have RiotJS working on all browsers IE9+. Wrote this a couple months ago specifically to address those issues: https://github.com/damusix/riot-grunt-boilerplate

[damusix]

@GianlucaGuarini I believe "DOM update event hooks" issue #2340 might be relevant here.

[JosephScript]

@damusix I also use Bable and Bublé for ES2015 compatibility, but I still think that riot at it's core should support all major browsers without running it through a transpiler. I'm curious, what are the benefits to dropping a commonly supported browser other than using some ES2015 features and shifting the burden to the end consumers of the library? Is it worth it?

[irisjae]

@davidtai However we could write your own function to batch together updates into requestAnimationFrame. That's my solution to the problem.

[davidtai]

@irisjay yes, we have built several higher level abstractions on top of riot including RAF scheduling.

[senica]

Is there any consideration of a way to give the developer a way to signify whether to update children tags or not? I have found often that I may have several nested children tags (perhaps as hidden menus) that do not need updated regularly (even if their data has changed). When the parent performs an event to open the menu, only then does it need updated. Here's a rudimentary example.

<parent>
  <button onclick="openChild"></button>
  <child updateOn={childIsOpen} data={<some data here>}></child>
  <script>
    this.childIsOpen = false
    openChild = ()=>{
      this.childIsOpen = true
      // this even handler will then update the child
    }
  </script>
</parent>

Even if the parent changes the child's data, or it's own data that would normally cause the children to be updated, this would just ignore the update if the updateOn did not evaluate to true.

I think this is the idea of shouldUpdate (which if I read correctly is being done away with), but that expects the children to know what's going on with the parent.

One more note here: generally you would just use if if you did not want your children to be evaluated. So, my use case may be pretty specific to my use-case where the child may do some server requests on mount, but I just don't want it continually updated on a long-running web-app.

[puppetmaster3]

Huge mistake to drop major browser ie11. It has major market share in general, and especially enterprise. Also it gains you nothing and lose a lot.

[puppetmaster3]

Separate tale I'd like to share in case it helps someone. I wanted to submit to webcomponents.org, they said it must be standard.
I love how in RIOT and Poly you don't need tooling or build things, and I tried hard to get standard components v1 to work w/ ie 11 via babel (as a pug filter). No joy of easy way of doing it.
I wasted much time.
Then I solved it:
bower install Polymer/polymer#^1.0.0
(remove polymer folder, leave web comps). The 'older' version of standard web components works fine w/ ie 11. No build steps needed. Once IE 11 drops < 1% of market share, easy step to upgrade to newer version. And all DOM based, no .js mess.
hth.

[GianlucaGuarini]

Hi everyone I just would like to give you some updates on this topic.
I am really glad of your feedback and I will treasure it.

We had 2 very productive calls during the last weeks where we discussed on how proceeding with the new version. Here I will recap our decisions:

• We will not use the {#if}{/if} {#each}{/each} syntax in favor of <if value={ foo }></if> <each value={ item in items }></each> that should be easier to parse with the current new parser
• The <script> tag inside riot components will be mandatory, so no more js mixed to html
• The current riot directives will be still supported (except for show/hide) and the riot components syntax will be still the same: <my-tag>HTML<script>JS</script><style>CSS</style></my-tag>
• The conditional and each statements will be not handled in runtime by riot (like for the current virtual) but by the riot-compiler instead
• The new parser needs more tests, documentation and benchmarks
• The new riot-compiler will be async and will be completely rewritten
• The compiler must returns only a plain object with { html, css, js, expressions, meta }. meta can contains the url and options passed to the compiler and/or the imports.
• The riot-parser will be responsible for throwing the syntax errors
• The riot-compiler will be responsible for throwing the semantic errors
• We will generate sourcemaps!!!
• We agreed about the export default {} statement to expose the tag logic to riot
• We will rename :scope to :host for the scoped css
• The current riot dirty checking rendering is too slow we will investigate new rendering strategies that we will decide later (once the compiler and the parser will be kind of stable):
  
  
  
  • I would like to try https://github.com/WebReflection/hyperHTML
  
  
  • Alberto proposed http://google.github.io/incremental-dom/#about or https://github.com/davidjamesstone/superviews.js
  
  

Todo list - phases

1st phase

• I will collaborate with @aMarCruz on the parser
• Alberto will push some patches to the current new parser in the next few weeks (to handle at least the <div if={} >, <div each={}>, <if> <each> and export default {} nodes) informing me when I can code review it and help him on it
• I will investigate about what’s the best rendering procedure experimenting with the libraries linked above
• The new riot compiler will be rewritten once the parser will be ready, even if @aMarCruz has started working already on it

2nd phase

• Create a new rendering strategy combining the results of using the compiler output
• Rewrite riot reducing its core API to the minimum implementing a new register method to create new components
• Test whether we will use the native webcomponents API vs custom mounting methods

3rd phase

• Update the unit test
• Implement a good serverside rendering strategy allowing also templates re-hydrates
• Update all the riot ecosystem in order to let it work with v4

We didn't schedule any range of time but it will be a tough work but we will ping you as soon as we will have something ready to test

[nodefish]

The conditional and each statements will be not handled in runtime by riot (like for the current virtual) but by the riot-compiler instead

Can you elaborate on this? I'm not sure I get it: wouldn't each no longer work for dynamic lists if it's done at compile time?

[aMarCruz]

@nodefish , we are talking about JavaScript right?

so, think in this fragment:

   ...
   <each expr="value, keyIndex in data.target">
     <tag>...</tag>
     ...more tags
  </each>

in JS you iterate arrays like this:

   render(data) {
     ...
     data.target.forEach((value, index, array) => {
       riot._render.tag(...)
       ... more tags
     })
   }

and objects:

   render(data) {
     ...
     riot._each(data.target, (value, key, object) => {
       riot._render.tag(...)
       ... more tags
     })
   }

now, merge both:

   render(data) {
     ...
     (data.target.forEach || riot._each(data.target))( (value, keyIndex, target) => {
       riot._render.tag(...)
       ... more tags
     })
   }

Here data.target is a fixed expression, of course, but data.target is _mutable_ and linked to the Tag instance. I think this is beauty, simple, and performant.

[nodefish]

Got it now, thanks. 👍

I had actually misunderstood what was being referred to (I didn't realize he was talking about the internal implementation of each).

[aMarCruz]

The same goes for the current <tag each="expr">, think about <each></each> as a sort like <virtual each="expr">

[GianlucaGuarini]

@aMarCruz the more I am playing with hyperHTML the more I like it for its simplicity. I guess the new riot compiler in the end will output just html strings mixed with some helper functions to handle the dynamic DOM changes for example check this example

[aMarCruz]

@GianlucaGuarini , hyperHTML looks easy but reading the (Caveats)[https://github.com/WebReflection/hyperHTML#caveats] I gess this have some of the Riot drawbacks, because the DOM diffing.

Many of this drawbacks can be solved by our riot-parser but I'm not sure if hyperHTML is SSR capable:

You have a hyperHTML function that is suitable for parsing template literals but it needs a DOM node context to operate.

Anyway, if riot._render (you name it) is isolated and exposes an interface that accepts "VTags" only, it can generate VNoves, hyperHTML nodes, HTML markup, or whatever, so we can experiment with more than one engine with little effort.

EDIT:
Ideally, the compiler should emit source code (ES5) that does not depend on transpilers or interpreters.
This code will need to be loaded in the same way as riot.tag2 is currently loaded.

Once loaded, the code will register an object (class or prototype) that the Riot runtime can instantiate, with methods to update its state and render the template.

The render method should call to the helper (riot._render) in the Riot runtime with enough information (standardized) for this helper to construct the objects required by the engine that we choice and pass them.

[GianlucaGuarini]

@aMarCruz we can do also SSR @WebReflection has already thought about everything 😄

[aMarCruz]

@GianlucaGuarini , it goes better :+1:

[fernandogmar]

Hi guys,

I met Riot on version 2 that was love at first sight. Easy to learn, simple to write, fast and small. All my wishes came true!

I am kind of dumb coding... I need multiple points for going from the point A to the point B...

My thoughts in case it helps you:

• I love those systems thought for humans instead of machines. I mean we could still code on binary it would be very fast for machines to execute it! :joy:
• No idea about what exactly you meant about automounted... but I like the kind of control with the mount function I found on Riot. I can set where and when I want to mount what.
• I would also like to have that kind of control on rendering/mounting with a 'shallowRender' or similar https://github.com/riot/riot/issues/2382 (for unit testing). Also love the idea of rendering on both environments https://github.com/WebReflection/viperHTML
• Parent.parent.parent yield 'issue' is a bit ugly... It looks like you are trying to fix it. Thanks!

Let me know if I can help!

After all don't forget having fun doing amazing things!

A big hugh! Un fuerte abrazo!

[nodefish]

Have you guys considered ahead-of-time compilation like svelte.js? Basically svelte outputs minimal self-sufficient vanilla JS and removes itself at build time, so it adds almost no runtime abstractions. Performance-wise this approach seems to be among the best: http://www.stefankrause.net/js-frameworks-benchmark6/webdriver-ts-results/table.html

And you can distribute svelte components with no dependencies.

[aMarCruz]

I was playing with Svelte a few days ago, but there's no way to link Riot with this one.

[irisjae]

For something to build upon, one of the most amazing (aka, functional, performant, and elegant) libraries would be https://github.com/adamhaile/S and https://github.com/adamhaile/surplus . In nodefish's link to the benchmark you can also see how nice it is. Take a look? @aMarCruz

[StarpTech]

I like it that the RiotJs make progress continuesly but I don't understand the decision to drop a major browser IE. What's the reason about that? The support should rely on the usage statistic e.g https://www.w3counter.com/globalstats.php

[GianlucaGuarini]

@StarpTech discussing about browsers support when we don't have released either a pre pre pre alpha release of our new rewrite is worthless. Please let's wait until we will have something concrete to test ;)

[icetbr]

Hi, I'm just a bystander in the JS frameworks arena since I haven't coded front end JS in a while, but here some thoughts regarding mostly aesthetics I guess.

I think this is how a v4 tag is going to look like

<tag>

  <myTag onclick={doStuff}></myTag>

  <script>

  import myTag from 'myTag.tag'

  export default {

    doStuff() {
    }   

  }

  </script>

</tag>

This is how a JS first approach might look like. And if you use ${} as delimiters, you get auto IDE integration (syntax highlight is easy to get, some IDEs have language injections by default)

import myTag from 'myTag.tag'

export default {

  template: `
    <myTag onclick={doStuff}></myTag>
  `,

    doStuff() {
    }   

}

And here it is in markojs (components are auto discovered, no import required)

<myTag onclick=('doStuff')></myTag>

class {

    doStuff() {        
    }

}

[nodefish]

FYI it appears one of the big limitations of HyperHTML is reordering. I don't trust browsers to do competent diffing on huge lists if you change the order of the items. This is one area that riot v4 would need to handle in a custom way. I could be wrong, but I don't think HyperHTML does "smart" diffing of lists (as it's focused on pushing template literals to the DOM and lets the browser handle it).

edit: Or not! It seems hyperHTML.wire may in fact take care of list item tracking/reordering: https://github.com/WebReflection/hyperHTML/blob/master/GETTING_STARTED.md#rendering-multiple-nodes.

Also: @GianlucaGuarini @aMarCruz This might be interesting: https://github.com/joshgillies/hypercomponent

[joshgillies]

@nodefish I was actually going to ask what the issue was you were seeing with reordering. But it seems like you've uncovered the secret sauce since originally posting the above! Hint: hyperHTML.wire. :)

Fact is if you manage your wires correctly you get node reuse for free, so as far as I'm concerned reordering becomes a non-issue.

With regard to hypercomponent I'm really close to publishing v3 which implements a class based API - https://github.com/joshgillies/hypercomponent/tree/v3

[aMarCruz]

ES6TL are excellent for a generic use, but they are very limitated for things like

<div attr={ a > 1 ? `foo${a}` : 'bar' }/>

The riot parser is the base that can handle this and is (almost) already done.

I'm now working on a "render" builder and a fork of hyperHTML v0.15.2 (ported to TypeScript) that will allow to emit HTML based in markers (like {= "<p/>" }) instead of the surrounding context.

All this will be part of a completely new codebase with a simpler API and more oriented towards the compilation (lighter runtime) which should give us a much better performance.

Regarding the low-level engine for the rendering I don't now... maybe I'll experiment with Inferno or snabbdom or some other framework yet, but the idea is performance w/ security and stability, keeping the riot syntax as much as possible.

This is a lot of work and time (we are all volunteers :)), but we are already on the way.

[nodefish]

@aMarCruz You can do nested template literals with Outer ${Inner} so it's not necessarily a problem if you wrap everything in a template literal. So your example in hyperHTML style would be

render`<div attr=${ a > 1 ? `foo${a}` : 'bar' } />`

Of course that's different from the riot style (which I personally prefer). Honestly I think using a pre-existing rendering backend is a smart decision at this point. The JavaScript ecosystem has way too many people rolling their own things.

[aMarCruz]

@nodefish actually, the code emitted for the previous fragment with my working "compiler" is something like this:

render: function (state) {
  riot.__$render(
    [
      ['<div attr="',  '"></div>'],
      riot.__$toStr( state.a > 1 ? 'foo' + state.a : 'bar' )
    ]
  )
}

where riot is a small runtime for tests, riot.__$render is hyperHTML, and riot.__$toStr is a guard for falsy output

So yes, it is possible to use ES6 TL, but I think the new parser is more convenient.

[WebReflection]

riot.__$render is hyperHTML

nope, nopity nope.

If I read that correctly, ['<div attr="', '"></div>'] is always different from ['<div attr="', '"></div>'] which is the main strength of hyperHTML, the bit not everyone understood.

Following the ABC behind hyperHTML

let previous;
function tag(chunks) {
  if (!previous) previous = chunks;
  console.log(previous === chunks);
}

tag`<div attr=${1}></div>`; // true
tag`<div attr=${2}></div>`; // true

[WebReflection]

Moreover, in hyperHTML this works already:

render`<div attr="${ a > 1 ? `foo${a}` : 'bar' }"></div>`;

Not a single issue, you just need to follow the 2.5 rules of hyperHTML. In this case: attributes in quotes, that's literally it!

[WebReflection]

[aMarCruz]

@WebReflection thanks for your excelent work and support.
I understand the comparisson of statics is by reference (by hash for FF), in the final version of riot v4 it must be cached in the Tag instances.

Regarding the above rules the riot compiler will emit what is necessary for hyperHTML to work as intended given the riot _own rules_ (quoting unquoted attributes values, expanding selfclosing tags, and so on).

In riot 3, all expressions generate raw text or values, not HTML. In v4 the expressions will generate text (textContent) or HTML (maybe other custom tag instances identified by the data-is property).

So, to allow expressions as text as unique content of an element, the compiler will append an space to the static part: <p>{ expr }</p> => [ ["<p>", " </p>"], expr ].

For expressions generating HTML a prefix is required (ex: =).
To allow mixed text and html expressions we need to pass all to hyperHTML as a single value, sanitizing text expressions before the innerHTML injection: <p>Title: {text} - {= html }</p> => [ ["<p>", "</p>"], "Title: " + sanitize(text) + " - " + html ].

Maybe I'm wrong on some concepts, I'm very new to hyperHTML and the compiler is WIP. Right now I'm focused on the JS part and I have not started the complete tests, but would be very happy to have your support in the implementation of the engine (maybe by email or slack).

[WebReflection]

I'd be happy to help but it looks like you're implementing a JSX transformer ...or something similar. @kentaromiura already worked on something similar, maybe he can help too.

[aMarCruz]

@WebReflection yep, we can see the riot compiler as something like that :) Thanks.

[babakness]

I'm the first guy out there to say IE sucks. But IE11 is like 12% global market share as it was shipped with Windows 10.

[aMarCruz]

@babakness ,
bad thing to have to support the only browser without basic ES6, but I agree and the use of IE11 is too high to ignore it, especially in companies that still use Win7.

[kazzkiq]

In my experience, companies that have IE11-enabled systems are those open about which browser their employees use. Most of the issues remain in IE8/WinXP/Vista/7 from companies who are stuck in time (which make a big chunk of corporative market, sadly).

[sourcegr]

You can use the :scope pseudoclass

<my-tag>
  <h1>Hi!</h1>
  <style>
    :scope {display:block; background:red; width:33%};
    h1 {color:#00f;}
  </style>
</my-tag>

example

[nodefish]

OK, now I feel stupid. I wasn't aware of that. Thanks!

[sourcegr]

@nodefish, no worries!!! It happens to me every day!

[coffeebite]

I'd like to propose lazy/asynchronous component loading and mounting. E.g. I have a tag called my-settings. Users don't change their settings often so it is not rendered most of the time. But I have to download and compile it nonetheless in case it is shown.

I'd like a system where, upon the first instance of <my-settings> in the DOM, riot can request the component definition from a predefined URL and mount it on demand.

[WebReflection]

But I have to download and compile it nonetheless in case it is shown.

This is not true with hyperHTML because it supports asynchronous chunks (Promises) so that views for specific sections/components can be asynchronous too and loaded on demand.

viper-news as example, which is the fastest HNPWA these days, does that.

Those import(...) are brought by Webpack

[evaisse]

Definitely agree with florian registering animation and retain events on dom update is only thing missing for me right now.

I would love seeing that kind of animation stuff being done in riot without heavy use of .unmount() or creating custom tags. Just by adding some custom events to a dom node :

<random-number-list>

  <div class="app">
    <div class="block" animation={ myAnimationHandler } each={ num in numbers }>
      { num }
    </div>
  </div>

  <script>
    var self = this,
        count = 6;

    this.numbers = [];

    // using a string to get a default css-driven animation with conventions based animations (like react/vue/angular/...)
    // .animated-number.animated-number-enter/.animated-number-leave/.animated-number-update
    this.myAnimationHandler = "animated-number";
    // using a function to manage dom node lifecycle with animation
    this.myAnimationHandler = function () {

      return {
        onMount: () => true,
        onUpdate: () => true,
        onBeforeRemove: () => new Promise()
      };

    };

    function setState() {
      var i, number;

      for (i = 0; i < count; i++) {
        if (Math.random() < 0.5) {
          number = Math.ceil(Math.random() * 12);
          if (number > 9) number = null;
          self.numbers[i] = number;
          self.update();
        }
      }

      setTimeout(setState, Math.random() * 250 + 250);
    };

    this.on('mount', setState);
  </script>

</random-number-list>

It's clearly something impossible to achieve in a simple way or with any mixin in the current versions.

[damusix]

How about importing styles?

<my-tag>
    <h1> ... </h1>
    <script>
        import marked from 'marked';
    </script>

    <style>
        import 'my-tag.css';
    </style>
</my-tag>

Or alternatively
<style src='my-tag.css'></style>

Maybe even assume .css and just src='my-tag'

To keep things separate for when a component's style becomes too large. This would be amazing with postcss.

[bcartmell]

CSS imports already work. See proper syntax at MDN

[damusix]

@bcartmell Sure but will Riot import this and parse it through its CSS parser? How would standard css @import work when I'm using a compiler like rollup babel or postcss where there I can't depend on a fixed path and want to use css variables?