Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tuxedo.js – A Framework Built on React and Flux

tuxedojs.org

Post reply on HN
Print view View original

71–80 of 90 posts

Re: Tuxedo.js – A Framework Built on React and Flux

#71

Post by mwillmott »

I'm generally in favour of people releasing more frameworks and showing off work like this. We're not being forced to use it and at the very least it allows us to see and understand other peoples thinking and approaches to new concepts like Flux.

With Marty.js posted the other day (https://news.ycombinator.com/item?id=8923053) and, having spent a while looking at that, i'm interested to know if the motivations for creating the two are broadly the same? Are they taking similar approaches or are there fundamental (or subtle) differences? This is something i'm struggling to understand so would appreciate other input.

Re: Tuxedo.js – A Framework Built on React and Flux

#72

Post by Gigablah »

nkozyra wrote: post #39
moe wrote: post #2

The javascript community seems to live by the motto "A framework a day keeps the doctor away". Is anyone keeping count, we must be in the hundreds by now?

I think this is because creating a Javascript framework is easier than creating a framework in other languages - clientside or otherwise. Note: I didn't say making a good framework was easy, just making one at all. Sometimes people just decide to experiment, to try something and then as they grow with it they think it's big enough to share. When a whole bunch of people do that, you end up where we are with JS framewo…

> The other ones are mocked into oblivion

This should not be the "natural order" of things.

https://news.ycombinator.com/item?id=5106767

Re: Tuxedo.js – A Framework Built on React and Flux

#73

Post by goatslacker »

andybak wrote: post #69
goatslacker wrote: post #44

Earlier quoted context omitted.

It doesn't have to be that way. These lessons are no substitute for server side rendering although with more frameworks supporting isomorphism out of the box this will hopefully be a thing of the past.

My only issue with 'isomorphism' it it forces me to use javascript on the server. As much as javascript isn't the worst language in the world, I'll never be happy with to live in a world where it's the only language.

The interesting bit of isomorphic applications isn't the fact that you can use JS on the server. For me, it's that you can keep all your UI and UI-related logic written in one language, and have your business logic, data fetching, and everything else in whatever language you prefer.

This has many benefits like code reusability and not having to write placeholders/render code twice -- in two different languages.

Re: Tuxedo.js – A Framework Built on React and Flux

#75

Post by thoman23 »

andybak wrote: post #69
goatslacker wrote: post #44

Earlier quoted context omitted.

It doesn't have to be that way. These lessons are no substitute for server side rendering although with more frameworks supporting isomorphism out of the box this will hopefully be a thing of the past.

My only issue with 'isomorphism' it it forces me to use javascript on the server. As much as javascript isn't the worst language in the world, I'll never be happy with to live in a world where it's the only language.

Thank you! I will never understand this push towards "isomorphism". Why do you want to use more javascript? I use javascript because I have to, not because I want to. I love being able to work in the language of my choice on the server.

Furthermore, I'm not convinced it's a good thing to blur the lines between client and server. Or in other words, I think it's a good thing for the developer to be thinking about the differences and the ramifications of code on the client vs. code on the server. The whole thing reminds me of the EJB days, where we were sold on the idea of not having to think about the implications of local vs. remote objects. In reality, no matter how you hide it in the syntax, those kinds of distinctions have consequences, and treating client code like it's server code or vice versa just seems like a bad idea to me.

Re: Tuxedo.js – A Framework Built on React and Flux

#77

Post by cheerazar »

davidlumley wrote: post #26

The index is missing some content on Safari thanks to an error (OS X, 8.0.2, private browsing enabled): > InvalidCharacterError: DOM Exception 5: An invalid or illegal character was specified, such as in an XML name. Seems like an useful combination, but doesn't make me feel great when it's got an error on a mainstream browser.

Looks to be fixed now. Thank you for alerting us to the issue!

Re: Tuxedo.js – A Framework Built on React and Flux

#78

Post by riffraff »

andybak wrote: post #38

To all the 'oh noes - another framework people' - there's a pattern here. We're going through a transition that isn't complete. (I might have the details wrong but here's the flavour) Backbone was a good start - Ember and later angular offered to fulfil a genuine need but after a long period of bedding in, many people have become dissatisfied with them. React (and a few similar frameworks that appeared around thw sam…

unless of course it's just the CADT model all over again.

Re: Tuxedo.js – A Framework Built on React and Flux

#79

Post by laichzeit0 »

mattgreenrocks wrote: post #55
lhorie wrote: post #53

Earlier quoted context omitted.

I recall reading about this idea of "exponential creativity". I don't remember if that was the actual term used in the article, but it was basically this idea that given a problem, you can incrementally come up with better solutions (e.g. add 9's to the end of a number to make it bigger), or you can take a leap out of that box and come up with a new class of solutions that completely outdo the old way of doing things…

The big problem is that OSS market rewards bloated frameworks/high commit rate/hype over careful, minimal design. Devs are unable to separate hype from technical excellence. I'm not sure many developers even skim the code of their favorite frameworks. Essentially, they're selecting OSS based on the exact same criteria used by the enterprise companies: * "I'll go with Angular since it's supported by Google" * "When I'…

> Ultimately, OSS is a poor vehicle for R&D because the market is every bit as dysfunctional and short-term-gain-seeking as the real market.

My biggest problem is I don't want to invest time anymore keeping up with the latest technology fad. I still write Perl code for this very reason, I invested the time, and it's "good enough" for most problems.

The second biggest problem is the maintenance of software developed using a fad technology. As often happens when I've used something cool it ends up biting me in the ass when a year or two down the line I have to go back and make code changes and the framework/library is no longer maintained, breaks in newer browsers, etc. because people have moved on to something newer and better.

I seriously question the long-term return on investment using new web technologies these days and am very apprehensive about willy-nilly investing time learning and using them until they've gained a significant amount of traction.

Re: Tuxedo.js – A Framework Built on React and Flux

#80

Post by tycho01 »

nilliams wrote: post #61
intrasight wrote: post #56

Twenty thousand lines of code to make a todo list - congrads. And crashes Emacs when opened due to that last line being tens of thousands of characters long.

What are you referring to?

TuxxTodoApp has its JS 'compiled' into the bundle.js, that apparently somehow reached 20k lines.

Interestingly, the user-written code (around 175 lines) appears to make for less lines than the Angular one. It seems that doesn't happen much, so to me that plus this using React makes it seem notable.

Then again, Tuxx using FB's React + Flux without otherwise having affiliation with FB may raise questions about how well FB (React/Flux) will play with them in the future...

Post reply on HN