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?
Tuxedo.js – A Framework Built on React and Flux
61–70 of 90 posts
Re: Tuxedo.js – A Framework Built on React and Flux
#62The site doesn't work and the error console is filled with javascript errors and 404s.
Re: Tuxedo.js – A Framework Built on React and Flux
#63Earlier quoted context omitted.
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'…
When I'm not sure which library to use, I just choose the one with the most commits I have never seen anyone use that logic.
Me neither. Nevertheless, the commit rate plays a role.
If the last commit is months old, you should be careful. If it is years old, you should stay away from it. (Example: The original Qmail mailserver was rock solid and djb's masterpiece of security. But you had to add custom patches for even basic features such as SMTP Auth. Why? Because at the time Qmail was written, SMTP Auth wasn't common yet.)
If the author then says that this is not due to lack of time, but because the software is "ready" / "done", this is an even worse sign. (Yes, I'm looking at you, Tilecache.)
Re: Tuxedo.js – A Framework Built on React and Flux
#64Earlier 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…
I don't think that a framework is a good substitute for a style guide or the processes like reviewing, documenting or factoring code that lead to consistency and readability. If your team members feel like they have to "rewire their mental models" or spend weeks rewriting code rather than adapting to it, the team has a problem that you should deal with in another way than pigeonholing your projects into frameworks.
I generally disagree with the sentiment that collections of libraries are somehow inherently a better solution than frameworks, though. I just think that it is probably a poor solution to the problem you describe here.
Re: Tuxedo.js – A Framework Built on React and Flux
#65Earlier 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'…
It's not strange, it's the natural state of a market with limited and ever-changing information. At each iteration, people ask themselves two questions: "Am I convinced this will alleviate one or more pain points I have?" and "Am I convinced this will be active, well-documented, maintained, and improved for the forseeable future?". Note the questions are "am I convinced this will" rather than "will this", because information is limited.
It is very difficult to know a priori whether something will really alleviate a pain point, or whether it just seems like it will. The ability to do that successfully most of the time is one of the great advantages of experience.
Even worse, it's basically impossible to predict the future evolution of community support for a given project, but support from a company that can pay salaries and is not itself going anywhere is one of the best positive indicators of longevity and maintenance (though it says little of quality).
Re: Tuxedo.js – A Framework Built on React and Flux
#66Earlier quoted context omitted.
> 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…
Absolutely, I'm beginning to lose patience repeating the frankly blinding-obvious-at-this-point-argument you just had to make, but I'm glad others like yourself haven't. 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.
And I have found the "you're just writing your own framework" point needlessly repeated over and over, despite having never run into it in practice. Choosing a large framework does not insulate you from the concerns of the grandparent. You still must come up with a style guide, and a way of using the tools. The win is not obvious, imo.
Re: Tuxedo.js – A Framework Built on React and Flux
#67I 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.
+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.
You're forgetting the people who are new and coming in. Having a hundred options to choose from leads to initial paralysis.
Re: Tuxedo.js – A Framework Built on React and Flux
#68To 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…
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.
Sorry - you've conflated two things:
"When building complex front-end apps frameworks help."
doesn't imply:
"Everything on the web should pretend it's an app"
My sweet-spot is is pjax, progressive enhancement and "let's pretend some people have javascript turned off so we can maintain a sane architecture without having to explain why"...
But - some things that run in a browser ARE apps and need some support beyond jQuery et al.
Re: Tuxedo.js – A Framework Built on React and Flux
#69Earlier 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.
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.
Re: Tuxedo.js – A Framework Built on React and Flux
#70It 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 tha…
I'm in the same boat. I absolutely love that React + Flux is "just javascript", essentially. It's as simple as it gets.