181–190 of 222 posts
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)
Earlier quoted context omitted.
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 boi…
> 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 expe…
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).
Not to mention we've moved past code tags like "each={ item, i in items }".
Why would I even consider digging deeper without knowing the answers to those two questions?
Earlier quoted context omitted.
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 pa…
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.
Earlier quoted context omitted.
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.
Idea: require a 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 tags within HTML and does JS highlighting/indenting on their content.)
Earlier quoted context omitted.
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.
The compiler also fails if a multi-line comment doesn't end at the end of a line. 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 hairie…
Earlier quoted context omitted.
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.
Idea: require a 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 tags within HTML and does JS highlighting/indenting on their content.)
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 }".
Maybe have another look for Riot on a later time and you can perhaps see the reason for it to exist.