Tuxedo.js – A Framework Built on React and Flux(tuxedojs.org)
tuxedojs.org
Tuxedo.js – A Framework Built on React and Flux
http://www.tuxedojs.org/
89 comments
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.
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.
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'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.
* "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.
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).
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).
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.
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.)
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.)
> 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.
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.
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.
Yep, SPAs and loading screens are not synonymous and the implication that any SPA can be replaced with a traditional multi-page app with no loading concerns and comparable UX is purposely obtuse.
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.
"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.
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.
This has many benefits like code reusability and not having to write placeholders/render code twice -- in two different languages.
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.
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.
I will never understand this push towards "isomorphism"
Keep it DRY. Write once, run everywhere. Bearing in mind you have to write the application once in Javascript, it's a counter-proposal to "being able to work in the language of my choice on the server", which is to use the 1 version.
Keep it DRY. Write once, run everywhere. Bearing in mind you have to write the application once in Javascript, it's a counter-proposal to "being able to work in the language of my choice on the server", which is to use the 1 version.
> 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.
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.
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 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.
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.
I'm moving towards the library approach for some toy projects for both client and server.
There is no perfect framework and by choosing one you're usually stuck with its warts for the long haul. I usually find that I'm bending my code to fit into the framework conventions that I don't necessarily agree with.
With ExtJS for example, the framework conventions dictate your project should be organized into folders like this:
Another example (still ExtJS!) is that I never agreed with ExtJS's MVC implementation - where its controllers were global for all instances of a view. It took Sencha several years before they fixed this by adding "ViewControllers" in ExtJS 5.
If ExtJS was not an all-encompassing framework I would have liked to use its UI components with a different MVC library (or simply vanilla JS) organized into my preferred project structure. I suppose it's still possible to do this but with frameworks you tend to not want to deviate too much from the framework conventions or things start to go wrong.
There is no perfect framework and by choosing one you're usually stuck with its warts for the long haul. I usually find that I'm bending my code to fit into the framework conventions that I don't necessarily agree with.
With ExtJS for example, the framework conventions dictate your project should be organized into folders like this:
controllers/
models/
views/
Another example (still ExtJS!) is that I never agreed with ExtJS's MVC implementation - where its controllers were global for all instances of a view. It took Sencha several years before they fixed this by adding "ViewControllers" in ExtJS 5.
If ExtJS was not an all-encompassing framework I would have liked to use its UI components with a different MVC library (or simply vanilla JS) organized into my preferred project structure. I suppose it's still possible to do this but with frameworks you tend to not want to deviate too much from the framework conventions or things start to go wrong.
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.
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.
The style guide is surely longer when using a toolset with fewer conventions?
If I'm using Backbone over Ember, my style guide has to cover things that would be covered by Ember's own docs, for example how to compose views, how to do nested routing, how to represent computed properties ...
Your longer style guide is defining code patterns for those use-cases. Your longer style guide is a framework, just more verbose because you aren't actually abstracting away those patterns.
If I'm using Backbone over Ember, my style guide has to cover things that would be covered by Ember's own docs, for example how to compose views, how to do nested routing, how to represent computed properties ...
Your longer style guide is defining code patterns for those use-cases. Your longer style guide is a framework, just more verbose because you aren't actually abstracting away those patterns.
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.
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.
People 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
Some are pioneering-friendly others just-doing-the-job-friendly.
Nothing static, all oscillating in a big Cambrian Explosion of JavaScript creativity
unless of course it's just the CADT model all over again.
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'm in the same boat. I absolutely love that React + Flux is "just javascript", essentially. It's as simple as it gets.
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.
Actually, 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).
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).
Well 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.
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.
+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.
Of course there is! It fragments the community, which means instead of pouring our efforts into making one really awesome framework (e.g. Ruby on Rails), every other developer is making their own.
Not that I think that's inherently bad, especially since web technology is constantly in flux, but you can't say that having tons of small frameworks has zero impact on anyone's life.
Not that I think that's inherently bad, especially since web technology is constantly in flux, but you can't say that having tons of small frameworks has zero impact on anyone's life.
Yes there is. It becomes harder to separate the wheat from the chaff.
You're forgetting the people who are new and coming in. Having a hundred options to choose from leads to initial paralysis.
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.
You 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 [2] https://github.com/goatslacker/iso
[1] https://github.com/goatslacker/alt [2] https://github.com/goatslacker/iso
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.
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.
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.
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.
We 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.
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.
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.
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.
Thanks so much for letting us know we will take a look first chance we get.
Thank you. We have made this adjustment.
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.
> 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!
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!
Yeah I apologize for that we are still working on a mobile friendly version of the site.
The site doesn't work and the error console is filled with javascript errors and 404s.
Did they rename `context` as `nearestOwnerProps`? Why?
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...
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...
[deleted]
[deleted]
[deleted]
Please stop.
[deleted]
[deleted](2)
yet 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.
Seriously? Your solution to showing syntax highlighted code snippets is images???
Downvoters, I'd like to hear your arguments of why my complaint is invalid.
It's not the complaint itself, it's that it's rude, lazy, and off-topic.
It 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.
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.
Please, stop this framework madness.
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?
Is anyone keeping count, we must be in the hundreds by now?
I 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.
I 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?
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 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.
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.
> The other ones are mocked into oblivion
This should not be the "natural order" of things.
https://news.ycombinator.com/item?id=5106767
This should not be the "natural order" of things.
https://news.ycombinator.com/item?id=5106767
[deleted]
hundreds? I'd be surprised if we hadn't reached a thousand.
(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.