Live data from Hacker News

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

muut.com

141–150 of 222 posts

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

#141

I would like to see more documentation about how to accomplish some of the benefits of web components with Riot.js, such as the ability to style your custom components without having those styles influenced by the host page's CSS and the ability to selectively theme nested elements with things like /deep/ and ::shadow.

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.

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

#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 written in... well... a real language with types and good tooling and real design patterns. The result is an application you can maintain and build upon for a long period of time rather than a heap of web cruft that collapses quickly under its own weight.

I know it's not sexy, but I've had the same experience you've had with "sexy." I'm becoming generally disillusioned with weakly typed and even dynamically typed languages -- they're fast to write but hard to maintain over long periods of time.

http://www.gwtproject.org

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

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

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

#144

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)

Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily.

Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.

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

#145

"Riot is React + Polymer + models + routing without the bloat." It is not + React. It's - React. It lists as one of its features, for example, a lack of a component lifecycle API (componentDidMount, componentWillMount, etc). This lifecycle API is one of React's best and most usable features. I can't give too much credit to a "tiny library" if it achieves its size by removing even the most basic features of other proj…

I want to continue from my earlier (hasty) response. I was on mobile and don't enjoy typing there. What I want to emphasize is that you can build custom tags without knowing much how Riot works. Just put together HTML and JavaScript. No need to know about `getInitialState`, `render`, `this.state` etc.. I wanted to create a tag definition syntax that is easy to learn and remember. There are lifecycle events if you wan…

> I'm also not a fan of `shouldComponentUpdate`. Ideally you should not think about such things and let the underlying library take care of the performance issues.

In my experience with React, something like this is absolutely necessary for performance once your data model gets to a certain scale. Does Riot have an equivalent? I agree that you shouldn't have to think about that stuff, but the reality is that sometimes you need that extra bit of performance.

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

#146
The amount of negativity and grilling is overwhelming here.

Riot addresses all of my pain points about frontend javascript frameworks by not being one yet offering the essentials.

The file size is absolutely essential. ~100kb to load Angularjs in your browser is crazy and to have to wrestle with framework specific learning curve.

My only concern is will the learning curve be brutal as Backbone.js?

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

#147

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-cognitive-lo... ) and there are slides for a presentation I gave a while back that talks about the design decisions that went into Mithril to reduce learning curves. (here: http://lhorie.github.io/mithril-presentation-oct-js-tech-nig... )

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

#148
post #144

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)

Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily. Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework.…

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't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.

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

#149
post #125

Earlier quoted context omitted.

Definitely some similarities exist like you listed. Riot offers following to the (massive) client-side table: 1. Custom tags (with unscary HTML + JS syntax) 2. Minimalism (both size and API surface) 3. Performance (minimizing DOM operations with virtual DOM) The 3rd item is not battle-tested / benchmarked yet and there is probably room for improvements.

I love the differing thought patterns apparent in the length of your and lhorie's response to this question. Like the framework, this response is minimal.

To be fair, you can get all 3 of those w/ Mithril. If you want a good comparison, the devil's in the details :)

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

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

You should also look at Dart. It has a very fast iteration cycle and is a much nicer language that Java (in my very biased opinion - I worked on Dart).
Post reply on HN