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

201–210 of 222 posts

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

#201

Post by saurabhnanda »

xmonkee wrote: post #181
saurabhnanda wrote: post #138

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)

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 ?

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

#202

Post by dopamean »

sanityinc wrote: post #197
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 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 pe…

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.

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

#203

Post by dopamean »

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"), ]) ]) ]) ]);

Agreed, it's not the best. Maybe you can help come up with something more palatable?

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

#204

Post by insin »

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

    return 
      
        
        Add
        
          
            
              
              task description
[1] https://github.com/insin/msx/

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

#205

Post by tipiirai »

insin wrote: post #204
tipiirai wrote: post #199

Earlier quoted context omitted.

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 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! return Add task description [1] https://github.com/insin/msx/

Definitely more readable than Mithril

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

#206

Post by iopq »

RussianCow wrote: post #158
MrDom wrote: post #156

Earlier quoted context omitted.

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.

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.

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

#207

Post by marrs »

tomphoolery wrote: post #173
state wrote: post #143

Earlier quoted context omitted.

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

    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.

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

#208

Post by nogridbag »

api wrote: post #142
saurabhnanda wrote: post #138

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…

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.

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

#209

Post by bleuarff »

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!

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

#210

Post by istoica »

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"), ]) ]) ]) ]);

yes man, this abstraction is horror, I hope mithril adheres to something else for declarative tasks a the one above
Post reply on HN