I delayed commenting on this because I wanted to read the article first. I agree with the article’s point 99% of the time. Of course here in Meteor land we have the rest of the stack so we are happy 
! I really don’t comprehend what you are trying to say at the end here though. Could you perhaps elaborate or provide some examples?
Depends. If stability in architecture means you are more productive, then Ember is a good choice. If you don’t need to create a ‘chat room’, then Ember has far more capability out of the box and probably wont contiue to annoy the developers who have invested time in learning aspects of the framework for them to be dropped. The Ember team take a more conservative view and don’t go rushing in trygin to chase shiney objects.
I mean that it just eases work of testers but can be replaced by post-processed machine-generated files developers never see.
In a broader sense, React is developer-centric or even tester-centric hack made popular. When you look at Meteor, it was started as startup/speed of MVP-centric. But as community is 90% developers, and majority are not beginners, it quickly moved in a direction of sophistication, because it’s just plain boring for Intermediate+ developer to just assemble blocks of code. We all want feeling unique artists not just workers… or just lack self-discipline 
But there are also designers and business people in any company.
From designer port of view, React is something unbearable. When I have skimmed the fanatic video about React and reached the point of
With JSX , it’s easy for designers to contribute code. I rushed to buy the tickets of LMFAO who come to Ukraine in May.
From business point of view, decision to move to React would have to be backed by very strong ROI promise and at the moment I see “I” but I don’t see “RO” there. I’m talking that being persuaded in the past by developers to “go into new brand technology” a couple of times, which lead to release delays for one and half year in one case and two and half years second time. Business had a shock but survived, developers had “brand new technology” on their resumes.
P.S. Maybe it would be clearer, if I add that Arunoda does great service to Meteor being Architect-centric, Josh Owens being teaching-centric, etc. and it is great that there is a community, which helps move it slowly but steadily ahead, and keeps constraints on chasing any new things. Meteor should be Meteor-centric. And Meteor-centric means what the original purpose was - rapid web/mobile application development tool.
P.P.S. You can look at React as great way to have strong biceps, which was made (strangely) by special design of bench for doing abs workout. And the big network Gymbook published the design of this Abbiceps abs-biceps bench and now every small gym would like to redesign their gym space to allow for that innovation. Of course, trainers are all talking about that. But nobody’s asked girls outdoors, do these biceps really matter that much in the context of whole body to make this Gym Framework revolution, and maybe there’s something apart of body. And nobody’s provided small gym owners with ROI analysis on the whole Abbiceps thingie.
2 Likes
What’s the point of this thread really? If you don’t want to learn React don’t learn it.
I got started with web app development thanks to Meteor and have continued on thanks to React. Prior to this I was building native iOS apps for 7 years (since the iPhone SDK was released really).
To me React feels more like I’m writing a “real” application as opposed to some HTML templates with logic attached, it does not feel like a hack to me at all. That’s just your opinion.
4 Likes
Do you work alone or in a team with designer, project manager, etc. That’s the right question.
I work with a team of six people with different roles.
Okay, so it is the question of how comfortable is the process of co-operation of non-developers with developers over React compared to Angular and Blaze or any other process you have used before. If they are happy and your company is successful, than that’s great!
Overall, I agree with you that from the bird’s eye point of view the original thread question is not constructive.
It would be constructive to hear success or failure stories instead. like:
I have used React + Mongo + … + 500 hours of work + Agile + … + market … we are team of 3 and Failed
or
I have used React + RethinkDB + 120 hours of work + our manager has 15 successful projects + designer was in 5 failure projects - and we had tremendous success!
Only Success/Failure compared to original Target can prove right or wrong. One cannot judge process by itself without the results context.
1 Like
My opinion is, developers lack confidence. We are always questioning what we are doing. After all, that’s what this whole argument is about. What’s the better way. We seem to do things that don’t make sense to us because “everyone else is doing it”. The mind set is ; “if it works for Facebook, then it will work for me”. It’s a fear of getting left behind. We need to stop thinking like this and start understanding why we use the things we use. Then, the ends will always justify the means. And we can stop this argument of what’s better.
3 Likes
I think the mind set is more that people don’t want to waste time on things that won’t be around for at least a few years. Popularity and momentum are really the only heuristics we have to determine that, because with both of those things comes continued support.
Regardless, technology is an industry where you will always be running in place just to be able to stand still.
5 Likes
Could you elaborate more on this point? I’m really not understanding what you are referring to here. [quote=“Volodymyr, post:43, topic:21846”]
In a broader sense, React is developer-centric or even tester-centric hack made popular. When you look at Meteor, it was started as startup/speed of MVP-centric. But as community is 90% developers, and majority are not beginners, it quickly moved in a direction of sophistication, because it’s just plain boring for Intermediate+ developer to just assemble blocks of code. We all want feeling unique artists not just workers… or just lack self-discipline
[/quote]
I disagree with this sentiment. Meteor has gone to more sophistication because there are many developers like me out there with 10k plus lines of code in one application, and we are realizing that 1k+ of that is stuff that the framework could do for us! Yes, us developers have a nasty tendency to reinvent the wheel (I think it’s been something like 10 million times or more now 
However I don’t think that meteor is catering to that, if anything it’s going the other way and saying “don’t reinvent the wheel, use Meteor’s wheel factory!”
With this I feel like I am finally understanding what you might be trying to say. When you say React, are you referring only to the base API? Or are you referring also to JSX? This statement reads like you are considering JSX separately.
It really depends on the business. The company I work for iterates our product so fast, and that product is built on blaze which plays nice in the same ecosystem as React, we have only RO, with no I. We are making conversion to React piecemail as we are in modifying sections of our application as it is. We are using https://atmospherejs.com/lassombra/react-templates to keep things down to basics especially where large templates are concerned (We have some “templates” that contain a hundred or more components.) We are using JSX in the rest of the instances.
What our Return has been is that we’ve been able to iterate faster, and with less buggy code. We have been able to write tests against our view logic. Most importantly, because we’re working in component land, we’re better able to break down and esitmate our tasks, resulting in better predicting our schedule![quote=“Volodymyr, post:43, topic:21846”]
P.S. Maybe it would be clearer, if I add that Arunoda does great service to Meteor being Architect-centric, Josh Owens being teaching-centric, etc. and it is great that there is a community, which helps move it slowly but steadily ahead, and keeps constraints on chasing any new things. Meteor should be Meteor-centric. And Meteor-centric means what the original purpose was - rapid web/mobile application development tool.
[/quote]
Yeah, I agree with that, though I don’t always agree with either of them (noone can be right 100% of the time). Where I Think you and I disagree is that for us React has helped Meteor be that rapid tool, we had outgrown blaze, and with React, we didn’t have to “outgrow” meteor with it!
And we’re right back to where I don’t understand what you are saying. If I try to dissect this, I’m getting that React is only part of the story (which we knew) but there seems to be something in here about it being used for something other than it was designed for? I’m missing where you are going with that.
1 Like
Thank you for detailed analysis and sharing your points. I agree that increased speed of iteration and ease of test coverage can be measurement of ROI. I also believe that 'what is measured can be imrpoved". So, if using React has increased speed of iteration some 10 or 20% and tests coverage some 20 or 30% with minimal investment, hats off Let’s return to this thread in a year and share practical results
I do wish you would try to present what you are saying about pre-processors in a different way. I think you might have some points in there, but I’m not able to extract what you mean. I really want to understand your perspective. You presented some relatively objective business needs/goals and we both offered small sample size observations on the application of those business needs, but you seem to have had some to say about using react and how it is as a developer, but I’m just not comprehending it, and would like to.
1 Like
Sure I meant the following. If we take example from the article I have cited above:
render: function() {
return <header>
{ this.state.name ?
this.state.name :
<span>Not Logged In</span> }
</header>;
}
My guess is that what we see above can be easily machine-generated from any code, as it is rightly pointed out React is nothing new but level of abstraction. So, actually, human generates code, which should be generated by postprocessor, and in addition, isolates HTML by encapsulation, which is good for testing but bad for design. For instance, you just cannot use any bootstrap templates without much tweaking.
This HTML is not necessarily would have to be isolated if for instance, IDE or test module or part of the framework would be able to tell bu what scripts this part of template is accessed or not accessed. So, actually, we can replace need for React in Blaze or whatever other framework by wise dispatcher module.
And probably what Javascript community lacks is robust IDE with great support for providing developer with different levels of abstraction of how the application actually works. Everything I’ve tried (Atom, Sublime, Webstorm) is just typing/template accelerators and software aggregators (GIT+cmd line, etc.).
If any analysis tools for web development of how everything is wired up are available for architects/developers/business analysts, I would be grateful for links.
Ok, I think I understand what you are saying. React to me is very developer centric and ignores designers. It lets developers reason through complex interactions in small scope. JSX when done right can be a bit of a middle ground where designers can say “stick these tags with these classes in there” and it works, but designers either need to be part developers themselves (in which JSX really does make a lot of sense) or need some kind of template language (enter https://atmospherejs.com/lassombra/react-templates).
In a lot of cases, I’ve found that JSX makes more sense for functional components (I use it for a lot of my low level components) but templating makes more sense on the top level!
1 Like
True. And to clarify further - why I do not see React as revolution but called it popular productivity hack - it is just MANUAL (and we are in the 16th year of 21st century, right? ) gluing your code with HTML in other way with enhanced isolation. It would be revolution if Javascript or Meteor would have something like that - http://doc.akka.io/docs/akka/2.4.4/intro/what-is-akka.html - that is giving totally other level of organization/structure to your bits of code and a lot of benefits. If anything like that exists in Javasript do point me in that direction.
I mean you are comparing apples to oranges. Akka is basically JVM based framework with a ton of work and experience behind it from J2EE to Spring to Akka. Javascript was first a simple language which was used to write validation on web forms etc. Then it evolved further until node.js came out. It is still evolving. Comparing Akka or JVM based frameworks with Javascript based frameworks would be very unjust. Akka is still not very easy to learn.
React is a UI framework and it does not claim anything else. It makes it easy for developers to understand there code.
We also strongly support this!
I have just provided Akka to show the relevant magnitude of things. So, and your post supports my point I have rather compared not apples to oranges but ant to elephant You have rightly told that elephant Akka is complex thing with long history but it does not get so much news as ant React.
Other example would be built-in support of microservices architecture or some business workflow management solution, etc.
I told apple to oranges because we cannot compare J2EE/Spring/Akka to JSP. React is more of JSP in javascript land. It is a part of the puzzle not the whole thing.
Javascript framework has a thing going for them and that is called momentum. The same thing started with Java when C++ was the king. People used to make fun of Java when i was in college. I think the same thing is going on with Javascript now.
Meteor is a good start and as it matures we will see more and more features coming into it as well. The goods thing is that MDG realizes that there are many things that needs to be fixed and they are slowly addressing them.
1 Like