
Riot – A React-like, 2.5K user interface library - tipiirai
https://muut.com/riotjs/
======
saurabhnanda
I just wish there was a way to fast forward 2 years into a 10k LOC project to
find out what new problems this creates. After running after the new hotness
in technology for the last 5 years, I've realised it's never about the
problems it solves today. It's the shit that you have to maintain a couple of
years down the line.

(Not saying that this is bad -- just a random rant)

~~~
api
I tried GWT years ago. It worked amazingly well, and let me write web apps in
a real language. But it was significantly slower to develop a new site in GWT
vs. plain vanilla HTML + CSS + JavaScript, and the speed to get up and running
eventually seduced me away.

Now I'm considering going back and giving it another try. It takes more time
to get up and running with GWT, sure, but the stuff you do write with it is
written in... well... a _real language_ with types and good tooling and real
design patterns. The result is an application you can maintain and build upon
for a long period of time rather than a heap of web cruft that collapses
quickly under its own weight.

I know it's not sexy, but I've had the same experience you've had with "sexy."
I'm becoming generally disillusioned with weakly typed and even dynamically
typed languages -- they're fast to write but hard to maintain over long
periods of time.

[http://www.gwtproject.org](http://www.gwtproject.org)

~~~
boobsbr
"real language"...

~~~
api
Not saying Java is the best language ever, just that it passes a certain
minimum bar that JavaScript does not.

~~~
boobsbr
I'm a Java developer (and it might shock people, but I like it), where I work
we're still stuck with good ol' Struts, it works, and a big international
corporation uses this system.

But comparing a functional scripting language with a object-oriented
statically-typed pre-compiled language, arguing one is better than the other,
does not make sense to me.

You can easily revert the situation and say that static typing is a weakness
of java, and it's poor fucntional (until before v8) capability is a drawback
and a strong point for Javascript.

I'm not into the JS world so I can't say anything about the tooling, but yes,
Java's tooling and ecosystem is an extremely strong point.

My complaint is about dismissing Javascript as not a "real language" while
it's got A LOT going for it.

EDIT: I also worked with GWT (GXT from ExtJs, actually) in 2011-2012, and it
was really nice. I miss it.

------
jarpineh
Hm. How does this compare to Mithril JS
([http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/))?

I just looked at the doc and read this thread (at 61 comments).

Same:

* virtual dom * has its own tag syntax * Mithril has MSX, but also supports regular JS data structure with m("tag", {attr:val, onclick: func, [more tags, "text"]} * router

Different:

* Where Mithril allows you to build and transform resulting template structure before virtual DOM generation, Riot mixes HTML tags and JS, builds tags from that which can be composed * Uses a compiler, Mithril without MSX can work directly in the browser * Probably other stuff, too, I'm just reading the examples, at least is not supported Ajax/XHR

Speed is a big question. Mithril is plenty fast (there's a benchmark on the
home page, and somewhere I saw a TodoMVC comparison which put Mithril near the
top few months back).

I have not yet formed an opinion, but RiotJS' size and web component approach
intrigue me. More example apps, plz, with client/server communication and CRUD
ops.

~~~
lhorie
Hi, Mithril author here.

A few important differences as far as I can tell:

\- Riot apparently requires a compile step (at least as far as being able to
follow the docs goes), Mithril doesn't

\- Riot has no AJAX support, Mithril does (plus promises, plus an idiomatic
workflow to work with async ajaxy stuff: `var prop = m.request(...)`)

\- I could not find anything about keys in the Riot docs. Keys are a very
important part of the virtual dom diff algorithm (basically it's the mechanism
that lets you sort tables without rebuilding the whole thing from scratch)

\- Riot's router appears to support only hash mode. Mithril's also supports
HTML5 mode (which allows you to skip the # symbol), and a querystring mode
that is step in between the two in terms of tradeoffs.

\- Both Riot and Mithril redraw by default on events, but Riot appears to lack
APIs to control when NOT to redraw. This is kind of a big deal with cases like
expensive oninput, complex event bubbling behavior, etc.

Other than that, I just have a small nitpick:

> Riot mixes HTML tags and JS, builds tags from that which can be composed

As far as I can tell, Riot components can be nested, but I'm not sure they can
be composed per se. Real composition would allow you, for example, to have
lazy components (i.e. pass a component A to another component B and evaluate A
at a specific point in B's virtual dom tree). A modal is an example of this.

> RiotJS' size and web component approach intrigue me

Mithril supports the `is` attribute, and I saw someone using custom elements
with a polyfill ( [https://github.com/WebReflection/document-register-
element](https://github.com/WebReflection/document-register-element) ) and
Mithril. It's basically "Web components, the good parts". Worth looking into.

~~~
jrmiii
Thanks for the comparison. If you look in the demo code, you'll see you don't
necessarily need the compile step, just write your custom tags with riot.tag
and use strings for the would-be compiled part.

~~~
lhorie
Interesting, I missed that. But I assume that's not idiomatic, is it?

------
mrcwinn
"Riot is React + Polymer + models + routing without the bloat."

It is _not_ \+ React. It's - React. It lists as one of its features, for
example, a lack of a component lifecycle API (componentDidMount,
componentWillMount, etc). This lifecycle API is one of React's best and most
usable features. I can't give too much credit to a "tiny library" if it
achieves its size by removing even the most basic features of other projects
it's drawing from.

I don't mean to be dismissive of the work itself. Just sayin' \- for people
who might jump on this and think, "it's smaller, that's great!" \- there is
more to the story than its file size.

~~~
tipiirai
I want to continue from my earlier (hasty) response. I was on mobile and don't
enjoy typing there.

What I want to emphasize is that you can build custom tags without knowing
much how Riot works. Just put together HTML and JavaScript. No need to know
about `getInitialState`, `render`, `this.state` etc.. I wanted to create a tag
definition syntax that is easy to learn and remember.

There _are_ lifecycle events if you want to do something more specific.

I'm also not a fan of `shouldComponentUpdate`. Ideally you should not think
about such things and let the underlying library take care of the performance
issues.

~~~
RussianCow
> I'm also not a fan of `shouldComponentUpdate`. Ideally you should not think
> about such things and let the underlying library take care of the
> performance issues.

In my experience with React, something like this is absolutely necessary for
performance once your data model gets to a certain scale. Does Riot have an
equivalent? I agree that you _shouldn 't_ have to think about that stuff, but
the reality is that sometimes you need that extra bit of performance.

------
danabramov
After reading a bit more, I don't think it's really that React-like, except
for virtual DOM.

I wrote a tangentially related article today:

[https://medium.com/@dan_abramov/youre-missing-the-point-
of-r...](https://medium.com/@dan_abramov/youre-missing-the-point-of-
react-a20e34a51e1a) (will be a series of posts, this is intro)

------
curveship
Question: do I read your compiler right, that any line starting with 'var',
'function' or 'this' is assumed to be javascript? So for instance:

    
    
       <p>
          How will riot.js compile
          this line?
       </p>
    

would fail?

[Don't mean to sound negative: I've been playing around with my own minimalist
framework, so this is right up my alley. I'm reading the code to get a feel
for how we've solved problems the same or differently, including the compile
phase. Neat stuff and I'll write more when I have time to go over it in more
depth.]

~~~
tipiirai
Not sure but this might indeed fail. Can you place an issue to github? Thanks!

Maybe it's good to split HTML and JS with the last HTML tag.

~~~
evmar
Idea: require a <script> tag around the JS in the template (but just for your
parser's benefit, not as a tag you intend to embed literally in the rendered
DOM -- you can remove it at parse time as necessary).

This has the nice side benefit that it will make editors happy. (E.g. emacs
recognizes <script> tags within HTML and does JS highlighting/indenting on
their content.)

~~~
tipiirai
I can clearly see the benefits here. I'm also resistant to it because of the
added syntax. Deciding later :)

~~~
jbellsey
The idea of having integrated components (HTML+JS) is certainly interesting
and forward-thinking. However, I hope it doesn't lead you to limit us to the
integrated style, by making the Riot compiler a required build step.

Personally, I greatly prefer the direct coding style, i.e., riot.tag(). Not
only because of the editor issues mentioned here, but because I can include my
own modules in my scripts. I.e., can I use require() inside a Riot-compiled
module?

Stuff starts getting very hoop-jumpy once you start creating your own compiler
& syntax, and bringing too much "magic" to the table. One of the big appeals
of Riot is how UN-magical it is!

------
jf22
I'm suspicious of libraries who showcase their size as a reason to go with
them.

Its the motion of the ocean in the library that matters.

~~~
tipiirai
Size is multiple things:

1\. simplicity

2\. maintanability

3\. API surface and learning curve

Riot also about _minimalism_ , especially in syntax.

Less proprietary stuff (and keystrokes).

~~~
lukeasrodgers
In my experience with Backbone, another relatively small js library, the fact
that the library is smaller and "does less for you" also means that you end up
in one of these scenarios: you need to figure out how to solve a lot of things
that other, larger libraries handle out of the box; or, you need to glue
libraries together that provide those solutions; or, you have a bunch of prior
experience with the library in question, have solved those problems before,
and can bring that expertise (and often that code) to each new project.

These all bring with them their own issues of simplicity (tying libraries
together?), maintainability (what happens when I realize my library/framework
additions are inadequate, and/or buggy?), and learning curve (instead of
learning the API I am learning how to do things with a very minimal API).

To some degree, a small library doesn't solve these problems, it offloads them
to you--which isn't necessarily a bad thing. It, like basically everything in
software development, is about being aware of the tradeoffs and figuring out
the best balance.

~~~
tipiirai
This is all very true.

But in case of Riot I suppose it's best for you to read the documentation and
see whether it does the job for you. I personally think the custom tag
approach is a great way to go.

------
otikik
One of React's selling points is that it uses a virtual DOM to minimize the
amount of manipulations it does to the real DOM -
[http://facebook.github.io/react/docs/reconciliation.html](http://facebook.github.io/react/docs/reconciliation.html).

The virtual DOM is an implementation detail (riot could re-render everything
on each change), but it's what makes React fast, and good for handling big
apps.

I don't think you can call a lib "react-like" if it doesn't have something
like the virtual dom diff. You could say it has react-like _syntax_ , maybe.

That said, I have been following riot for a while and I always liked its
minimalistic approach. Maybe I will give it another look now that it is 2.0

EDIT: I somehow missed the big subtitle which says "Virtual DOM" on the
website. It clearly states that Riot has something similar to React's. I can't
explain know how I managed to not see it. Thanks to everyone who called me
out.

~~~
yuchi
It’s advertised as having a Virtual DOM.

~~~
otikik
You are right, I will have to investigate more. I don't know how much of
react's virtual dom diff can you cram in 2.5kb though :)

~~~
tipiirai
Not much. The point is that such heavy diffing can be avoided if loops and
conditionals are enough and if you don't need random HTML changes.

~~~
tipiirai
Exactly. Loops and conditionals should give you enough power.

But in React you can arbitrarily change HTML because the render method returns
a string to be compared to the earlier situation.

A tag name can change for example (which you rarely need).

~~~
masklinn
> But in React you can arbitrarily change HTML because the render method
> returns a string to be compared to the earlier situation.

I'm pretty sure the render method returns a vdom node (which the library can
then diff and merge into the actual DOM)

------
thomasfl
I like the use of a virtual DOM and the custom tags. Custom tags is what makes
Angular easy to use. But I would like to see some benchmarks. I'm afraid
parsing every single byte of every single html template is slow.

Riot also needs widgets. Lots of lots of widgets for material design widgets
for making desktop and mobile apps, and twitter bootstrap like widgets. Good
developers are lazy developers. They don't want to make an entire eco system.

~~~
tipiirai
Benchmarks are definitely coming.

In theory Riot is super fast. The DOM is parsed once when a tag is initialized
and after that the text nodes and attributes are only updated if the
expression results to a different value. The expressions are compiled and
cached.

Any performance bottleneck can be fixed.

~~~
masklinn
> Benchmarks are definitely coming.

Beware the way you're benchmarking, e.g. immutable structures and pure (&
immutable-state-aware) components can make a pretty huge difference in react.

~~~
tipiirai
Yes. This is indeed a big challenge.

Maybe I can just use the TodoMVC app.

~~~
masklinn
Yeah Matt Esch (virtual-dom) has a bench based on todomvc:
[https://github.com/matt-esch/mercury-perf](https://github.com/matt-
esch/mercury-perf) [http://matt-esch.github.io/mercury-perf/](http://matt-
esch.github.io/mercury-perf/)

Or [http://evancz.github.io/todomvc-perf-
comparison/](http://evancz.github.io/todomvc-perf-comparison/) which seems to
be an older version of the same bench but has a better output.

~~~
tipiirai
Thanks. I think comparing Riot with React is most important initially. And
there is no Riot 2.0 TodoMVC example available yet.

I also think that Riot performance can be further optimized.

Slowly getting there...

------
lsdafjklsd
After using ember's router and react-router, I can't do client side routing
with a router like this (or backbone's, or anything that is sinatra like). The
layout management part of nested routes is crucial and way too hard to do with
something as minimal as this.

That said, great work on this library! I'm impressed with how much
functionality you guys have in such a small package.

~~~
xixixao
Which (if any) client side router library do you prefer then?

~~~
danabramov
react-router, I assume.

See more on nesting: [https://github.com/rackt/react-
router/blob/master/docs/guide...](https://github.com/rackt/react-
router/blob/master/docs/guides/overview.md)

------
iamdanfox
Immutable props seems to be one immediate difference between React and Riot. I
hope this could be considered for a future update; immutability by default
makes debugging so much nicer!

(Also React's PropType checking is surprisingly useful)

------
danabramov
It would be cool to summarize the kind of stuff you can or can't do with Riot
vs React.

I still don't get how state works, whether state changes propagate down the
components as prop changes like in React, etc.

~~~
tipiirai
Each component maintains it's own state. Think them as functions with isolated
scope. The tags accept arguments via HTML attributes and each tag has a
reference to it's parent.

Instance variables and method are assigned to the scope and you have direct
access to them on the HTML expressions. Once the scope changes and tag's
`update()` method is called the expressions are calculated and DOM nodes are
updated. Nested children are also updated.

You can update all tags at the same time with a global `riot.update()` method.

Hope this helps.

------
b6fan
One thing I like React is it is plain javascript.

Therefore I can use coffeescript to describe the component:

    
    
        {div, p, ul, li} = React.DOM
        ...
        render: ->
          div className: 'foo',
            p className: 'bar', 'blabla'
            p className: 'bar', 'blabla'
            ul className: 'somelist',
              @state.items.map (x) -> li key: x.id, x.content
                

If Riot.js uses a custom parser, it may not be able to do this.

~~~
evmar
This no longer works in React 0.12 because they changed the element creation
syntax. :\

~~~
b6fan
Actually I am using this syntax with React 0.12.1. React.DOM just work as
expected. For custom components, prepend "React.createClass" with
"React.createFactory". See
[http://jsfiddle.net/saxr8gLd/](http://jsfiddle.net/saxr8gLd/)

------
sebastianconcpt
I really like what you guys are trying to do. MVP is fantastic and if you get
the virtual-dom kind of rendering then it could be _it_.

I'm planning to evaluate integrating this for flow [1] I've already created a
card for it [2]

[1] [https://github.com/flow-stack/flow](https://github.com/flow-stack/flow)
[2] [https://trello.com/c/6gwqvq5l/91-riot-
integration](https://trello.com/c/6gwqvq5l/91-riot-integration)

------
stereosteve
Looks nice. +1 for enclosing JS in a script tag.

Vuejs has a nice component compiler: [https://github.com/vuejs/vue-component-
compiler](https://github.com/vuejs/vue-component-compiler)

It puts JS inside of a script tag, which would fix some of the parsing issues,
and also fix syntax highlighting. It also provides hooks for pre-processors.
Have you considered this approach?

~~~
tipiirai
Need to consider the script tag.

------
chadpaulson
I'm curious why a library which puts emphasis on a slim Virtual DOM
implementation would go through the trouble of accommodating jQuery.

------
hokkos
Seems more like Angular than React with the template expression, why compare
it with React then ? Angular is now a dirty word ?

~~~
tipiirai
React is closer to Riot than Angular because of HTML/JS components backed with
virtual dom. The HTML syntax is perhaps closer to Angular than JSX.

I'm sure there will be a Angular comparison here as well:

[https://muut.com/riotjs/compare.html](https://muut.com/riotjs/compare.html)

Ember too, because of HTMLBars (DOM based templating) and FastBoot (later).

------
konradb
I'd be really interested in the views from people who were much more into JS
than I am. I've used Angular for a couple of small cases now and I like it,
but have been hearing lots of good stuff about React (and even Om, I'm quite
Clojure inclined). How does this stack up against React in terms of power,
brevity, etc?

~~~
tipiirai
Maybe you can find the answer from the comparison section:

[https://muut.com/riotjs/compare.html](https://muut.com/riotjs/compare.html)

~~~
yaddayadda
Maybe I'm missing something, but that comparison looks like apples versus
oranges, or more specifically JavaScript-side versus HTML-side. The React
example looks like the JS-side only, while the Riot example looks like the
HTML-side only. What am I missing?

edit: I see a touch of embedded script (i.e. handleSubmit) in the Riot
example, but not nearly enough to replicate the JS code in the React example.
And there is a <script> call, but it looks more like an Angular partial than
an actual script.

~~~
muraiki
I haven't used React in about 6 months, but I'm pretty certain the Riot code
does the exact same thing.

If you haven't used React, it has JSX as syntactic sugar for what would
otherwise be a bunch of javascript: see the "render" function in createClass.
So a component is written in JS.

With Riot, the JS goes into the template to create a component.

There's a lot of things to like about React, but it requires some boilerplate
and a larger API in order to support the amount of freedom it offers in
updating (that Riot page goes into this a bit).

If you want something that keeps the HTML and JS separate but still allows
components, while having a straightforward API along with a small file size,
check out knockoutjs.com

~~~
yaddayadda
> If you want something that keeps the HTML and JS separate ...

I guess my JS knowledge is small enough that I just expect the HTML and JS to
be primarily separated. (It seems like a best practice to me, but I haven't
experimented with code that wasn't primarily separated, so I'm sure I'm
missing some important insights).

Thank you for making the knockoutjs.com recommendation. For someone, with
primarily Angular experience, who is looking to broaden their horizon, which
of the three would you recommend as the _next_ framework to learn: React,
Riot, or Knockout?

~~~
muraiki
I believe that React would offer you a very different perspective. It also has
a strong developer community; React is already being used in a lot of places
(although Azure's management interface was just recently redone using
Knockout). I've also heard that you can combine React and Angular.

Reading this will take a bit of time, but it will help you to understand
React's approach: [http://jlongster.com/Removing-User-Interface-
Complexity,-or-...](http://jlongster.com/Removing-User-Interface-
Complexity,-or-Why-React-is-Awesome)

After this, the React tutorial should get you up and going. Once you start
working on more complex apps, look into the Flux architecture (an approach to
application structure that Facebook uses with React, like you'd use
MVC/MVVM/etc otherwise).

------
nhunzaker
This seems way different than the library I remember 6 months ago...

[https://github.com/muut/riotjs/tree/8c7e841e2c7724df9bab9397...](https://github.com/muut/riotjs/tree/8c7e841e2c7724df9bab939749c691b67e88151d)

Rebrand?

~~~
bshimmin
It seems like their manifesto here hasn't really stood the test of time:
[https://muut.com/blog/technology/riotjs-the-1kb-mvp-
framewor...](https://muut.com/blog/technology/riotjs-the-1kb-mvp-
framework.html)

(The bits about jQuery at least, anyway.)

~~~
tipiirai
True. Things have changed since then. Especially about role of jQuery in
views. Riot 2.0 unifies HTML/JS together causing less need for it.

I still think jQuery is still fantastic and definitely has a lot of use cases.

------
jbrooksuk
For anyone who doesn't remember, Riot.js used to be a 1kb MVP library,
[https://news.ycombinator.com/item?id=7036274](https://news.ycombinator.com/item?id=7036274)

~~~
tipiirai
I'm sorry :)

~~~
jbrooksuk
_Shakes fist_ you will be ;)

This looks better though, IMHO.

------
chrisfarms
Fantastic intro doc. I read the entire thing without really thinking. I like
the aim, and I think I could learn to accept the weird looking javascript
floating in the root node (though I think it might look easier on my eye if
wrapped in a <script> tag, even if that tag is redundant)

But, I would _really_ love to see some render time benchmarks with large (2K+)
loops adding/removing deeply nested nodes. This is where React really shines
in my opinion, and I'm struggling to believe that Riot can compare with the
implementation described.

------
STRML
Very cool project! I have used nearly every framework under the sun and React
is, by far, my favorite. It's getting better every release. The concepts it
introduces are sound, and I don't think I'd ever do frontend development any
other way.

That said, Riot is a very encouraging take on React - and I think it may have
a very solid place in apps that need to be very light and fast. Perhaps it's
perfect for prototyping. I will try to find a small project for it.

One question; is there any way to render to a string so Riot can be used
server-side?

~~~
tipiirai
Server side rendering is on the roadmap among other things. Look for the last
item on the FAQ:

[https://muut.com/riotjs/faq.html](https://muut.com/riotjs/faq.html)

------
danesparza
One of the biggest selling points for React/Flux for me was the fact that it
had been proven by Facebook and Instagram on some very large projects.

What has this been used on?

~~~
sebastianconcpt
Welcome to the "Nobody was fired by hiring IBM" of the new century.

~~~
danesparza
Please don't misunderstand. I was only trying to make the distinction between
"somebody's pet project that might work" and "this stuff HAS to work for
millions of views and hundreds of devs every day"

------
daemonk
Does this support nesting custom tags? How do I communicate between different
tags? Is the opts variable accessible outside the definition of the tag?

~~~
tipiirai
Unlimited nesting is supported. You pass options with HTML attributes:

<parent>

    
    
      <child arg={ data } />
    
      this.data = { foo: 'bar' }
    

</parent>

~~~
vidarh
Is that only when defining a custom tag, or when using it as well? All the
examples seems to be of nesting when defining a custom tag. If it supports it
when using the tag, how do you get access to the nested content?

------
bleuarff
I will definitely have a look at this release, it seems to bring quite a few
changes. We've been happily using Riot in production environments for nearly a
year now, since before 1.0 release. I can't tell enough how happy I am with
this framework. It's incredibly easy to build quite complex interfaces. Thanks
Muut for that!

------
cayblood
I would like to see more documentation about how to accomplish some of the
benefits of web components with Riot.js, such as the ability to style your
custom components without having those styles influenced by the host page's
CSS and the ability to selectively theme nested elements with things like
/deep/ and ::shadow.

~~~
tipiirai
Currently styling is outside Riot's responsibility. Shadow elements are not
supported enough on browsers and require too much polyfilling.

Also not sure about component- based styling in general. I think that CSS
should be controlled separately <\-- highly personal opinnion.

~~~
cayblood
Your whole point about polyfilling really avoids the issue that web
components/Polymer is trying to address. Of course polyfilling is needed now
for that, but until we have it, we won't have truly reusable web components,
and claiming Riot can substitute Polymer is therefore a pretty big bait and
switch, cool though Riot.js may be.

~~~
tipiirai
I would say that Riot does very much what Polymer is trying to address - which
is custom tags.

The implementation and syntax is different so it's not a drop- in replacement,
but both have similar goals.

------
qwtel
Looks nice. React really is more of a pattern or (if you will) a design
philosophy, so anything along those lines is appreciated. However, I don't
think being ~10x smaller is enough. It needs to be ~10x better as a whole,
which in my view it isn't. The improvements seem more cosmetic than
substantial.

------
caoglish
Last year, its size is 1k which they are proud of. Now 2.5k which is 2.5 times
of used to be. Just let me guess: this library will become double size to 5k
next year this time.

Even jQuery is thinking how to reduce the file size by its team. This library
increases its size like this much. Seriously?

------
rcarmo
I've been using Riot 1.0 for a number of simple things (including a few
dashboards) and it's a lot less hassle than most other JS frameworks.

This looks like a very nice upgrade, in the sense that the previous templating
was a bit ugly. I hope the virtual DOM let me handle SVG as well...

~~~
tipiirai
SVG should be no problem if loops and conditionals are enough for the logic.
Never tried though.

------
dirtyaura
Looks promising. Is this battle-tested yet? I.e. is there a web app with a
non-trivial amount of traffic that is using Riot at the moment?

The main selling point of React is that it is actually tested against millions
of users and browser configurations as a part of Facebook UI.

~~~
tipiirai
muut.com uses Riot for authentication, signups and for forum settings which is
a fairly large application. The site is fairly popular.

Of course React is much more tested and probably more solid at this point and
Riot 2.0 is just released.

But one major benefit for Riot is that there is indeed 24x less code to
maintain and so much less weak spots to take care of.

~~~
therealunreal
Do you think that the 24x less code is because of its exceptional design? Or
is it missing some features?

~~~
coldtea
Some of the features might be redundant (at least for some use cases) so it's
not like "missing features" is necessarily a deal-breaker.

Not that you said so, but it's something one can think when he hears that Riot
might be "missing stuff".

------
pags
Maybe I just don't get it, but I can't even get anything from the landing
page. What concerns does this library address? What are the general
abstractions like?

Why would I even consider digging deeper without knowing the answers to those
two questions?

------
boskop
Looks very similar to ractive component spec:
[https://github.com/ractivejs/component-
spec/blob/master/auth...](https://github.com/ractivejs/component-
spec/blob/master/authors.md)

------
Freyskeyd
Hey,

I'm just curious about performance with fucking large app. It's always the
main issue for me, a todo list can't show use performance. If your framework
is fast with 3 items in a list, what's the point with, like, 1000?

I'm gonna try

~~~
tipiirai
Haven't tried with such large datasets. Very curious about the results!

Should be fast, since Riot uses compiled and cached expressions and updates
DOM nodes only if there is a change.

If there is a performance bottleneck, it can be fixed.

We'll be doing performance tests and comparisons later.

------
facorreia
I've user Riot 1.0 successfully on a project, and I'll be looking into this
iteration. Embracing React's virtual DOM model, in a minimalist way, does
sound attractive.

------
coding4all
I feel sorry for people who have to write native JS at this point. I can't
imagine a JS job interview where you didn't have to know of/about yet another
framework.

~~~
woah
Great to have some innovation on the frontend for once. We're getting closer
and closer to a place where we can write flexible, performant interfaces
without the heavy frameworks and tooling of native frontend dev.

------
niutech
Earlier news about Riot.js:
[https://news.ycombinator.com/item?id=6653024](https://news.ycombinator.com/item?id=6653024)

------
heldrida
This looks amazing! I work with angularjs, been testing reactjs, but this
looks simpler and minimal to code ? Probably less documentation or community
online ?!

------
CmonDev
Where is the list of controls? I would be really interested to see their grid
layout control implementation. This is something web is struggling with.

~~~
tipiirai
Riot 2.0 is a "core" library and such controls can be build on top of it. No
controls exist, since this is all very new.

~~~
CmonDev
What happened to Riot 1.0 though?

~~~
tipiirai
Riot 1.0 started liking what React did to views.

------
ph0rque
Is there any way to automatically convert your react code to riot to try it
out? That would make it easy for me to decide if I should switch.

~~~
license2e
+1 for React to Riot converter

------
kmfrk
Would love an example of an example project. That can be cloned and played
around with.

Some people learn by reading docs, but I like the hands-on experience.

~~~
tipiirai
Agreed. This is coming.

------
gasping
This bears no resemblance to react whatsoever. By taking out the render,
getInitialState, componentWillMount and other lifecycle methods Riot.js
completely misses the ideology behind react and becomes just another
templating library. Waste of time, anyone reading this should stick with
React.

Not to mention we've moved past code tags like "each={ item, i in items }".

~~~
tipiirai
Glad you like React so much!

Maybe have another look for Riot on a later time and you can perhaps see the
reason for it to exist.

------
ola
Is this the same Riot.js as the 1kb framework or is this just named the same?

~~~
tipiirai
Yes. It's the same library, but with a new (major) version.

It's inspired by React so the views are build differently than in 1.0.

~~~
ola
Ok, now I understand, sometimes there are several javascript projects with
same name.

------
heldrida
So impressed with both Riot and Mithrill! Thanks for sharing your work guys!

------
odiroot
Great, another framework mixing concerns and doing custom HTML.

What's wrong with React?

~~~
tipiirai
The point of React is to mix HTML and JS together. They deliberately mix
templates with logic, which is actually the main inspiration for Riot.

But we felt that what React does could be simplified. We didn't need full
diffing and batching of HTML and we didn't like the verbosity on how
components are created.

 _minimalism_ is where Riot starts from.

~~~
mjackson
> The point of React is to mix HTML and JS together.

In React, there are no "templates." There's just JavaScript, and then more
JavaScript that looks kind of like HTML (JSX). But it's all still JavaScript.

Also, FWIW, I find that one of the largest benefits of React is to have the
logic and the representation of the markup inline, together in the same file.
It really helps productivity by eliminating the context switching going from
js to markup.

> We didn't need full diffing and batching of HTML

^^^ That's the point of React. You don't have to do the diff in your head (or
in your code).

------
mtarnovan
A link to the github repo would be useful.

~~~
tipiirai
Here you go:

[https://github.com/muut/riotjs](https://github.com/muut/riotjs)

It's on the download page. Admittedly not very visible.

~~~
tipiirai
Ribbon is now there.

Thank you!

~~~
mborch
Maybe just _watch_ me on Github.

------
tmaly
seeing figures like 2.5K makes me think back to the days of programming
assembly in 4K space on an HC12

------
invarinat
it should be nice if it was like react( html in js)

------
grabcocque
Oh a new Javascript framework. I'd been getting worried, it'd been 40ms since
the last one.

~~~
Touche
Oh a dismissive comment on HN upvoted to the top. I'd been getting worried,
it'd been 1 post since the last one.

~~~
it_learnses
Oh a strawman comment on HN...

~~~
marrs
Oh, a reddit meme on HN. I'd been getting worried. I hadn't seen one of those
here yet.

------
curiously
The amount of negativity and grilling is overwhelming here.

Riot addresses all of my pain points about frontend javascript frameworks by
not being one yet offering the essentials.

The file size is absolutely essential. ~100kb to load Angularjs in your
browser is crazy and to have to wrestle with framework specific learning
curve.

My only concern is will the learning curve be brutal as Backbone.js?

------
debacle
Minimal usually means slow.

