191–200 of 222 posts
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?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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.
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.
The implementation and syntax is different so it's not a drop- in replacement, but both have similar goals.
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.
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.
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.
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…
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 tokenizing after a concrete use case.
Definitely keep this in mind. Thanks!
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)
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-cogniti…
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 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 writ…
GWT can output to ExtJS, to , to . And barring minor changes, your code stays the same.
Now that is worth the investment.
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)
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-cogniti…
return m("html", [
m("body", [
m("input"),
m("button", "Add"),
m("table", [
m("tr", [
m("td", [
m("input[type=checkbox]")
]),
m("td", "task description"),
])
])
])