Riot: Update riot project description

[GianlucaGuarini]

I have started updating the riot documentation for the upcoming 3.0.0 release but I realized that the project description _A React-like, user interface library_ (used many times in our doc) is not really fair. Riot is not like React it doesn't use virtual dom see also https://github.com/riot/riot/issues/1977. Riot is probably one of the simplest and smallest UI/DOM javascript libraries and removing the riot-router in [email protected] we will be focused only on the presentation layer so it will not be a full stack library anymore. I guess we could find a better description for riot more compliant to its philosophy.

All suggestions are really appreciated
✌️

[GianlucaGuarini]

ping @tipiirai @rsbondi @aMarCruz @cognitom @rogueg

[cekvenich]

Improved Web Component - easy to use, easy to style. Continued: "you should be using web components now on your team - and that includes designers and cross browser support. Other dom based components like HTML5 web component and polymer are rough, and non dom UI components are less designer friendly. Download this zip to try, you'll stay''

[zazapeta]

Low cost UI Library :

• Low size (6kb)
• Low learn curves (easy to learn)
• Low verbosity

Riot is a fresh K.I.S.S. that keep your headache as low as possible.
Try it, you will be rich again.

[sylvainpolletvillard]

one of the simplest and smallest UI/DOM javascript libraries

There, you have it :smile:

[dypsilon]

This is the first time I look at Riot, so my suggestion is very shallow. On the other hand, don't you want to know what a person first looking at Riot expects from the description? So here it is: there are many frontend frameworks out there, please include how Riot differs from all of them right in the project description.

[vitogit]

Powerful minimalistic UI/DOM javascript library with clean and concise syntax

[KrishnaPG]

