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)
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.
You should also look at Dart. It has a very fast iteration cycle and is a much nicer language that Java (in my very biased opinion - I worked on Dart).
I echo your sentiments about disillusionment with weakly typed/dynamically typed languages and I still haven't really reached a situation where I was glad I didn't have a type system backing me.
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.
I used GWT for a few years on two projects, but I would not use it on any future projects. The first was using GXT, which you should probably avoid for public facing sites.
We ran into some GWT compilation issues mainly due to code size a couple of times with some browsers, like Safari, that left us dead in the water until Google released an update.
The second project used vanilla GWT and we were very happy with how performant it was. But we avoided lots of GWT features which seem over-engineered and complicated. We used JSON overlay types instead of RPC calls (which made our compilation / or dev mode much faster - I forget honestly). We avoided MVP, because I never met anyone who actually fully understood MVP with GWT. Instead, we had a very simple MVC structure that worked great for us (but lacked unit tests..). We avoided most of the CSS features because the complexity/value wasn't favorable for us.
Moved on to a JS project afterwards and it was a breath of fresh air.
On the one hand I wish that the docs for these projects could speak to those concerns, but on the other hand I'm not even sure how they would do that successfully. When something is this young it just takes time to figure out how it's going to survive and be maintained.
I remember the days of using prototype.js over jquery. If only someone could have saved me the time.
I'm sorry for coming across as a dick, but the idea that you "wasted" time learning a framework that became obsolete is silly to me, and it seems to be a common sentiment.
Ask yourself: at the time you used prototype.js, did it save time on the project?
If you answered Yes, then it was never a waste of time. Knowing prototype.js AND jQuery makes you a better developer: you learned the hard way that abusing prototypes can lead to hard-to-understand code. That can only be a good thing!
No, you're not being a dick. You're right — it definitely made me a better developer. To my memory I didn't switch because of a particular lack of a feature or features, but because jquery was being maintained more consistently.
Community support makes such a big difference, and now that I'm further down the line I'm averse to having to basically make a bet up front.
> I remember the days of using prototype.js over jquery. If only someone could have saved me the time.
There was plenty of criticism from the JS world when Prototype came out, and the main issue everyone had was how Prototype attempted to shoehorn classical OOP into JavaScript (hence, the abuse of prototypes and fake class inheritance), which is a mistake amateur JS developers make to this day. jQuery has at least made it so using the most popular DOM abstraction framework didn't also mean you were running less-than-ideal code inherently, but developers still manage to mess this one up.
I think it's because when you learn how to program, you only learn the classical style, so you're not ready for the pitfalls of prototypal inheritance. So a lot of developers go through the "phase" of attempting to retro-fit their own ideas of how programming should work into a language that is designed in a totally different way, inevitably lead to problems, and have "the revelation" of understanding the prototypal inheritance idea. It's kind-of like a growing pain, which is why I'm really happy JS is being taught more heavily in schools and especially to entry-level programmers. Unlike Java, JavaScript is more accessible (just pop open the REPL in any browser) and its results are easier to observe. While it's not a great tool to teach people the concepts of OOP, I think it's very useful to teach kids at a young age that there isn't just one way to do things. They're different enough to screw developers up on a day-to-day basis, but not different enough that spending a few weeks with the language isn't enough to grasp its power.
As others have said, you really didn't waste your time there. If anything, it was simply a matter of JS developers collectively and simultaneously going through the same growing pains and eventual realizations about how the language works.
While it's not a great tool to teach people the concepts of OOP...
I actually think it's a very good tool for teaching OOP. It doesn't have types to confuse the issue, it favours composition over inheritance by design, and it fully encapsulates state.
You could do much worse than JS as a teaching language. In fact, I'd say that it was only through practical application in JS that I fully appreciated the concepts extolled by Smalltalk, Self, and Lisp. Had I worked in a Java environment I may not have had those insights until much later.
Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily.
Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.
It goes both ways. By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved. For each feature you need, you either have to create your own solution, or manually integrate a bunch of smaller libraries. On the other hand, committing to an established framework means you have to work around issues that the framework was not designed to solve.
I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.
I agree there. Deciding on tooling for a long term project is a very tough balancing act.
Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.
Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.
Yeah, that's completely fair. I generally work on projects with constantly evolving requirements, so I tend to roll my own framework(s) by gluing together existing libraries that each solve a specific problem very well. That approach works well for me because most of the time I simply don't know the long-term implications of using an existing framework for any given project, so it's easier for me to evolve my own as I go. But I think there are a lot of projects out there that benefit greatly from the ecosystem behind certain frameworks (Rails comes to mind) and don't run into many bottlenecks due to said frameworks. For them, assembling a foundation is totally unnecessary because there's an open source framework that provides exactly what they need.
I don't have enough experience in different types of environments to say which approach is most suitable in most cases, but I'll definitely say that using an existing framework is the safer path (you have a community to lean back on), and is also advantageous for hiring. So I think you're correct when you say that many developers are afraid of rolling their own frameworks, but I think there are good reasons for that, especially for quickly-growing startups.
One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.
How many data points do you need to uniquely represent every person in earth? I bet its a smaller number then the number of constraints and requirements in your system.
By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved.
You don't have to roll your own framework. You could always just use the micro-libraries that are ubiquitous in JS and pick an architecture that best fits your application. shrug to each their own. :)
Isn't that basically rolling your own framework? :) A "framework" doesn't have to be a huge 100k-LOC library--it can just be a set of conventions and design patterns with some code to enforce them--but you always need some kind of consistent structure in your application if you want it to be at all maintainable.
Isn't that basically rolling your own framework? :)
shrug Personally, I don't see it that way. Frameworks are more generalized and reusable. They tend to be so large because they have to take into account a wider degree of problems. Applications with custom architectures and some external libraries are very specific and not typically reusable. Maybe it's just a matter of degrees.
No, because a framework tells you where to put your code. It will say "put a handlebars file in application.hbs, this is the default, or you can override the default and load it manually" or something to this effect.
So a framework has that "convention over configuration" flavor, while libraries are explicit. You actually have to load the application.hbs file manually with a handlebars parser. Then you use another library for the router, etc.
Maybe we have different definitions for what a framework is, but I strongly disagree with the notion that frameworks have to be implicit and magical. Libraries solve specific problems; frameworks help you structure your code. That doesn't mean that your framework needs to automatically load files named a certain way, or magically call certain methods; it can just be a set of conventions that are optionally enforced by code.
I can't imagine the spaghetti that would result from not using any framework (even a tiny handmade one) and just throwing a bunch of libraries together.
What? By your definition object orientation is a "framework" because it "helps you structure code" and is "a set of conventions that are optionally enforced by code". That's not a framework, that's a paradigm!
If a framework doesn't do something implicitly it's just a large library. If it's a set of conventions not backed by baked-in logic, it's a style guide.
A framework must CALL YOU. It usually gives you a piece of code that loads itself and lets you customize what it does by passing your code/configs to it. Then you tell it to run with what you gave it. The parts of the framework that you call yourself are actually "plug-ins" or basically framework-specific libraries.
If the framework never calls your code and you only call into the framework, that's always just a library. I would argue that actually it's easier to conflate a very full-featured library with a microframework because both really kind of call your code (especially when it's in the form of closures or a DSL).
You would never accidentally call a framework a library, though, because it's obvious that it's handling things for you. It's running everything behind the scenes and you just kind of advise it to do the things you want.
A framework must CALL YOU. It usually gives you a piece of code that loads itself and lets you customize what it does by passing your code/configs to it. Then you tell it to run with what you gave it. The parts of the framework that you call yourself are actually "plug-ins" or basically framework-specific libraries.
I really like this description. I've been trying to come up with a better description of what a framework is and isn't and I kept falling short. This one works well. Thanks! :)
Mithril is roughly equal in scope to Knockout+Sammy. The small gap between what most frameworks call "bidirectional data binding" and what it actually is in terms of vanilla js can be bridged with simple functions (I talk about that in a slightly more advanced context here: http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi... ).
Dependency tracking can refer to two things: tracking changes for the purpose of updating the DOM (which Mithril does handle, albeit in a different way), or computed properties (which I personally think are not a good idea, but that you could do w/ an observable library from microjs)
Mithril is a tremendous little framework, and Leo has done an exemplary job of writing it, documenting it and blogging about usage patterns and tricks. While declining frequent requests that he cram more functionality into its core, he takes the time to explain the trade-offs, showing a deep understanding of the problem space which gives me confidence to build upon his work. So thanks Leo!
Hopefully, in time, more people will realise the "zen" of mithril's minimal approach. In the meantime, interested readers can check out lichess.org, which recently rewrote its impressive UI using mithril.
I work at a coding bootcamp and we recently used Mithril to teach one of our JS units. I was skeptical at first that it would be properly understood by novice developers... boy was I wrong.
Mithril is an awesome framework. A breath of fresh air really.
I did a quick tweak of React's JSX transpiler to output mithril-compatible code [1], as the above was the sort of syntax I was using JSX to get away from!
I think it starts to look like HAML / Slim / Jade once you use CoffeeScript. Understandably not for everyone, but I quite like it, and it doesn't mess with your syntax highlighting like JSX does.
m "body",
m "input"
m "button", "Add"
m "table",
m "tr",
m "td",
m "input[type=checkbox]"
m "td", "task description"
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.
Me thinks Mithril is fairly minimal, too, but this point can't be completely objective. If API allows to do things I find complicated to do myself, then I happily accept a little bloat here and there.
I will be looking at Riot custom tags and how they might help (or hinder) creating components out of functionality. There is currently an interesting discussion on the Mithril mailing list about these things. Also it's what attracted me to Angular long time back (and what drove me away from it, as well).
I love the differing thought patterns apparent in the length of your and lhorie's response to this question. Like the framework, this response is minimal.
- 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 ) and Mithril. It's basically "Web components, the good parts". Worth looking into.
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.
Should then be trivial to whip up a require.js plugin that leverages riot.tag for working on-the-fly in development, but which compiles during a build/optimize process.
"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.
Great link. Then I'm even more confused that it makes the point to say it doesn't have "componentDidMount," [but it just has something else instead]. To me, the mixed markup shown on that page is a bizarre way to express a component's rendered state. Just my personal opinion.
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.
> 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.
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.]
Confirmed. Just take the demo app and insert the line 'this is some text.' anywhere in it. It looks like it's particularly bad if you put it into a nested element: the compiler treats everything after the line (including html markup) as javascript.
The compiler also fails if a multi-line comment doesn't end at the end of a line.
<!-- a comment --> and more text
It outputs an empty compiled file.
My honest opinion is that you should consider rewriting the compiler in a classic tokenize-parse-compile style. Several projects (like mustache.js) have had to go through this evolution. Your current solution -- line-by-line with regexes and state flags -- will only get hairier and hairier.
Well, maybe a line-by-line solution is good enough, I mean, it would only target a subset but the code will be readable. I still think though that any compiler which is intended for real apps should do the classic tokenize-parse-compile steps.
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.)
This seems like a great idea, even if it's just optional tags that get ignored. With <script> you suddenly have a valid html fragment that should work with any editor.
I guess as is, a make could include a grep -v </?script> step.
Agree, removing the need for any special editor support would be great, even if offered as a compiler option. Makes the detection of JS a non-issue too.
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!
I tried making a simple dynamic page and failed repeatedly by attempting to put seemingly innocuous javascript in { } blocks. A simple case such as { platforms.join(' ') } works fine as where { technologies.map(function(t) {return t}).join('|') } does not. Until this is either fixed or (all limitations and work-arounds) documented, I consider this unusable for any real project.
(function(v) {
try {
v = d.technologies.map(d.function(d.t) {
d.return d.t
} finally {
return !v && v !== 0 ? "" : v
}
}).call(d), ").join('|') }"].join("")
There's two problems: (1) prefixing keywords with 'd.' which may possibly be solved by skipping keywords or with(d){...} and (2) the ").join('|') }" code became data.
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.
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.
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.
I agree that calling it "React-like" seems misleading. When I read about a 'x'-like library I expect something that could actually replace 'x' and provide nearly the same features.
Pete Hunt did a great talk on what actually makes React / virtualdom different from other databinding approaches.[1] Using this definition Riot.js looks a lot more like Angular, Ember et al. to me.
I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.
The difference between React and other databinding methods is that you can use all JS language features (i.e. if, for, while, .filter(), .map(), libraries like Rx.js, etc.) when defining what you want your DOM to look like.
Suppose I want to have a list of items based on some array, which I want to filter based on some predicate, and display the items differently based on their content type.
> I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.
Totally agree. While I do (most of the time) appreciate JSX, it is IMO the least interesting and relevant feature of React. It mostly just lets our company's designers continue to edit view templates that would otherwise be far beyond their training/experience. So that's nice, but it's not what makes React tick.
I somehow missed that (quite incredible, being one of the main subsections), and I simply assumed that you can't cram something like that in 2.5kb - I apologize.
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.
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.
Beware the way you're benchmarking, e.g. immutable structures and pure (& immutable-state-aware) components can make a pretty huge difference in react.
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.
By nested routes, you're referring to the kind of thing described by finchjs? How are they critical to your workflow? Would be interested to learn more.
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)
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.
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/
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?
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?
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.
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
> 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?
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.
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).
We certainly thought about rebranding. But since Riot 2.0 continues the minimalistic approach and "only" changes the way how views are assebled we thought the name can stay.
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.
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?
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"
The group releasing it has a drop in forums/commenting system called "Muut" that is fantastic. We needed a private forum system and it was one of the easiest integrations I've ever done. Really solid work.
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?
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!
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.
It would still be good for you to address this concern in your documentation since you claim that it's a replacement for Polymer. I would suggest providing a few examples of how one might accomplish CSS isolation on their own in a way that is 'good enough' for real-world use.
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.
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.
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?
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?
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'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.
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.
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.
This looks amazing! I work with angularjs, been testing reactjs, but this looks simpler and minimal to code ? Probably less documentation or community online ?!
I would say that a grid would be a great showcase, especially with custom column renderers and/or editors. That's a real stress test for any GUI system, update code, templating etc.
I've been funding CSS Grid implementation work for 2+ years so that eventually no one needs a framework for grid layout. Go play with it in Chrome and help squash bugs :)
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 }".
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.
> 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).
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?
They do seem to be getting closer to sanity with each one though. With the advancements in browsers, in a few years the experience of web development may not be completely awful!
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)
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
You should also look at Dart. It has a very fast iteration cycle and is a much nicer language that Java (in my very biased opinion - I worked on Dart).
I echo your sentiments about disillusionment with weakly typed/dynamically typed languages and I still haven't really reached a situation where I was glad I didn't have a type system backing me.
"real language"...
Not saying Java is the best language ever, just that it passes a certain minimum bar that JavaScript does not.
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.
If you want a "real" language with types and whatnot, there's js_of_ocaml.
The other advantage with GWT I see is.. as the target changes, your app doesn't have to, only the transpiler.
GWT can output to ExtJS, to <insert next HTML5/JS framework>, to <future platform>. And barring minor changes, your code stays the same.
Now that is worth the investment.
I used GWT for a few years on two projects, but I would not use it on any future projects. The first was using GXT, which you should probably avoid for public facing sites.
We ran into some GWT compilation issues mainly due to code size a couple of times with some browsers, like Safari, that left us dead in the water until Google released an update.
The second project used vanilla GWT and we were very happy with how performant it was. But we avoided lots of GWT features which seem over-engineered and complicated. We used JSON overlay types instead of RPC calls (which made our compilation / or dev mode much faster - I forget honestly). We avoided MVP, because I never met anyone who actually fully understood MVP with GWT. Instead, we had a very simple MVC structure that worked great for us (but lacked unit tests..). We avoided most of the CSS features because the complexity/value wasn't favorable for us.
Moved on to a JS project afterwards and it was a breath of fresh air.
This is so true.
On the one hand I wish that the docs for these projects could speak to those concerns, but on the other hand I'm not even sure how they would do that successfully. When something is this young it just takes time to figure out how it's going to survive and be maintained.
I remember the days of using prototype.js over jquery. If only someone could have saved me the time.
I'm sorry for coming across as a dick, but the idea that you "wasted" time learning a framework that became obsolete is silly to me, and it seems to be a common sentiment.
Ask yourself: at the time you used prototype.js, did it save time on the project?
If you answered Yes, then it was never a waste of time. Knowing prototype.js AND jQuery makes you a better developer: you learned the hard way that abusing prototypes can lead to hard-to-understand code. That can only be a good thing!
No, you're not being a dick. You're right — it definitely made me a better developer. To my memory I didn't switch because of a particular lack of a feature or features, but because jquery was being maintained more consistently.
Community support makes such a big difference, and now that I'm further down the line I'm averse to having to basically make a bet up front.
Well, there's opportunity cost to consider.
> I remember the days of using prototype.js over jquery. If only someone could have saved me the time.
There was plenty of criticism from the JS world when Prototype came out, and the main issue everyone had was how Prototype attempted to shoehorn classical OOP into JavaScript (hence, the abuse of prototypes and fake class inheritance), which is a mistake amateur JS developers make to this day. jQuery has at least made it so using the most popular DOM abstraction framework didn't also mean you were running less-than-ideal code inherently, but developers still manage to mess this one up.
I think it's because when you learn how to program, you only learn the classical style, so you're not ready for the pitfalls of prototypal inheritance. So a lot of developers go through the "phase" of attempting to retro-fit their own ideas of how programming should work into a language that is designed in a totally different way, inevitably lead to problems, and have "the revelation" of understanding the prototypal inheritance idea. It's kind-of like a growing pain, which is why I'm really happy JS is being taught more heavily in schools and especially to entry-level programmers. Unlike Java, JavaScript is more accessible (just pop open the REPL in any browser) and its results are easier to observe. While it's not a great tool to teach people the concepts of OOP, I think it's very useful to teach kids at a young age that there isn't just one way to do things. They're different enough to screw developers up on a day-to-day basis, but not different enough that spending a few weeks with the language isn't enough to grasp its power.
As others have said, you really didn't waste your time there. If anything, it was simply a matter of JS developers collectively and simultaneously going through the same growing pains and eventual realizations about how the language works.
I actually think it's a very good tool for teaching OOP. It doesn't have types to confuse the issue, it favours composition over inheritance by design, and it fully encapsulates state.
You could do much worse than JS as a teaching language. In fact, I'd say that it was only through practical application in JS that I fully appreciated the concepts extolled by Smalltalk, Self, and Lisp. Had I worked in a Java environment I may not have had those insights until much later.
Agreed.
Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily.
Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.
It goes both ways. By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved. For each feature you need, you either have to create your own solution, or manually integrate a bunch of smaller libraries. On the other hand, committing to an established framework means you have to work around issues that the framework was not designed to solve.
I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.
I agree there. Deciding on tooling for a long term project is a very tough balancing act.
Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.
Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.
Yeah, that's completely fair. I generally work on projects with constantly evolving requirements, so I tend to roll my own framework(s) by gluing together existing libraries that each solve a specific problem very well. That approach works well for me because most of the time I simply don't know the long-term implications of using an existing framework for any given project, so it's easier for me to evolve my own as I go. But I think there are a lot of projects out there that benefit greatly from the ecosystem behind certain frameworks (Rails comes to mind) and don't run into many bottlenecks due to said frameworks. For them, assembling a foundation is totally unnecessary because there's an open source framework that provides exactly what they need.
I don't have enough experience in different types of environments to say which approach is most suitable in most cases, but I'll definitely say that using an existing framework is the safer path (you have a community to lean back on), and is also advantageous for hiring. So I think you're correct when you say that many developers are afraid of rolling their own frameworks, but I think there are good reasons for that, especially for quickly-growing startups.
I couldn't have said it better myself :)
One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.
> the more complex and unique your problems are, the more it makes sense to roll your own.
Of course, everyone thinks their problems are complex and unique.
How many data points do you need to uniquely represent every person in earth? I bet its a smaller number then the number of constraints and requirements in your system.
By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved.
You don't have to roll your own framework. You could always just use the micro-libraries that are ubiquitous in JS and pick an architecture that best fits your application. shrug to each their own. :)
Isn't that basically rolling your own framework? :) A "framework" doesn't have to be a huge 100k-LOC library--it can just be a set of conventions and design patterns with some code to enforce them--but you always need some kind of consistent structure in your application if you want it to be at all maintainable.
Isn't that basically rolling your own framework? :)
shrug Personally, I don't see it that way. Frameworks are more generalized and reusable. They tend to be so large because they have to take into account a wider degree of problems. Applications with custom architectures and some external libraries are very specific and not typically reusable. Maybe it's just a matter of degrees.
No, because a framework tells you where to put your code. It will say "put a handlebars file in application.hbs, this is the default, or you can override the default and load it manually" or something to this effect.
So a framework has that "convention over configuration" flavor, while libraries are explicit. You actually have to load the application.hbs file manually with a handlebars parser. Then you use another library for the router, etc.
Maybe we have different definitions for what a framework is, but I strongly disagree with the notion that frameworks have to be implicit and magical. Libraries solve specific problems; frameworks help you structure your code. That doesn't mean that your framework needs to automatically load files named a certain way, or magically call certain methods; it can just be a set of conventions that are optionally enforced by code.
I can't imagine the spaghetti that would result from not using any framework (even a tiny handmade one) and just throwing a bunch of libraries together.
What? By your definition object orientation is a "framework" because it "helps you structure code" and is "a set of conventions that are optionally enforced by code". That's not a framework, that's a paradigm!
If a framework doesn't do something implicitly it's just a large library. If it's a set of conventions not backed by baked-in logic, it's a style guide.
A framework must CALL YOU. It usually gives you a piece of code that loads itself and lets you customize what it does by passing your code/configs to it. Then you tell it to run with what you gave it. The parts of the framework that you call yourself are actually "plug-ins" or basically framework-specific libraries.
If the framework never calls your code and you only call into the framework, that's always just a library. I would argue that actually it's easier to conflate a very full-featured library with a microframework because both really kind of call your code (especially when it's in the form of closures or a DSL).
You would never accidentally call a framework a library, though, because it's obvious that it's handling things for you. It's running everything behind the scenes and you just kind of advise it to do the things you want.
A framework must CALL YOU. It usually gives you a piece of code that loads itself and lets you customize what it does by passing your code/configs to it. Then you tell it to run with what you gave it. The parts of the framework that you call yourself are actually "plug-ins" or basically framework-specific libraries.
I really like this description. I've been trying to come up with a better description of what a framework is and isn't and I kept falling short. This one works well. Thanks! :)
FWIW, the framework I wrote (Mithril) is a direct product of working on a multiple-man-year Angular codebase and the pains that arise from such a beast. I wrote about that here ( http://lhorie.github.io/mithril-blog/lessons-learned-from-an... )
On a related topic, I talk about complexity walls (the idea of code that outgrows a framework's zone of comfort) here ( http://lhorie.github.io/mithril-blog/decreasing-cognitive-lo... ) and there are slides for a presentation I gave a while back that talks about the design decisions that went into Mithril to reduce learning curves. (here: http://lhorie.github.io/mithril-presentation-oct-js-tech-nig... )
Where does Mithril fit in this stack: RequireJs, Knockout (with components), SammyJS (for routing/browser history and events)?
--After doing some reading it looks like it replaces some of knockout and sammy but I'd lose data binding and dependency tracking of knockout.
Mithril is roughly equal in scope to Knockout+Sammy. The small gap between what most frameworks call "bidirectional data binding" and what it actually is in terms of vanilla js can be bridged with simple functions (I talk about that in a slightly more advanced context here: http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi... ).
Dependency tracking can refer to two things: tracking changes for the purpose of updating the DOM (which Mithril does handle, albeit in a different way), or computed properties (which I personally think are not a good idea, but that you could do w/ an observable library from microjs)
Mithril is a tremendous little framework, and Leo has done an exemplary job of writing it, documenting it and blogging about usage patterns and tricks. While declining frequent requests that he cram more functionality into its core, he takes the time to explain the trade-offs, showing a deep understanding of the problem space which gives me confidence to build upon his work. So thanks Leo!
Hopefully, in time, more people will realise the "zen" of mithril's minimal approach. In the meantime, interested readers can check out lichess.org, which recently rewrote its impressive UI using mithril.
I work at a coding bootcamp and we recently used Mithril to teach one of our JS units. I was skeptical at first that it would be properly understood by novice developers... boy was I wrong.
Mithril is an awesome framework. A breath of fresh air really.
Mithril "HTML" syntax is not for my taste:
return m("html", [
]);
Agreed, it's not the best. Maybe you can help come up with something more palatable?
I did a quick tweak of React's JSX transpiler to output mithril-compatible code [1], as the above was the sort of syntax I was using JSX to get away from!
[1] https://github.com/insin/msx/
Definitely more readable than Mithril
yes man, this abstraction is horror, I hope mithril adheres to something else for declarative tasks a the one above
I think it starts to look like HAML / Slim / Jade once you use CoffeeScript. Understandably not for everyone, but I quite like it, and it doesn't mess with your syntax highlighting like JSX does.
Ha ha ha, this is awesome. Thank you for writing this. You have to admit, benefits that are provided sound amazing, hard to look over.
It is interesting times for sure.
Nanda? Haha funny to run into you here. Kaisa chal raha hai?
I couldn't find out more about you from your HN username. Care to ping me on twitter @saurabhnanda ?
Hm. How does this compare to Mithril JS (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.
Definitely some similarities exist like you listed.
Riot offers following to the (massive) client-side table:
1. Custom tags (with unscary HTML + JS syntax)
2. Minimalism (both size and API surface)
3. Performance (minimizing DOM operations with virtual DOM)
The 3rd item is not battle-tested / benchmarked yet and there is probably room for improvements.
Thank you for your comment.
Me thinks Mithril is fairly minimal, too, but this point can't be completely objective. If API allows to do things I find complicated to do myself, then I happily accept a little bloat here and there.
I will be looking at Riot custom tags and how they might help (or hinder) creating components out of functionality. There is currently an interesting discussion on the Mithril mailing list about these things. Also it's what attracted me to Angular long time back (and what drove me away from it, as well).
Nothing in the Universe is completely objective
I love the differing thought patterns apparent in the length of your and lhorie's response to this question. Like the framework, this response is minimal.
That's one way to spin it.
To be fair, you can get all 3 of those w/ Mithril. If you want a good comparison, the devil's in the details :)
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 ) and Mithril. It's basically "Web components, the good parts". Worth looking into.
riot.mountTo() lets you "lazily" render a tag on a specific node.
Thanks for the analysis.
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.
Interesting, I missed that. But I assume that's not idiomatic, is it?
Should then be trivial to whip up a require.js plugin that leverages riot.tag for working on-the-fly in development, but which compiles during a build/optimize process.
"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.
Riot has lifecycle events.
https://muut.com/riotjs/guide/#tag-lifecycle
Great link. Then I'm even more confused that it makes the point to say it doesn't have "componentDidMount," [but it just has something else instead]. To me, the mixed markup shown on that page is a bizarre way to express a component's rendered state. Just my personal opinion.
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.
> 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.
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... (will be a series of posts, this is intro)
Question: do I read your compiler right, that any line starting with 'var', 'function' or 'this' is assumed to be javascript? So for instance:
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.]
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.
Confirmed. Just take the demo app and insert the line 'this is some text.' anywhere in it. It looks like it's particularly bad if you put it into a nested element: the compiler treats everything after the line (including html markup) as javascript.
The compiler also fails if a multi-line comment doesn't end at the end of a line.
It outputs an empty compiled file.
My honest opinion is that you should consider rewriting the compiler in a classic tokenize-parse-compile style. Several projects (like mustache.js) have had to go through this evolution. Your current solution -- line-by-line with regexes and state flags -- will only get hairier and hairier.
I'm aware of this. Just wanting to avoid going there at this point and hoping that a smaller regex- based thing can do it.
Well, maybe a line-by-line solution is good enough, I mean, it would only target a subset but the code will be readable. I still think though that any compiler which is intended for real apps should do the classic tokenize-parse-compile steps.
I'll start by improving the current implementation and see how far I can go with it without making it crazy.
I'll start tokenizing after a concrete use case.
Definitely keep this in mind. Thanks!
Issues logged for this, the multi-line comment termination issue, and for treating any line that ends with')' or '}' as javascript.
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.)
This seems like a great idea, even if it's just optional tags that get ignored. With <script> you suddenly have a valid html fragment that should work with any editor.
I guess as is, a make could include a grep -v </?script> step.
Agree, removing the need for any special editor support would be great, even if offered as a compiler option. Makes the detection of JS a non-issue too.
I can clearly see the benefits here. I'm also resistant to it because of the added syntax. Deciding later :)
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!
I tried making a simple dynamic page and failed repeatedly by attempting to put seemingly innocuous javascript in { } blocks. A simple case such as { platforms.join(' ') } works fine as where { technologies.map(function(t) {return t}).join('|') } does not. Until this is either fixed or (all limitations and work-arounds) documented, I consider this unusable for any real project.
Looking at the generated code:
There's two problems: (1) prefixing keywords with 'd.' which may possibly be solved by skipping keywords or with(d){...} and (2) the ").join('|') }" code became data.
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.
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).
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.
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.
Suspicion might be warranted if the page only discussed size. However, it lists many features.
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.
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.
It’s advertised as having a Virtual DOM.
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 :)
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.
Once you have loops, conditionals and recursion, don't you have "random HTML changes"?
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).
> 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)
As a point of reference, virtual-dom is 17k when minified with the same settings and 5.8k when gzipped.
That's starting from the 42k 1.2.0 distfile.
Riot virtual DOM is a simple expression -> DOM node map. It's much different than what React has.
Riot cannot make random sub-tree replacements. It's best for situations where the tag HTML structure is fixed (no tag name changes for example).
Riot virtual DOM minimizes the work and makes less DOM manipulations than React on each update cycle.
Loops and conditionals can change the structure.
I agree that calling it "React-like" seems misleading. When I read about a 'x'-like library I expect something that could actually replace 'x' and provide nearly the same features.
Pete Hunt did a great talk on what actually makes React / virtualdom different from other databinding approaches.[1] Using this definition Riot.js looks a lot more like Angular, Ember et al. to me.
[1] https://www.youtube.com/watch?v=-DX3vJiqxm4
Virtual DOM implementation is indeed different.
The biggest reason for calling it "React-like" is the basic idea of components, where related HTML and JS are combined together.
> "Build components, not templates"
http://www.slideshare.net/floydophone/react-preso-v2
I think this is the "what" of React and virtual DOM is the "how".
I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.
The difference between React and other databinding methods is that you can use all JS language features (i.e. if, for, while, .filter(), .map(), libraries like Rx.js, etc.) when defining what you want your DOM to look like.
Suppose I want to have a list of items based on some array, which I want to filter based on some predicate, and display the items differently based on their content type.
In a React render() function I would just use
to filter unwanted items, and
to map the individual items to how I want them to look like.
To me it looks like to implement something like this in Riot would require to build / use something that is more like Angular's computed properties.
But I'd like to be proven wrong.
In Riot you need to do following:
<my-tag>
</my-tag>
And you can also manipulate items on every update. I'm sure that at some point there will be a clear use case where React is a better choice.
So far Riot rendering has worked us perfectly.
> I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.
Totally agree. While I do (most of the time) appreciate JSX, it is IMO the least interesting and relevant feature of React. It mostly just lets our company's designers continue to edit view templates that would otherwise be far beyond their training/experience. So that's nice, but it's not what makes React tick.
>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.
Sorry, I don't follow. The Riot.js project site DOES tout "Virtual DOM" as one of its features.
You say it doesn't actually have that?
I somehow missed that (quite incredible, being one of the main subsections), and I simply assumed that you can't cram something like that in 2.5kb - I apologize.
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.
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.
> 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.
Yes. This is indeed a big challenge.
Maybe I can just use the TodoMVC app.
Yeah Matt Esch (virtual-dom) has a bench based on todomvc: https://github.com/matt-esch/mercury-perf http://matt-esch.github.io/mercury-perf/
Or http://evancz.github.io/todomvc-perf-comparison/ which seems to be an older version of the same bench but has a better output.
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...
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.
By nested routes, you're referring to the kind of thing described by finchjs? How are they critical to your workflow? Would be interested to learn more.
Which (if any) client side router library do you prefer then?
react-router, I assume.
See more on nesting: https://github.com/rackt/react-router/blob/master/docs/guide...
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)
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.
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.
One thing I like React is it is plain javascript.
Therefore I can use coffeescript to describe the component:
If Riot.js uses a custom parser, it may not be able to do this.
The above is not possible with Riot.
I still think that a declarative language is more suitable to describe the UI layout than a DSL built by non-declarative languages.
Wouldn't this be possible with some preprocessing pipeline?
This no longer works in React 0.12 because they changed the element creation syntax. :\
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/
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 [2] https://trello.com/c/6gwqvq5l/91-riot-integration
Looks nice. +1 for enclosing JS in a script tag.
Vuejs has a nice 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?
Need to consider the script tag.
I'm curious why a library which puts emphasis on a slim Virtual DOM implementation would go through the trouble of accommodating jQuery.
Seems more like Angular than React with the template expression, why compare it with React then ? Angular is now a dirty word ?
Angular has nothing to do with MVP, why would be compared to it?
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
Ember too, because of HTMLBars (DOM based templating) and FastBoot (later).
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?
Maybe you can find the answer from the comparison section:
https://muut.com/riotjs/compare.html
Thanks, in my haste I didn't see this. Helps a lot!
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.
React components written in JavaScript with embedded "JSX".
Riot components are HTML (mixed with expressions) + JavaScript.
Perhaps the HTML root element makes it look like "HTML-side only".
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
> 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?
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-...
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).
This seems way different than the library I remember 6 months ago...
https://github.com/muut/riotjs/tree/8c7e841e2c7724df9bab9397...
Rebrand?
We certainly thought about rebranding. But since Riot 2.0 continues the minimalistic approach and "only" changes the way how views are assebled we thought the name can stay.
It seems like their manifesto here hasn't really stood the test of time: https://muut.com/blog/technology/riotjs-the-1kb-mvp-framewor...
(The bits about jQuery at least, anyway.)
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.
For anyone who doesn't remember, Riot.js used to be a 1kb MVP library, https://news.ycombinator.com/item?id=7036274
I'm sorry :)
Shakes fist you will be ;)
This looks better though, IMHO.
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.
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?
Server side rendering is on the roadmap among other things. Look for the last item on the FAQ:
https://muut.com/riotjs/faq.html
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?
Welcome to the "Nobody was fired by hiring IBM" of the new century.
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"
And? Instagram's web app is still kinda crappy.
Dojo has also been used on a bunch of huge projects, but nobody gets excited about it...
The group releasing it has a drop in forums/commenting system called "Muut" that is fantastic. We needed a private forum system and it was one of the easiest integrations I've ever done. Really solid work.
Does this support nesting custom tags? How do I communicate between different tags? Is the opts variable accessible outside the definition of the tag?
Unlimited nesting is supported. You pass options with HTML attributes:
<parent>
</parent>
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?
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!
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.
Also the ability to easily broadcast events up and down the component hierarchy.
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.
It would still be good for you to address this concern in your documentation since you claim that it's a replacement for Polymer. I would suggest providing a few examples of how one might accomplish CSS isolation on their own in a way that is 'good enough' for real-world use.
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.
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.
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.
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?
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...
SVG should be no problem if loops and conditionals are enough for the logic. Never tried though.
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.
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.
Do you think that the 24x less code is because of its exceptional design? Or is it missing some features?
They have a different approach. There are some details under "Same but different" part of comparison to React. https://muut.com/riotjs/compare.html
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".
The design is vastly different. DOM update logic is more straightforward. We realized that heavy diffing is not needed.
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?
Looks very similar to ractive component spec: https://github.com/ractivejs/component-spec/blob/master/auth...
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
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.
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.
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.
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.
Earlier news about Riot.js: https://news.ycombinator.com/item?id=6653024
This looks amazing! I work with angularjs, been testing reactjs, but this looks simpler and minimal to code ? Probably less documentation or community online ?!
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.
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.
What happened to Riot 1.0 though?
Riot 1.0 started liking what React did to views.
I would say that a grid would be a great showcase, especially with custom column renderers and/or editors. That's a real stress test for any GUI system, update code, templating etc.
I've been funding CSS Grid implementation work for 2+ years so that eventually no one needs a framework for grid layout. Go play with it in Chrome and help squash bugs :)
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.
+1 for React to Riot converter
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.
Agreed. This is coming.
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 }".
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.
Is this the same Riot.js as the 1kb framework or is this just named the same?
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.
Ok, now I understand, sometimes there are several javascript projects with same name.
According to Google cache, it is. The size change may be due to rewrite (version 2.0):
> This is the biggest change from Riot 1.0 to 2.0. JavaScript and HTML are now part of the same module.
So impressed with both Riot and Mithrill! Thanks for sharing your work guys!
Great, another framework mixing concerns and doing custom HTML.
What's wrong with React?
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.
> 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).
A link to the github repo would be useful.
Here you go:
https://github.com/muut/riotjs
It's on the download page. Admittedly not very visible.
Should whack one of those "Fork me on github" ribbon things on there.
Ribbon is now there.
Thank you!
Maybe just watch me on Github.
seeing figures like 2.5K makes me think back to the days of programming assembly in 4K space on an HC12
it should be nice if it was like react( html in js)
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?
Oh a new Javascript framework. I'd been getting worried, it'd been 40ms since the last one.
Haha. No kidding.
On the other hand Riot is over 1 year old project and this is a new/improved version.
They do seem to be getting closer to sanity with each one though. With the advancements in browsers, in a few years the experience of web development may not be completely awful!
Well, Riot is pretty old... This is a major upgrade, and as such font-page-worthy I'd say.
Oh a dismissive comment on HN upvoted to the top. I'd been getting worried, it'd been 1 post since the last one.
Oh a strawman comment on HN...
Oh, a reddit meme on HN. I'd been getting worried. I hadn't seen one of those here yet.
Minimal usually means slow.