Live data from Hacker News

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

muut.com

161–170 of 222 posts

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

#161
post #143

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)

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'm sorry for coming across as a dick, but the idea that you "wasted" time learning a framework that became obsolete is silly to me, and it seems to be a common sentiment.

Ask yourself: at the time you used prototype.js, did it save time on the project?

If you answered Yes, then it was never a waste of time. Knowing prototype.js AND jQuery makes you a better developer: you learned the hard way that abusing prototypes can lead to hard-to-understand code. That can only be a good thing!

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

#162
post #154

Earlier quoted context omitted.

It goes both ways. By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved. For each feature you need, you either have to create your own solution, or manually integrate a bunch of smaller libraries. On the other hand, committing to an established framework means you have to work around issues that the framework was not designed to solve. I wouldn'…

> the more complex and unique your problems are, the more it makes sense to roll your own. Of course, everyone thinks their problems are complex and unique.

How many data points do you need to uniquely represent every person in earth? I bet its a smaller number then the number of constraints and requirements in your system.

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

#163
post #161
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'm sorry for coming across as a dick, but the idea that you "wasted" time learning a framework that became obsolete is silly to me, and it seems to be a common sentiment. Ask yourself: at the time you used prototype.js, did it save time on the project? If you answered Yes, then it was never a waste of time. Knowing prototype.js AND jQuery makes you a better developer: you learned the hard way that abusing prototypes…

No, you're not being a dick. You're right — it definitely made me a better developer. To my memory I didn't switch because of a particular lack of a feature or features, but because jquery was being maintained more consistently.

Community support makes such a big difference, and now that I'm further down the line I'm averse to having to basically make a bet up front.

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

#164
post #142

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 echo your sentiments about disillusionment with weakly typed/dynamically typed languages and I still haven't really reached a situation where I was glad I didn't have a type system backing me.

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

#165
post #142

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…

"real language"...

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

#166
post #114

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…

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.

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

#167
post #142

Earlier quoted context omitted.

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…

"real language"...

Not saying Java is the best language ever, just that it passes a certain minimum bar that JavaScript does not.

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

#168
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.

Isn't that basically rolling your own framework? :)

shrug Personally, I don't see it that way. Frameworks are more generalized and reusable. They tend to be so large because they have to take into account a wider degree of problems. Applications with custom architectures and some external libraries are very specific and not typically reusable. Maybe it's just a matter of degrees.

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

#169
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…

Where does Mithril fit in this stack: RequireJs, Knockout (with components), SammyJS (for routing/browser history and events)? --After doing some reading it looks like it replaces some of knockout and sammy but I'd lose data binding and dependency tracking of knockout.

Mithril is roughly equal in scope to Knockout+Sammy. The small gap between what most frameworks call "bidirectional data binding" and what it actually is in terms of vanilla js can be bridged with simple functions (I talk about that in a slightly more advanced context here: http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi... ).

Dependency tracking can refer to two things: tracking changes for the purpose of updating the DOM (which Mithril does handle, albeit in a different way), or computed properties (which I personally think are not a good idea, but that you could do w/ an observable library from microjs)

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

#170
post #142

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…

If you want a "real" language with types and whatnot, there's js_of_ocaml.
Post reply on HN