51–60 of 90 posts
The "Feature" section (with links labeled "Graceful Degradation", "Semantic Action Creation", etc) are all 404s since they're missing the ' http://' . 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 .
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…
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.
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.
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…
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.
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.
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).
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…
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…
* "I'll go with Angular since it's supported by Google"
* "When I'm not sure which library to use, I just choose the one with the most commits"
* "I'll just choose something with the most features in case I need them"
The upshot is that incremental, monolithic solutions get selected over and over because they're easiest to digest and usually supported by a well-known entity with lots of capital (lol meritocracy).
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. Very strange.
Earlier quoted context omitted.
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 be fair, a loading screen in a web app is a symptom of a bad design, not the use of a framework. For instance, you can use React from Node.js to pre-render the app's initial state.
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'…
I have never seen anyone use that logic.
Earlier quoted context omitted.
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.
> 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…
The 'don't use frameworks, use libraries' argument is naive, and just does not hold up in the real world of teams trying to build things.
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…
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.