This is fantastic. This removes efforts to maintain a random front end view layer while legitimizing the numerous react integration attempts. This will save a lot of time moving forward to phase out blaze.
The State of Meteor Part 2: What Happens Next
71–80 of 153 posts
Re: The State of Meteor Part 2: What Happens Next
#72The problem with Meteor is not the front-end. The problem is that data exists (for the most part) in Relational DBs.
This prevents Meteor from being used in any environment that needs to/wants to use a SQL db.
This prevents Meteor from being used in any form, for any application that needs to access existing data in a SQL db.
React does not prevent Meteor being adopted - not having SQL support is a dealbreaker.
If Meteor does not confront and solve this problem nothing else matters.
The only thing MDG should be doing in 2016, is SQL DB support.
Re: The State of Meteor Part 2: What Happens Next
#73Earlier quoted context omitted.
Let's say hypothetically I have 600 concurrent users, what steps can a Meteor dev take to increase performance?
Most meteor apps are stateless on the server so you can safely scale by adding more servers (and more server to Mongo if that's the bottleneck). This can be easily done with Cluster package ( https://github.com/meteorhacks/cluster ). It's so easy you don't even need to configure anything.
I'll think it's easier (maybe more expensive) to just use Galaxy, and scale. Then host your Mongo database on Compose.io that also scales.
Re: The State of Meteor Part 2: What Happens Next
#74Earlier quoted context omitted.
I think React won the HN front page, where anyone who criticizes it or promotes another technology gets down-voted. However outside this bubble, ReactJS has a very long way to go before adoption rates make it a contender for top library ( http://trends.builtwith.com/javascript/javascript-library ).
React is probably too hard for casual scripters. I disagree with the OP's point about it being the new jQuery. It is however perfect for a solid engineering solution to building great web applications. It's for engineers who care about churning out a well tuned architecture and not for those who are just creating an CRUD app that just grows organically.
I'd be curious to know what you find hard about React?
Also a CRUD app that just grows organically needs a well-tuned architecture too, once it grows large enough.
Re: The State of Meteor Part 2: What Happens Next
#75I strongly urge you to take a step back and really look at React community from 30,000 foot view. Please don't get on the hype train without taking a look at other solutions. Vue.js as far as libraries go, and Ember as far as framework go. I promise you, you'll have a better experience.
Vue.js seems like backbone. Last time i checked Ember looked way complicated. What i like about React is the simplicity. Its basically JavaScript with few React functions thrown in. As a view component its very good. I have used it in normal rails app as well.
Re: The State of Meteor Part 2: What Happens Next
#76Meteor's best trick has always been data synchronization. That was the magic trick that sold your client. They proved real-time data synchronization could be simple and seamless, and everyone else had to run to catch up. But that trick is now 4 years old, and nothing else of substance really emerged. As Ember, Angular and React grew, you were never going to want to use their odd looking front end. Their data sync als…
GraphQL and Relay may be the answer but it's too young to make that switch now and Meteor is solving that exact problem. Meteor has the momentum and community to take it further. Maybe it actually adopts the GraphQL standard and unifies it into the ultimate dev UX experience.
Re: The State of Meteor Part 2: What Happens Next
#77Might have been different if they had chosen to embrace SQL, instead of just putting it on the roadmap and letting it rot.
See, when people see that, they miss the point a bit. The beauty of Mongo is it syngerzies extremely well with a pure javascript approach.
Re: The State of Meteor Part 2: What Happens Next
#78I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not…
jQuery filled a need. It's as simple as that. Its success has nothing to do with looking in the other direction or not redefining Javascript: it solved a problem that a lot of Javascript developers were struggling with. Now what's really fascinating to me now is that while one can safely say jQuery created a revolution in the Javascript world when it came out, it is today widely looked as a smell and avoided as much…
That need was filled by Prototype.js before jQuery. I remember the times when Rails defaulted to Prototype (author was a member of Rails core team, iirc). I also remember when we still had to choose between the two for the new project and I was unhappy if the choice was Prototype. So they both solved the problem, but jQuery's solution was more focused and way more elegant.
Re: The State of Meteor Part 2: What Happens Next
#79Earlier quoted context omitted.
Meteor has as a better chance than ever, ESPECIALLY if 90% of what you can do in Meteor you can do in "bare metal" NPM! Meteor doesn't have to provide that many "features" to win over the NPM crowd that it has struggled to acquire thus far. It's so damn complex to implement all this stuff that most developers need help doing it. Meteor's problem thus far has been it makes it easy but provides no way to "drop down" to…
Quotes or not, this is the first time I've seen "bare metal" applied to npm. Hah.
yea I made up. But if you've been in any Meteor forum topics about NPM and support for modules etc, it would would make more sense. Meteor exists as a layer on top of NPM. It has done a lot of harm to its marketability. "Bare metal" in this case is a good thing, it's sought after deeper control which the Meteor community has awakened to realizing is a must.
Re: The State of Meteor Part 2: What Happens Next
#80I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not…
well said. another important thing to remember is when jQuery came about interfacing with the DOM was really messy across browsers. Ajax queries as well. simplifying those, in my opinion, the killer features of jQuery at the time. Interfacing with the DOM was not even something that dojo, mootools etc were doing at the time. At least that part wasn't as obvious/easy in those frameworks.
The big change I experienced with Jquery is that it operates on sets of elements. It eliminated most guards and loops I'd been accustomed to when dealing with the DOM.