8 ms·
Tuxedo.js – A Framework Built on React and Flux
- hmans 12y agoPlease stop.
- intrasight 12y agoTwenty 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.
- nilliams 12y agoWhat are you referring to?
- tycho01 12y agoTuxxTodoApp 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...
- boomlinde 12y agoThe site doesn't work and the error console is filled with javascript errors and 404s.
- moe 12y agoThe 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?
- wtetzner 12y agoI think it's probably a good thing for now. People are still trying to figure out how to do frontend programming well. Eventually one/a few good models will come out of the chaos, and some frameworks implementing them will start to stabilize. Of course, I have no idea how long that will take.
- callahad 12y agoI feel like the Ruby webdev community had a similar ethos, but I dropped out of that scene before things really coalesced. Can anyone comment on how things are playing out there?
- watty 12y agohundreds? I'd be surprised if we hadn't reached a thousand.
- deleted 12y ago[deleted]
- nkozyra 12y agoI 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 frameworks. I'm in the "it's no big deal" group. Are there thousands of frameworks? Yes. Have I heard of more than 5 of them being used extensively? No. The good ones are embraced by developers and shared. The other ones are mocked into oblivion. It's the natural order of things.
- aidos 12y agoOT I haven't looked at the lib yet (will do soon) and I know this is going to seem like a silly compliant but - on mobile the content of that page keeps moving around underneath me. It's incredibly frustrating!
- drabinowitz 12y agoYeah I apologize for that we are still working on a mobile friendly version of the site.
- solids 12y agoPlease, stop this framework madness.
- bringking 12y agoDoes Tuxedo have a plan for Isomorphic applications? I have been following the Yahoo fluxible project since it provides nice abstractions, but was designed for isomorphic apps out of the box.
- drabinowitz 12y agoCurrently we have been focusing on a purely client side implementation, that being said our features are largely built to extend React and Flux and that should put us in a strong position to work with Isomorphic apps down the line.
- goatslacker 12y agoYou should check out alt[1] and iso[2] which is isomorphic out of the box and it's pure flux. There are examples in both repos. [1] https://github.com/goatslacker/alt https://github.com/goatslacker/alt [2] https://github.com/goatslacker/iso https://github.com/goatslacker/iso
- bringking 12y agoThanks, those look great. Good work. Looks a little leaner than fluxible as well, which is always a plus
- Lazare 12y agoCoincidentally, I was just searching for a good Flux implementation for my first flux-style app, and something about alt really looks good. I think I'll give it a whirl. :)
- deleted 12y ago[deleted]
- fro 12y agoWhy is there is a five second animation to load a completely static home page?
- bonif 12y agobecause HTML is not sexy anymore... We're reinventing the old Flash (skip intro) web sites of the 90s, again ;-(
- nacs 12y agoThe "Feature" section (with links labeled "Graceful Degradation", "Semantic Action Creation", etc) are all 404s since they're missing the 'http://' http://'. The Graceful degradation link, for example, goes to http://www.tuxedojs.org/www.tuxedojs.org/docs/TuxModularity http://www.tuxedojs.org/www.tuxedojs.org/docs/TuxModularity instead of http://www.tuxedojs.org/docs/TuxModularity http://www.tuxedojs.org/docs/TuxModularity.
- sjfstebbins 12y agoThank you. We have made this adjustment.
- drabinowitz 12y agoThanks so much for letting us know we will take a look first chance we get.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- pacomerh 12y agoI just see them as "This is the way I organize my JS", so they're all useful to me.
- xixixao 12y agoI hate them! Do you remember the good old times, where people just wrote their code, and didn't share it with anyone? Everyone just reimplemented everything, all the time. And if someone did try to share some code, you wouldn't find out about it in "news"!!! You'd have to search through mailing lists and be lucky! to spot it before it got replaced by thousands of angry emails about the new license people's favorite *nix tool just adopted. I do remembered reading an email one day, from some guy who was getting tired of all these licensing discussions. He remember the great ol' times, when code was written on paper, everyone had their own language, and no one gave a damn about a license...
- jastanton 12y agoYou sir, win. Edit: I'm getting prepared for this to be my most down voted comment yet so guess I should add something of substance like saying that; I don't feel like the over sharing of JS libraries is inherently the problem. But it's what you do with that that can bring you into dangerous water, for example. If my project depends on 10 deprecated projects I'm going to have a hard time. But if I grab one as my base and build on top of it to suit my needs than a healthy architecture can be born. So I guess oversharing isn't the issue, but if you don't plan on maintaining your project forever more make it easy to extend, overwrite, and build on. A lot of JS frameworks don't have this in mind.
- emsy 12y agoI never miss downvoting, but all the "not another framework!" Posts make me do so. It's not the framework creators fault that JavaScript is flooded with libraries, so give the framework the chance to prove itself. For JavaScript frameworks, it's survival of the fittest.
- woah 12y agoBetter than some of the stagnant languages out there. If people don't want to try any of these new frameworks, they should just keep using what they were using before. Strange to complain about there being too much enthusiasm and innovation in a community.
- mattgreenrocks 12y agoActually, those 'stagnant' languages are powering your OS, your browser, the backend server, etc. They've had millions of dollars invested into them for development, implementation, and optimization. Doesn't mean they're good, but more that they're [usually] good enough that you can completely ignore them. Talk about abstraction! Anyway, lots of frameworks coming out != progress. Similarly, lack of new frameworks != stagnation. It often implies maturity, especially if the language has undergone a previous period of hype. Good tech stays around. Everything else dies by the wayside. Easier to just sit back and see who's left standing a year later. React looks desirable in my eyes because it isn't a framework with a God complex (aka all 'opinionated' frameworks).
- agmcleod 12y agoWell if nothing is changing with the language, or no new frameworks, then that does mean stagnation. Is it a bad thing? Of course not. Such stable languages and tools are great to have. Likewise I do think the sleuth of frameworks means progress. Not always good progress, but we will continue to learn and improve things going forward as these experiments succeed or fail.
- woah 12y ago
- shinzui 12y agoThe "Revolutionary App Architecture" looks like a big red flag. Also, that's the first time I've seen a scrum master credited for an open source project.
- thoman23 12y agoAlso, they misspelled "dependencies". :)
- riobard 12y agoSeriously? Your solution to showing syntax highlighted code snippets is images???
- riobard 12y agoDownvoters, I'd like to hear your arguments of why my complaint is invalid.
- jdlshore 12y agoIt's not the complaint itself, it's that it's rude, lazy, and off-topic.
- riobard 12y agoIt was rude??? Jeez you guys are really spoiled kids. Let me know when you are dealing with real customers down the way and how they will bitch about stuff. What's even the point of criticizing me being "lazy"? How am I supposed to complain the valid point without being "lazy"? Write a tutorial on using JavaScript syntax highlighting library? That might be OK elsewhere, but this is Hacker News and they are demoing code snippets. They are supposed to know this will cause serious usability issues. And if this complaint is off-topic, I'm not sure what else we should talk about here on HN.
- davidlumley 12y agoThe 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.
- cheerazar 12y agoLooks to be fixed now. Thank you for alerting us to the issue!
- lopatin 12y agoIt would take something truly novel to make me consider anything on top of the simple and powerful setup which is react + a custom flux. I don't see much here except some glue that reduces flux boilerplate for actions. It also seems to be a replacement for a simple mixin that subscribes components to stores. The animations feature doesn't seem to be too different than the standard CSSTransitionGroup. The docs say that the Tuxx abstracts away the "complexity" of flux but I don't buy it.
- ryanatkn 12y agoSame. Flux is really simple and most of the implementations just remove some boilerplate and add some conventions. Given more time there might be a framework that has everything that I want, informed by comprehensive, mature, real-world use cases, but I haven't yet seen anything compelling enough in the dozen or so libraries I've looked at. I've found a lot of value in having granular control so I can explore different conventions and optimizations.
- cnp 12y agoI'm in the same boat. I absolutely love that React + Flux is "just javascript", essentially. It's as simple as it gets.
- jstoiko 12y agoI just spent the past 5 days (re-)evaluating javascript frameworks for a project. It does feel like there are (too) many choices. However, I wonder: why are so many of these frameworks so opinionated? e.g. in Tuxxedo, why would 'actions' be named 'add', 'remove', 'edit' or 'get'. Why not following CRUD or POST/DELETE/PUT/GET convention? That's just one example. It feels like the front-end developer community tends to over-engineer things these days.
- UberMouse 12y agoThose actions can be named whatever you want. The person who wrote the code that appears in the documentation just went with those names, they're completely up to you, the developer.
- sjfstebbins 12y agoWe provided opinionated components, but almost all of them are customizable. Actions, animations etc.. can all be changed. We allow you to use our default component names or adjust them to your liking. This ability to adjust defaults follows throughout Tuxx. Check out the documentation for more.
- bsimpson 12y agoDid they rename `context` as `nearestOwnerProps`? Why?
- deleted 12y ago[deleted]
- thomasloh 12y agoyet another React + Flux "framework". The truth is, a lot of companies who are using React and Flux already have a framework in place, they just didn't polish it to put it out there. Nothing ground-breaking here, certainly nothing revolutionary.
- andybak 12y agoTo 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 same time) turned everyone's head and seemed to offer a much better way forward. However it was only part of the jigsaw. It can be described as the V in MVC with some suggestions on the right way to add the M and C ('Flux'). So - what we're seeing now is a lot of people who've had time to digest React+Flux and are releasing a complete MVC package that incorporates all the lessons learnt. Consider how long we had the "just use jQuery" phase of front-end development. It's just time for pendulum to swing back the other way.
- norswap 12y agoFrameworks are most often a bad idea. Use libraries instead. Sometimes they are useful though. For instance, they make sense when routing. But in those cases, they should more like libraries as well: more lightweight. Something like Express or Koa.js but more lightweight.
- sebastianconcpt 12y agoPeople learn using frameworks and discover using libraries. Some are pioneering-friendly others just-doing-the-job-friendly. Nothing static, all oscillating in a big Cambrian Explosion of JavaScript creativity
- morley 12y ago> Frameworks are most often a bad idea. Use libraries instead. People say this a lot, and it makes me wonder if they've ever worked on a team working on the same codebase. And if they do, what secret sauce they're drinking to not go insane. In my experience, when people on a team use libraries at their whim, the coding styles diverge wildly from feature to feature. One person decides they're going to write all their AJAX callbacks in an anonymous function; another likes to reference a function directly; another likes to both; and yet another uses promises. And as soon as someone needs to fix someone else's project, they do some combination of (a) getting wildly frustrated with this other coding style, (b) rewire their mental model to adapt to this new style, (c) spend a week rewriting it in their own style, (d) introduce a ton of bugs in the process, or (e) by some miracle, get it to work perfectly. So to combat this, the team works out coding standards and a style guide. You must tab with two spaces! You must pass a real Javascript function to your callbacks! You must separate your state from your view! And of course, once your style guide is big enough, lo and behold: you have your own hand-rolled framework. And hopefully it's tight enough that everyone writes in the same style, but is still expressive, and is still simple enough for a new team member to learn quickly. So if you're just starting a codebase, it makes complete sense to pick a framework on the outset because people have already gone through that headache for you.
- mwillmott 12y agoI'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 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.
- daemonk 12y agoAll these frameworks to do MVC... Maybe it's time browsers just natively support 2 way binding of data to DOM elements and virtual DOM diff-style batch rendering. It seems silly to relegate these features that everyone wants to a 3rd party library.