Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Riot – A React-like, 2.5K user interface library

muut.com

Post reply on HN
Print view View original

211–220 of 222 posts

Re: Riot – A React-like, 2.5K user interface library

#211

Post by RussianCow »

iopq wrote: post #206
RussianCow wrote: post #158

Earlier quoted context omitted.

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.

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 li…

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.

Re: Riot – A React-like, 2.5K user interface library

#212

Post by iopq »

RussianCow wrote: post #211
iopq wrote: post #206

Earlier quoted context omitted.

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 li…

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 b…

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.

Re: Riot – A React-like, 2.5K user interface library

#213

Post by MrDom »

iopq wrote: post #212
RussianCow wrote: post #211

Earlier quoted context omitted.

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 b…

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 o…

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! :)

Re: Riot – A React-like, 2.5K user interface library

#214

Post by rapind »

tipiirai wrote: post #199
lhorie wrote: post #147

Earlier quoted context omitted.

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…

Mithril "HTML" syntax is not for my taste: return m("html", [ m("body", [ m("input"), m("button", "Add"), m("table", [ m("tr", [ m("td", [ m("input[type=checkbox]") ]), m("td", "task description"), ]) ]) ]) ]);

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"

Re: Riot – A React-like, 2.5K user interface library

#216

Post by karmakaze »

curveship wrote: post #94

Question: do I read your compiler right, that any line starting with 'var', 'function' or 'this' is assumed to be javascript? So for instance: How will riot.js compile this line? 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 compi…

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.

Re: Riot – A React-like, 2.5K user interface library

#217

Post by [deleted] »

karmakaze wrote: post #216
curveship wrote: post #94

Question: do I read your compiler right, that any line starting with 'var', 'function' or 'this' is assumed to be javascript? So for instance: How will riot.js compile this line? 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 compi…

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.

[deleted]

Re: Riot – A React-like, 2.5K user interface library

#218

Post by karmakaze »

karmakaze wrote: post #216
curveship wrote: post #94

Question: do I read your compiler right, that any line starting with 'var', 'function' or 'this' is assumed to be javascript? So for instance: How will riot.js compile this line? 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 compi…

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:

  (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.

Re: Riot – A React-like, 2.5K user interface library

#219

Post by jbellsey »

tipiirai wrote: post #189
evmar wrote: post #134

Earlier quoted context omitted.

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.)

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!

Post reply on HN