81–90 of 222 posts
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.
Some people learn by reading docs, but I like the hands-on experience.
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.
1. simplicity
2. maintanability
3. API surface and learning curve
Riot also about minimalism, especially in syntax.
Less proprietary stuff (and keystrokes).
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.
https://github.com/muut/riotjs/tree/8c7e841e2c7724df9bab9397...
Rebrand?
That said, great work on this library! I'm impressed with how much functionality you guys have in such a small package.
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 vir…
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.
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'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).
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.
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.