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

151–160 of 222 posts

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

#151

Post by [deleted] »

RussianCow wrote: post #148
v13inc wrote: post #144

Earlier quoted context omitted.

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

[deleted]

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

#152

Post by v13inc »

RussianCow wrote: post #148
v13inc wrote: post #144

Earlier quoted context omitted.

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

I agree there. Deciding on tooling for a long term project is a very tough balancing act.

Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.

Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.

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

#153

Post by yaddayadda »

muraiki wrote: post #69
yaddayadda wrote: post #26

Earlier quoted context omitted.

Maybe I'm missing something, but that comparison looks like apples versus oranges, or more specifically JavaScript-side versus HTML-side. The React example looks like the JS-side only, while the Riot example looks like the HTML-side only. What am I missing? edit: I see a touch of embedded script (i.e. handleSubmit) in the Riot example, but not nearly enough to replicate the JS code in the React example. And there is…

I haven't used React in about 6 months, but I'm pretty certain the Riot code does the exact same thing. If you haven't used React, it has JSX as syntactic sugar for what would otherwise be a bunch of javascript: see the "render" function in createClass. So a component is written in JS. With Riot, the JS goes into the template to create a component. There's a lot of things to like about React, but it requires some boi…

> If you want something that keeps the HTML and JS separate ...

I guess my JS knowledge is small enough that I just expect the HTML and JS to be primarily separated. (It seems like a best practice to me, but I haven't experimented with code that wasn't primarily separated, so I'm sure I'm missing some important insights).

Thank you for making the knockoutjs.com recommendation. For someone, with primarily Angular experience, who is looking to broaden their horizon, which of the three would you recommend as the next framework to learn: React, Riot, or Knockout?

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

#154

Post by orr94 »

RussianCow wrote: post #148
v13inc wrote: post #144

Earlier quoted context omitted.

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

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

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

#155

Post by stereosteve »

Looks nice. +1 for enclosing JS in a script tag.

Vuejs has a nice component compiler: https://github.com/vuejs/vue-component-compiler

It puts JS inside of a script tag, which would fix some of the parsing issues, and also fix syntax highlighting. It also provides hooks for pre-processors. Have you considered this approach?

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

#156

Post by MrDom »

RussianCow wrote: post #148
v13inc wrote: post #144

Earlier quoted context omitted.

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

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

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

#157

Post by RussianCow »

v13inc wrote: post #152
RussianCow wrote: post #148

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

I agree there. Deciding on tooling for a long term project is a very tough balancing act. Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spe…

Yeah, that's completely fair. I generally work on projects with constantly evolving requirements, so I tend to roll my own framework(s) by gluing together existing libraries that each solve a specific problem very well. That approach works well for me because most of the time I simply don't know the long-term implications of using an existing framework for any given project, so it's easier for me to evolve my own as I go. But I think there are a lot of projects out there that benefit greatly from the ecosystem behind certain frameworks (Rails comes to mind) and don't run into many bottlenecks due to said frameworks. For them, assembling a foundation is totally unnecessary because there's an open source framework that provides exactly what they need.

I don't have enough experience in different types of environments to say which approach is most suitable in most cases, but I'll definitely say that using an existing framework is the safer path (you have a community to lean back on), and is also advantageous for hiring. So I think you're correct when you say that many developers are afraid of rolling their own frameworks, but I think there are good reasons for that, especially for quickly-growing startups.

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

#158

Post by RussianCow »

MrDom wrote: post #156
RussianCow wrote: post #148

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

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.

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

#159

Post by v13inc »

RussianCow wrote: post #157
v13inc wrote: post #152

Earlier quoted context omitted.

I agree there. Deciding on tooling for a long term project is a very tough balancing act. Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spe…

Yeah, that's completely fair. I generally work on projects with constantly evolving requirements, so I tend to roll my own framework(s) by gluing together existing libraries that each solve a specific problem very well. That approach works well for me because most of the time I simply don't know the long-term implications of using an existing framework for any given project, so it's easier for me to evolve my own as…

I couldn't have said it better myself :)

One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.

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

#160

Post by easymovet »

lhorie wrote: post #147
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)

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.

Post reply on HN