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.
Riot – A React-like, 2.5K user interface library
141–150 of 222 posts
Re: Riot – A React-like, 2.5K user interface library
#142I 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)
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.
Re: Riot – A React-like, 2.5K user interface library
#143I 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)
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
#144I 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)
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…
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
#146Riot 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
#147I 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)
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
#148I 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.…
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
#149Earlier 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.
Re: Riot – A React-like, 2.5K user interface library
#150I 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…