I would strongly suggest not to use either "web components" or "react like" on your documentation till the event system is nailed down. They are misleading and unnecessarily wastes the users time with mismatched expectations. As @GianlucaGuarini has already advised (here https://github.com/riot/riot/issues/2012) Riot js needs user-written "external app logic" to achieve the expected event functionality and not ready for prime time (at least to compete with the likes of "react" or to be called as "web component" library).

There is no harm in just saying it is a 'lightweight framework' without having to compete with React or web-components.

With the need for "external app logic", Riot.js essentially boils down to be an MVC / MVVM framework, rather than being a web-component one. The example created by @GianlucaGuarini in https://github.com/riot/riot/issues/2012 clearly highlights this MVC nature.

Also, size is not the only criteria for a framework. In fact, the gzipped JS file size may matter initially, but once the browser downloads it, the later requests to it will be served by local browser cache (for several days). Hence size is not a deciding factor. Rather, what is more important for template engines is, the performance. It would be good for users to see performance benchmarks of item rendering, especially when large list of items are being updated on the fly. The issue https://github.com/riot/riot/issues/2012 once again highlights a major all children update problem that could hamper performance (specially for large tables), and users should well be aware of these kind of limitations before staring to adapt this framework.

[cekvenich]

@KrishnaPG I don't see some of your points:

• It is a web UI component, one of many, you don't have to call it that, but that's what it is. Ex: A 'competitor' to RIOT is v1 of HTML5 standard web component http://masons-foundation.org/en/s_home/webComp/comp1
• 'app logic' / Framework / MVC is heavy and big and hard to debug and learn to use. I hope creators don't think of this as a framework, more of a lib. For framework, any can use this, ex: Flux. (not MVC | MVM - those are now considered harmful). I would argue that even navigation or data binding be done outside of the web components so that we can render a SEO page when needed. Biggest feature is shadow dome (:scope) so that you can have a nice UI component style embeded. (and then page can bind to it). There are plenty of events and route religions, but there is only one DOM based component that a designer can style using their tools (ex: Sass).
• size does matter in download times, most user are mobile. And google PWA is pushing small loads. For example ads are capped at 200K max. AMP is < 40k. That includes images. Also if I get advanced I want to groak the code base.

Being small is harder than being large.

[MartinMuzatko]

Riot is solving a lot of pain points which do not only concern beginners but also experienced developers. Riot helps to overcome the huge amount of knowledge required in 2016 to build something interactive but still organized.

As I described it on my blog: Riot is a lightweight micro UI-Library. Writing powerful Apps without learning dozens of idioms and methods.

Most of the time, when I learn something like Angular(1/2) I don't feel like learning JavaScript but just a set of proprietary ideas. With Riot, I'll learn something new too, but I will be able to use this knowledge beyond the projects, I use Riot with.

Riot didn't require me to have a huge build setup, which was fantastic to start with Riot. Riot enabled me to learn - along other tools - how to better use it together with node. So in my honest opinion. Of all the tools that would enable me to create interactive component-based webapps, Riot had the best learning experience. A year ago, I was shying away a bit of all the tools bearing these big words like "Observable", "Router" etc.. But later on, I was thrilled to learn more, as every little tool in Riot taught me to be a better developer.

This is something I enjoyed most about using and learning Riot.

Maybe this helps to better find out what makes Riot so special. Right now I can't come up with an explicit suggestion. If Riot didn't exist, I wouldn't be able to keep up with the speed of the javascript developer world in the first place.

You can find almost any tool in the NPM registry. But you won't find such a helpful and amazing tool that has so much heart and thought put in it, than Riot.

[ninthspace]

As someone who has gone through Angular 1, discovered and worked with Polymer (and wish he hadn't) and is not convinced by VueJS or the ridiculousness of React, Riot is simply "web components that just work".

Furthermore, it's straightforward to migrate a traditional (perhaps Ajax- or Pjax-driven) website into one that partly or wholly uses Riot.

[nodefish]

Some unstructured notes:

• Usage-wise it's still fairly React-like, regardless of how it maintains rendering state behind the scenes, so there still might be some merit to that statement.

• It's definitely component-based and compositional. Composition is really "in" right now as a concept in this field.

@KrishnaPG There's no way to completely eliminate coupling and make components completely reusable. There's always some expectation of how a component will be used. A simple button component, at some point, needs to talk to the app in some way. There's no difference here at all between React and Riot. It's only a matter of defining your component's API in a general enough way.

Riot is just as component-based as React is imho.

• Sadly, Riot isn't doing so well in terms of marketing. Vue.js kind of won the "minimalist" spot in people's perceptions, even though it's got ~1.5-2x mental load over Riot.

• I feel like there should be some logos of companies that use Riot in production on the front page, because the JavaScript ecosystem is already extremely fragmented, so people very easily rule out libraries that look like they don't get any use.

[senica]

Do you have any [google] analytics on how people are finding riot — perhaps some of the keywords will show what people are looking for and you can speak to that? I believe I stumbled on it by using some keywords like "user interface" (currently in your description).

"A painless user interface library...that just makes sense."

[MartinMuzatko]

@nodefish coming from a marketing background myself, I have to say a few things regarding your comment.

Beware, as this lengthy comment will not really contribute to the topic at hand but still might help finding the "identity" of Riot and thus, how one can see or understand Riot.

While a few logos strapped on a webpage can help people see where it is used - it doesn't really tell much about the tool other than that it is trusted by an amount of enterprise people.
Riot has 10000 stars already - which is really impressive!

"Vue.js kind of won the "minimalist" spot in people's perceptions"

It depends on the worldview of the user. You can "sell" a minimalist tool both to developers that prefer more magic and handholding in their approach or to developers that would like to have a bit more of control.

There are dozens of different tools to do the same thing. This can't be more true in todays web development. So Riot has its own appeal to various developers. But they all share one ore more worldviews regarding how a tool should work and how it supports them.

"A painless user interface library...that just makes sense."

Delving a lot into the forums and github issues, one can tell what makes Riot so appealing. A tool should help you overcoming insecurities regarding how to build something. If you know that other tools such as Angular are helping so many companies to build awesome apps, but you suck at using it - whose fault is it then? Yours or Angulars? So Riot has its well earned right to exist and to be used by (telling by the stargaze amount) at least 10000 developers that love to have this tool existing and working. Fixing real problems or real people.

Honestly, if you want to help Riot spread the word of an amazing minimalistic approach, you should write blog posts, attend local meetups and discuss Riot or even organize a talk like I did.
Hell, there are so many other options like extending the Showcase of Riot.

Having already a lot of loyal developers to share their opinion here in the issues or in the forums helps :)
This is always something that will keep Riot alive.

[nodefish]

@MartinMuzatko I know it depends on the user's worldview, but I find it discouraging when I see framework comparisons that list 7 different frameworks, and Riot is not in the list. I don't need Riot to be the most popular library, but I think it's not even getting a minimum of acknowledgement. This is more of an objective problem than a subjective worldview problem.

The logos are only for preventing people from flicking through the site and saying "oh ok" and just leaving. Of course, as @senica suggests, site analytics can confirm this or other trends. People make quick heuristical decisions all the time, though, especially in the JavaScript ecosystem which has thousands of libraries vying for attention. It's very easy to rule out Riot from the start and anything that reduces that chance, and has literally 0 cost, is worth pursuing imho.

A lot of your post is about the merits of Riot. I'm pretty sure people who are here already know Riot is good. The problem is getting it a bit more recognized. I don't want to evangelize, that's very corporate and Microsoft-ish. I view this rather in the inverse: I want to find the problem behind why Riot has so little traction, and resolve it.

[KrishnaPG]

@nodefish

There's always some expectation of how a component will be used.

Standardizing that expectations is what makes or breaks a framework / library.

If one takes a riot-gear component and cannot swap it with a similar Riot component that offers similar functionality (without referring to the documentation of the new component) - that indicates the failure of framework/library.

You are right: one cannot completely eliminate coupling

That is why frameworks / libraries exist - to abstract out the coupling

---

As for the marketing of Riot:

We are using Riot in production for a large scale enterprise grade application - but our experience with it did not motivate us to give a reference to any of our other customers.

If it helps, here are the issues that burnt us heavily:

1. Performance issues with child tag updates
2. Zombie child tags when nesting tags
3. Static evaluation of branches
4. Lack of transition (exit/entry) support for list items
5. Not so direct support for dynamic tags and HTML content rendering

---

Having said that, let me also say few positive things that we liked about Riot:

1. Simplicity and component Re-usability
2. Expressions are actual JS script
3. Build tools support (such as riot-brunch)

These made us get started with Riot quickly. But only to find later that it is not ready for prime time.

All in all - Riot is a very good concept - but it still has long way to go, if this has to be taken seriously.

We would be happy to be the first ones to give an official reference / endorsement to the world, if it can fix the gaps.

[nodefish]

@KrishnaPG

If one takes a riot-gear component and cannot swap it with a similar Riot component that offers similar functionality (without referring to the documentation of the new component) - that indicates the failure of framework/library.

To me, that's a failure of the component, not the framework. Riot is agnostic and freeform in terms of how you design a component's API. I don't see how React or Vue is any different in this regard. It would be helpful if you could give an example of how other frameworks differ in this regard.

[KrishnaPG]

@nodefish

all other frameworks doing the same mistake, does not justify it as right.

To me, that's a failure of the component,

And a framework / library that is surrounded with dozens of such failed components - hardly can succeed in the market.

The way successful frameworks/libraries deal with this is: by providing clear semantics.

The problems we face in our system (indicated in earlier post), all are consequence of this lack of clear semantics. For example, a dynamic language evaluating static type branching is a confusing semantic that forces one to either write too much of boiler-place code or loose performance. This is a recurring pattern we faced with RiotJS

[rsbondi]

I think we need a new issue created, here is for discussing the description of what riot IS and not what you think riots SHOULD BE

[senica]

@rsbondi it can be helpful to see the "weaknesses" to help identify what exactly Riot _IS_. For example, @KrishnaPG pointed out one of my biggest pet peaves of "user interface" libraries. That is the lack of support for _in_ and _out_ transitions. A user interface library should seek to make building a pleasant user experience better, faster, and easier. Riot lacks this feature as I pointed out here https://github.com/riot/riot/pull/2004. It provides directives for each, if, show, hide, but provides no means for transition between those states when bound to a model (or javascript expression). In that regard, riot does not make building a user interface a pleasant experience at all. There are loosely three main states of a visual component in a user interface: hidden, transitioning, and visible. When one-third of that is not accounted for (transitioning) in a user interface library, what are you left with? Hopefully this helps answer the question "what is riot?" Or perhaps, "where is riot headed?"

For me, I'll continue to use Riot because it's in line with my development styles and gives me back freedoms for dom manipulation without building crazy directives (angular) everytime I want to do something very simple. Perhaps "freedom" is a keyword that should be used. Other libraries/frameworks really seem to limit creativity without 5x the extra work. I believe in the direction of Riot and even with my complaints, it's still "A painless user interface library...that just makes sense [for me]."

@KrishnaPG you sound like you've come a similar place as me in terms of developing with Riot. It's a love/hate thing. I'd encourage you to get involved in doing some pull requests or send some money their way to continue development. Even if they hate your pull request, it at least gets them thinking of what is missing/lacking.

[rsbondi]

Yes very helpful, but not in this discussion, that is why I said to open a new issue please!

[prateekbh]

@GianlucaGuarini @rsbondi @sylvainpolletvillard

"A minimalistic and comprehensive UI Library"
simple like "facebook" without "The"

GIF

[rsbondi]

I am all for removing "React like", "virtual dom" and "full stack", I don't think "web component" is a good idea, it may lead to false expectations, would prefer something like "component based".

[GianlucaGuarini]

until now the one I prefer is: "Powerful minimalistic UI/DOM javascript library with clean and concise syntax"

@prateekbh thanks but your description would not push me downloading it

[cekvenich]

@GianlucaGuarini Please glance this tutorial on stanard web components v1

• http://developers.google.com/web/fundamentals/getting-started/primers/customelements
  If you read there in 'browser support' section - it is ratified now.
  But the gist of that is that it is 1:1 w/ RIOT functionality. And they call it 'html5 web components v1.

Also saying 'DOM javascript' is confusing at first glance. Playing w/ your title, here is an iteration:
How about: 'Powerful UI DOM component library with clean syntax'
For more they can read up, but it's a good subhead.

[GianlucaGuarini]

@cekvenich yes I like it "Powerful UI DOM components library with elegant and clean syntax"

[sylvainpolletvillard]

@GianlucaGuarini my understanding of _powerful_ for a JS library is _full-featured_, which contrasts with _minimalistic_. I think a more suitable word would be _flexible_ or _extendable_ ; otherwise vanilla JS is the most powerful choice out there :wink:

[cekvenich]

That is good: 'Powerful UI DOM components library with ?'
I would like to avoid 'and' if possible. Pick one: elegant, conscie or clean or flexible or something. They are all similar w/ shades of difference, it's just an adjective. So just one adjective at the end.

I think it's good - and great is the enemy of good, it's in the ballpark.
To me it was important that it works now and it's cross browser, by encapsulating it helps control the html sprawl. and out of the box it's Sass, one of few components that works w/ designers. Powerful UI DOM components library that works - maybe to plain.
Powerful UI DOM components library that is flexible?
Powerful UI DOM components library with concise syntax?
Powerful UI DOM components library. (+ add some css transition effect to 'cycle' 4-5 adjectives at end - using REACT to do it :-) - or just a statement:

RIIOT v3. Powerful UI DOM components library.

[corps]

This may not be be a popular opinion, but I strongly feel that RiotJS's strengths are about what it is not more than what it is. And I feel those decisions do have, you know, meaningful trade offs. "This is the best view library ever!!!" isn't convincing to a veteran with a skeptical eye to new approaches to old problems.

1. It's the lack of flexibility (not as expressive as JSX with arbitrary javascript expressions, not the full requirements of the web component spec) that actually makes the implementation and usage of RiotJS simple.
2. It's the lack of power (no on-boarded unifying event system for supporting browser incompatibilities, lack of key support in iteration) that makes it less to learn for beginners. The assumptions are simple and few.
3. It's less javascript and more just HTML directives.

If anything, the thing that sold me to use RiotJS instead of other view libraries had more to do with a specific use case that RiotJS excels at and View.js / React don't really even bother to address: views for mid sized Rails apps where the majority of developers are not front end developers.

Easy interlopability with server side rendered elements? Check.
Mostly just HTML syntax with a handful of the most important directives? Check
Can play well with that janky rails-jquery component pulled in by a gem you don't have time to replace? Check.
Documentation in Japanese? Well that's just icing.

[corps]

To follow up more productively, I'd like to say this tagline about RiotJS:

"The 80% of web components you need in a small api surface."

[sourcegr]

Just some thoughts based on the strong points of RiotJS (as I see them)

The "Web Apps in a flash" micro library
Pure javascript, concise syntax, blazing fast
All you need to know, you know it allready <-- this is very important, all other frameworks demand you learn a lot of new things and follow their syntax! I Believe we should focus on making a good tagline about this

[chrishandorf]

See the bottom of the following page comparing vue.js and riot. Any comments on the validity of the vue.js advantages?
https://vuejs.org/guide/comparison.html

[cekvenich]

I feel they are comparing MVC framework to a Web Component lib.

Nothing you can say to help them. You can us any WebCompoent w/ any framework. Ex: Riot w/ Flux, HTML5 web components w/ Vue. Like you can use Bootstrap or Material Design (MUI) w/ Riot. But RIOT does not compare to CSS or frameworks.

[chrisvfritz]

@cekvenich That's actually not accurate. Vue only deals with the V in MVC, like React and yes, Riot. Unlike React, both Vue and Riot can also be used to progressively enhance the page with custom components by just dropping in the respective library, with no compile step. If you still find unfair comparisons after learning more about Vue, there's a link to submit a pull request at the bottom of the page.

[GianlucaGuarini]

Thanks to anyone for the great feedback I will update the project description when riot@3 will be released. I am locking this topic because I feel it's getting too far from my original question.

p.s.
Riot and Vue are two great frameworks I really like Vue and the comparison on their site is fair and it might be updated when riot@3 will be released. However despite the 1000 articles, blog posts, opinions and comparisons about frontend stuff I strongly recommend anyone to pick one of the frameworks you like most, test it, and then decide if it fits better to your workflow/codestyle and does good the task you need to achieve.