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 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.
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 (e.g. Knuth's arrow notation, busy beaver).
One could argue that the arms race between Prototype, Dojo, YUI etc from the last decade was a race of incremental solutions and one-upmanship, and jQuery largely stood out from the crowd by having extremely well thought out developer ergonomics.
I think that the ideas behind React/Mithril/Mercury (composability, unidirectionality, etc) are, as jQuery UX was at the time, a "leap out of the box" in the frameworks' arms race, but I feel that frameworks like tuxedo are again settling into the territory of being merely stabs at incremental improvements.
The main problem I see here is that it's not particularly obvious what kind of problem this framework solves. Virtual DOM frameworks are hot because they help solve problems. In contrast, it's hard to sell features.
Those lessons appear to have left us needing a loading screen to show a web page. I'll stick with not bolting everything I can find together into a Frankensteins monster of a stack.
> to digest React+Flux and are releasing a complete MVC package that incorporates all the lessons learnt
I'd reduce this to "some lessons learnt".
While some people build frameworks based on React+Flux, other poeple still think these frameworks are larger than they should be, and provide even more lightweight alternatives, such as Riot.js.
Nevertheless, I agree that this is still in progress. There are phases of trying entirely new designs, pushing them to their limits, reducing them to their essence, using them as building blocks for new designs, and so on.
Frameworks 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.
It 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.
Same. 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.
I 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.
Better 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.
+1. There is literally zero negative impact on anyone's life by a hundred new js frameworks coming out every day. Ignore them. Use the ones you know and enjoy. If a new one seems to be gaining mainstream traction, spend an hour to check it out. Don't waste a second of brain activity or get annoyed with new frameworks - there is no reason.
Does 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.
Currently 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.
The "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.
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.
I 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.
Those 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.
All 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.
OT 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!
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.
[+] [-] andybak|11 years ago|reply
(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.
[+] [-] lhorie|11 years ago|reply
One could argue that the arms race between Prototype, Dojo, YUI etc from the last decade was a race of incremental solutions and one-upmanship, and jQuery largely stood out from the crowd by having extremely well thought out developer ergonomics.
I think that the ideas behind React/Mithril/Mercury (composability, unidirectionality, etc) are, as jQuery UX was at the time, a "leap out of the box" in the frameworks' arms race, but I feel that frameworks like tuxedo are again settling into the territory of being merely stabs at incremental improvements.
The main problem I see here is that it's not particularly obvious what kind of problem this framework solves. Virtual DOM frameworks are hot because they help solve problems. In contrast, it's hard to sell features.
[+] [-] weego|11 years ago|reply
[+] [-] vog|11 years ago|reply
I'd reduce this to "some lessons learnt".
While some people build frameworks based on React+Flux, other poeple still think these frameworks are larger than they should be, and provide even more lightweight alternatives, such as Riot.js.
Nevertheless, I agree that this is still in progress. There are phases of trying entirely new designs, pushing them to their limits, reducing them to their essence, using them as building blocks for new designs, and so on.
[+] [-] norswap|11 years ago|reply
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.
[+] [-] riffraff|11 years ago|reply
[+] [-] lopatin|11 years ago|reply
[+] [-] ryanatkn|11 years ago|reply
[+] [-] cnp|11 years ago|reply
[+] [-] emsy|11 years ago|reply
[+] [-] woah|11 years ago|reply
[+] [-] fro|11 years ago|reply
[+] [-] bringking|11 years ago|reply
[+] [-] drabinowitz|11 years ago|reply
[+] [-] goatslacker|11 years ago|reply
[1] https://github.com/goatslacker/alt [2] https://github.com/goatslacker/iso
[+] [-] fro|11 years ago|reply
[+] [-] bonif|11 years ago|reply
[+] [-] shinzui|11 years ago|reply
[+] [-] thoman23|11 years ago|reply
[+] [-] mwillmott|11 years ago|reply
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.
[+] [-] jstoiko|11 years ago|reply
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|11 years ago|reply
[+] [-] daemonk|11 years ago|reply
[+] [-] nacs|11 years ago|reply
The Graceful degradation link, for example, goes to http://www.tuxedojs.org/www.tuxedojs.org/docs/TuxModularity instead of http://www.tuxedojs.org/docs/TuxModularity.
[+] [-] drabinowitz|11 years ago|reply
[+] [-] sjfstebbins|11 years ago|reply
[+] [-] davidlumley|11 years ago|reply
> 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|11 years ago|reply
[+] [-] aidos|11 years ago|reply
[+] [-] drabinowitz|11 years ago|reply
[+] [-] boomlinde|11 years ago|reply
[+] [-] bsimpson|11 years ago|reply
[+] [-] intrasight|11 years ago|reply
[+] [-] nilliams|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] hmans|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]