I'm really not sure about the "problems" with React being described.

Minified at 124k. Sure, but with gzip that's absolutely negligible. Unless your app utterly tiny, 124K is nothing (the version of React with addons is 38K gzipped/minified).

I'm not sure what they're going on about with React's dirty checking - all of that stuff is override-able, and things like batching are just a sane way of doing DOM updates.

The verbosity, I'm not seeing it - sure there's JSX, but you mitigate this by abstracting components so you're building out of high-level components that mean that the complexity is only shown where it needs to be.

JSX is also far nicer and more explicit than using HTML templates, and brings a lot to the table, especially with 0.12, including ES6-style patterns that work really nicely for describing a structure of components.

Also, not sure about the "boilerplate". What are they talking about?

    React.createComponent({ render(){ return <span/>; });

No boilerplate there.

There's not even that much to remember, aside from the component lifecycle, some handy utilities, and a few useful addons.

There are some more complicated but optional things like PropTypes (not necessary at all, but a nice way to provide type requirements for your component's properties) and contexts (which is at current undocumented and a bit weird, but that's not really an official feature).

Unless you are building apps that are utterly tiny, none of this makes sense.

Looking at Riot2, it looks very implicit and magical - how do we know where the HTML ends and the script starts? How do you break your logic apart and have any sort of code re-use?

And for a "non-framework" it certainly seems to deviate from HTML + JS quite a bit.

> Minified at 124k. Sure, but with gzip that's absolutely negligible. Unless your app utterly tiny, 124K is nothing.

Well React is just a view engine so you have to combine it with something else, usually a flux implementation. Then if you want to make things even easier you throw in ImmutableJS which is not small either. Or you might just use Omniscient which wraps this all up into a nice package.

But by this point you're close to 400k pre-gzip. That's gigantic compared to the competition. IIRC MercuryJS (which has a VDOM and Immutable data structures) is like 40k. Mithril (which is an MVC VDOM library) is 15k.

It's worth remembering that the company behind Riot are a 3rd party provider delivering components to host websites. These websites already have jquery/angular/whatever in their own payload, and Moot won't be the only resource they are pulling into their page.

In that context, you can see why reducing size is given such a priority. I can assure you, tags that don't take such measures can have a catastrophic affect on your site's performance.

Sure, I can answer.

I think 124Kb does matter a lot. It's not just about the download size but several other things as well:

1. Code size. More vulnerable areas for bugs. Bigger stack traces.

2. Execution time. Scripts are not images. They block the page. And you cannot just remove them from the page like you can do with images.

3. On mobile bits and CPU cycles matter significantly more.

Boilerplate.

Look for the example on this page:

https://muut.com/riotjs/compare.html

and you can see that little things add up.

I'm going to update the compiler so that HTML ends on the last tag and if you want to be explicit you can wrap the logic inside a script tag.

You clearly love React and it works for you. The article is about the issues we had and how Riot solved them.

Could you answer a few of the parent's questions, though?

We know that the article is about your issues, but we're curious to hear why these seemingly insignificant issues mattered to you.

An aside but I became curious when riot was mentioned two days in a row, first thing in the east-coast morning, submitted by the same author.

While self-promotion is a skill, the submitter's comment and submission history is painfully focused exclusively on their own work.

I can certainly appreciate being proud of the things you build—that's great—but it comes across as disingenuous when it is quite literally the only thing you contribute to the discussion.

That's indeed the case. I basically code my own things and then release them as open source. jQuery Tools, Head JS and now Riot.js 2.0 to name the biggest contributions.

HN is an unique place to get feedback for your own work. I certainly have opinions about others work as well but usually I keep my mouth shut and go back to work.

Having the confidence to release your projects as open-source is excellent and something I wish more people had.

However—by your own description—HN is a place where you solicit feedback but can't be bothered to extend the same courtesy to your peers.

Think of it like a conversation. If I approach you asking for feedback on my projects but never return the favor, does that not seem suspicious?

In fairness, open sourcing a project is quite a big courtesy to begin with, and providing a website, support, documentation, etc is much more of a commitment than leaving a comment on HN.

There are more than enough people on HN providing huge amounts of feedback about everything they can at the slightest opportunity. I don't think that tipiirai's contributions are sorely missed.

I think you aren't being nice trying to teach him manners. Having others already upvoted this submission we can move over this 'incident', can we?

I tend to give feedback on a form of GitHub issue. It's more focused and the discussion doesn't explode.

For my own projects I like to get all the rants as well. Gives a broader picture. I have a feeling that HN doesn't have a very strict etiquette.

Fair point.

To be clear, I take nothing away from what you've done here: More tooling options are rarely—if ever—a bad thing and your presentation of riot is beautiful and clear, very well executed.

We're Finns afterall. https://www.youtube.com/watch?v=DvidoBBJSRA

I don't think this is necessarily bad in this case. It's quite normal for busy people to focus on their work, many YC startup founders do the same.

The first submission has caused quite a hot discussion, so submitting again the next day isn't overkill IMO.

Well Tero's fiercest opinions typically take the form of code :)

Riot 2.0 was completed and submitted yesterday after lunch (Finland time), blog post was completed today at the same hour. We genuinely felt they were worth telling the world about and people seem to agree.

I am not sure why it's becoming popular to say "It’s unacceptable that the underlying framework is bigger than the application itself." If your domain specific implementation is smaller than the framework itself, it means the framework did exactly what it was supposed to do, it reduced the amount of work you had to do to implement your app.

it is really unacceptable when your app can do without it - and that's Riot is trying to prove. It doesn't mean to hurt your feelings.

I agree that it is unacceptable/irresponsible in a way to have a larger payload than is necessary, but I think that is a different issue. Something like selective importing only what you need from the framework vs. the whole shebang.

That's another way of staying minimal, but still, the library makers get to maintain that pile of rarely used features and that may slow down development, delay releases.

There was a discussion of Riot yesterday: https://news.ycombinator.com/item?id=8928433

I can see Riot taking it's fair share of the market with the websites that have not-so-complex structure and can benefit from code/size optimization, like various search engines, sharing apps, financial tools, etc.

The key here would be faster than React sever-side rendering - isomorphic apps seem to be the uprising trend at the moment.

I am not sure I see the value over React yet, but the more experiments in the field we have, the better we collectively are. So thanks a lot for building and open-sourcing this.

Is there a non-trivial example of a Riot project that we can look at the code for? My confusion is around conditionals. The documentation says:

   In Riot the HTML structure is fixed. Only loops and conditionals can add 
   and remove elements. But a div cannot be converted to a label for example. 
   Riot only updates the expressions without complex subtree replacements.

   "Currently if is implemented with CSS display property as well". 

Considering this, how would I implement a page that has to show two completely different components based on a form input?

Seems like you'd have to include all possible components and toggle them based on a variable.

It doesn't seem like you can apply an if attribute to a component directly - the second component here never disappears, but the first is wrapped in a <div> and does:

http://bl.ocks.org/insin/5e0bf04cf1f701c235ad

Thanks a lot, this clarifies it. Having only CSS based hiding of components (and only if wrapped within a div) is a bummer. I am curious to know how the authors plan to work around it for serious app development.

Like this

<my-tag>

  <nested-tag1 if={ parent.val }/>

  <nested-tag2 if={ !parent.val }/>

  <input oninput={ edit }>

  edit(e) {
   this.val = e.target.value
  }

</my-tag>

Thanks for responding.

You might want to look at insin's comment above. In insin's code example, the conditional doesn't work on a component, but does on a normal HTML tag. Would that be a bug?

The lack of true conditionals is a turn-off for me. React's conditionals lets you build things like react-router without any extra semantics, in which the router picks up the appropriate component based on the URL.

On the child component you refer the parent data with `parent.` prefix.

Toggling display of child components with an "if" attribute doesn't work if I change the expression to parent.component either - evaluating a component attribute declared in a parent in the context of the child is pretty surprising, if that's what happens.

It seems like using a value attribute on a <select> doesn't set the selected value, I had to manually set selected on the <option>s to get it to work, and updating the value from elsewhere doesn't seem to affect the selected option either way.

Checkbox events are throwing "SyntaxError: function statement requires a name".

Wrapping the display of the disabled value in () instead of [] throws "SyntaxError: missing formal parameter" on load.

Updated gist showing these here: http://bl.ocks.org/insin/5e0bf04cf1f701c235ad

I don't see any docs on using forms - is support for form elements still a work in progress?

> To some extent we questioned whether anyone needed a framework at all.

This is the #1 saddest trend in software today. I see it all the time.

Look, if you can't figure out what value people get from a tool, please don't bother comparing your thing to it.

Riot is compared to React mostly and React worked as an inspiration for it. We totally see the value in it. We have used it and still use it on production. Not sure if you have seen the React vs Riot 2.0 comparison:

https://muut.com/riotjs/compare.html

React isn't a framework.

I have been reading this since yesterday. Can you shed some light on how can you include jQuery plugins with VDOM support. Ractivejs [1] does it using decorators feature.

[1] http://stackoverflow.com/questions/23083841/ractivejs-and-jq...

Observation: I see JavaScript web component frameworks following what JSF invented some 10 years back, xhtml templates & Expression language for processing context.

Is the '{}' syntax configurable ? like jinja2 ? I would love to change it to '#{}' for making it consistent with EL.

Yup. In Riot the DOM is only updated when there is a diff.

Server side support is coming so you can do "isomorphic" apps and render components on the HTML page as string.

Current 2.0.1 does not support this feature.

Being able to render progressively to the response buffer would be great

Check the previous related submission (linked in this thread), there is the same comment as yours with answers.