what major production apps are build with Meteor? This might be the wrong place to ask but I figured it's worth a shot.
The State of Meteor Part 2: What Happens Next
141–150 of 153 posts
Re: The State of Meteor Part 2: What Happens Next
#142Earlier quoted context omitted.
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.
With React you have to Reason about abstract things pretty early, especially if you're using something like Redux. You have to know how to think about code in the abstract. A lot of people are just trying to get specific behavior on their website. They're thinking "I want a form that does this x", "I want a button that does y". They don't may not know how to think about abstract architecture and they may not see the value in it.
React doesn't really let you write code this way easily. You will run into problems with the lifetime cycle. You will be constantly fighting the library. Angular on the other hand lets you write a basic CRUD app without having to worry about those things. It's friendlier for people new to development.
I'm not advocating for Angular, I very much dislike it and I exclusively write using React, I just think React too hard or too much for normal people.
Re: The State of Meteor Part 2: What Happens Next
#143I 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…
Silly question - why are is everybody talking about jQuery in the past tense and why are you saying it "did not succeed"? It just got a beta release of a major version less than a week ago, it's a core part of Bootstrap, which just about anyone building webapps has used at some point, and depending on whose statistics you look at[1], powers a frankly absurd number of sites, including things everyone's heard of like M…
I think you've misread the parent. S/he isn't insinuating that jQuery didn't succeed, but that it (has) succeeded because of a set of reasons which are not part of the modus operandi of the teams behind a lot of modern UI frameworks.
Re: The State of Meteor Part 2: What Happens Next
#144Earlier quoted context omitted.
Part of the reason this year has been a bit of a mess is because MDG has been focusing a lot of resources on the profit-generating component of their business: meteor hosting and support. They launched Galaxy (their hosting service) just a couple months ago so it's still too early to say how successful that will be, but it could easily be in their best interests to cannibalize some of their older features if it helps…
Not having to spend money on Blaze will make them more competitive as a hosting business. Frankly, when is the last time you saw a billion dollar unicorn hosting business? Or a hosting IPO? I doubt we will see SQL support. We will likely see something with GraphQL instead.
As a developer who is only using them for a personal project so far, I don't care one way or the other if they are incapable of becoming a unicorn - I just want them to be profitable enough to continue developing the framework. They may be under too much pressure from their investors to go that route, but wasn't hosting MDG's monetization plan from the beginning? If so, savvy investors would already know the likelihood of unicornization was low/zero when they invested.
You're certainly much more in the loop about SQL/GraphQL. Would GraphQL allow non-mongo databases to push updates out to clients for reactive updates?
Thanks for running Crater.io - I've been reading it a lot recently!
Re: The State of Meteor Part 2: What Happens Next
#145The 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 Me…
It's probably too late. The work they've done with blaze is wasted since react and angular(still) are dominant. The work they've done with MongoDB is wasted since most of the world wants SQL. So what do they really bring to the table. It feels like too little too late.
Re: The State of Meteor Part 2: What Happens Next
#146Earlier quoted context omitted.
Why would the post be business focused? The guy that wrote it doesn't run "Meteor the business", he just loves the framework itself. I am not even sure how a CMS got mentioned and compared here.
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…
"allow you to drop down to make lower level tweaks as you would on 'bare metal' NPM"
Meteor is entirely open-source and I've had no trouble diving into the lower levels to accomplish what I need to accomplish. Everything is split into reasonable packages and is relatively easy to traverse.
If anything, the Meteor team hasn't done a good enough job showing their true value (realtime via oplog->client updates, etc). Most of the current controversy stems from front-end developers jumping on the React bandwagon, splitting up the community as it stands. Not a big deal IMO.
Re: The State of Meteor Part 2: What Happens Next
#147Earlier quoted context omitted.
I'd strongly disagree with the idea that we need or even want one ring to rule them all. Remember different frameworks are designed to solve different problems in different ways [1][2]. Anyone who has dug deep enough into a framework or tool-set will be able to write out a very long list of unique quarks, gotchas, caveats, hidden strengths/weaknesses, and what have you. It's those differences that will make one frame…
What if we replace "best" with "good enough for most common uses"? Most of the roads and bridges we build today aren't pinnacles of innovation, they're just good enough that we don't bother optimizing them much more. With how young the software engineering field is I don't think we'll get to this point in the near future, but part of me looks forward to a day when we have widely accepted standard solutions to common…
I think there is a difference between "just good enough" and "has reached maximum efficiency". I think a lot of people want to settle at the first one, yet I see the second one nowhere in sight.
Re: The State of Meteor Part 2: What Happens Next
#148Might have been different if they had chosen to embrace SQL, instead of just putting it on the roadmap and letting it rot.
I couldn't agree more. One of the most expensive things we have to do on Meteor projects is constantly re-mapping the way we think about our data so it works in a noSQL paradigm.
If they were serious about the framework they'd drop everything they're doing and focus on getting some proper relational support happening ASAP.
Re: The State of Meteor Part 2: What Happens Next
#149The 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 Me…
Agreed. If anybody thinks the real problem with Meteor is that it uses an antiquated templating system they're missing the bigger picture.
Re: The State of Meteor Part 2: What Happens Next
#150Earlier quoted context omitted.
I totally agree with you. It took me lots of time just to figure out to write a 'PROPER' react application. There are too many modules to choose from for routing, data acess etc.. Then I tried with Angular 2, it look me less time to get up and running with forms, routing and everything...
It may take you even less time with Aurelia!
Aurelia too seems interesting. Since I have done development in Angular 1.x before, Angular 2.0 was the natural choice.
From the look of it, Aurelia seems promising, need to look into more before I need to comment anything.