It may even be worth holding off and revisiting this idea in 30-60 days. Things are moving so fast, maybe the dust will have settled more by then… rather investing time and effort trying to wrap your head around so many dissenting views (in a situation where only time will tell).
Thanks, @ramez.
When you say “it’s very much worth the effort”, do you mean that Meteor is very much worth the effort or that building a faster way for beginners to learn Meteor (whatever it turns out to be) is worth the effort? Or both?
If you were at my level, with only part of my time to allocate to learning, would you learn the Meteor ecosystem, or would you learn something else? I could always keep playing with PHP et al and wait until Meteor’s path forward is clearer.
I know that it will take time and effort to learn a new framework of some sort, but had reached the conclusion that that time would be paid back in spades within around 2 months. I have a lot of SPA’s to build and I’m betting that any framework will be worth it in the long run.
'Thought that Meteor would get me up and running fastest, but am now questioning that thought!
Advice?
Thanks, @ramez - I hadn’t come across this one. It seems quite a bit further down the track than I need right now (focusing on fast and efficient apps, rather than quick and easy human learning). I can see what you mean about the way it’s presented.
To be fair, the Meteor Guide does mention compatibility with version 1.2 in the Application Structure section:
Since this is a new feature introduced in Meteor 1.3, you will find a lot of code online that uses the older, more centralized conventions built around packages and apps declaring global symbols. This old system still works, so to opt-in to the new module system code must be placed inside the imports/ directory in your application
Thanks, @maxhodges. I understand where you’re coming from. I agree that it might look hard to impossible to do… until you find a way, or see it done. So, I agree with all of your comments: but have personal experience in addressing situations just like this and think that I’ve those issues covered.
My primary objectives are:
- To, as quickly and easily as I can, have a quick and easy SPA-prototyping process and toolkit/platform - so that I can get the designs right enough for my own and small set of clients to to use and evolve over time - before handing them over over to professional developers to convert into robust, fast and scalable SPA’s. Prototyping tools are inadequate for the job, both in terms of UI and data model that they support.
- To apply, test and demonstrate Deliberate Master within the SD world - and make it easier for people like me to convert our ideas into tangible value, in the process.
I reckon - not without experience in many different fields - that the second objective will accelerate rather than slow down the process. But I can understand you thinking the opposite: been there - done that!
I hear you. Here is my honest advice:
-
You are in a similar position I was in 2 months ago. And we already have a commercial App making money (here is our launch announcement: ZeSchool App -- Digital Classroom with Meteor / Blaze). Prior to that we were coding in AS3 (ActionScript / Adobe AIR / Flash). With Meteor we got up and running quickly and it’s doing great. We did not want to do it in PHP (and definitely not in Python or Ruby). Note that we are among a small group of people on this forum actually making money off our product (i.e. not selling services, or training).
-
Visit this poll: Who uses what - Blaze/Angular/React/Vue - Poll . You will find that the ‘old’ Meteor way is still very present and strong. The adoption of React is not as strong as was originally expected (in fact, my guess is that half the ones using React were using it before, and a big part of the other half are there because of MDG wanting to jump on the FB ecosystem). I strongly recommend Blaze for anyone wanting to develop good apps quickly (Blaze is nothing more than Handlebars, a dominant DOM-based themeing engine for Node / Express and even Ghost). And with Blaze future development going to the community (let by the amazing @mitar), you will find a lot of improvements coming to it (including Incremental DOM) – last I checked there was only one bug! And it was something silly easily circumventable in your code. Now I know that many will push for React, I haven’t seen any compelling reason to make the jump.
-
As MDG refocuses on the data layer (Apollo), they will drop (I predict) involvement in the view layer. So you will be on your own regardless. Might as well stick to what works and later refactor if you needed to (and I bet you won’t have to).
-
Start using Meteor as soon as you can so you can learn its ropes. Here are my favorite tutorials and the ones that really got us developing quickly by LevelUpTuts (leaps and bounds better than many of the resources out there) – don’t buy any books or videos (not worth it).
6 Likes
@hexatonic, I think we’re on a similar wavelength!
I like your list of assumptions:
- I’d add/clarify that “radically different backgrounds” would include radically different expertise levels as well as radically different domains. 'Suspect that you meant that.
- I’d add - “to start with” to your Point 1 - i.e. “1. Assume newbies want to build a somewhat naive application from a data perspective, to start with.”
- Point 2. In my case, my data models are not very complex (simple recursive taxonomy of taxonomies), but nearly all of my apps will use a very similar data model.
- Totally agree with Point 3 and Point 4.
- Point 5. The lack of easy support for SQL is a disappointment for me - given that I have early prototypes working against a SQL database already - but converting doesn’t seem too challenging. Your experience? I agree that opening up that can of worms at the start is not a newby task!
Your “dead ends” experience is concerning!
I like the idea of newbies from other frameworks working together to overcome some of these “common” obstacles.
Agreed. are you also thinking both common obstacles in the Meteor-world as well as obstacles that are common to across the various modern frameworks?
@GaryBartlett, we came from SQL too, and love MongoDB now (even though it is not Acid-compliant).
2 Likes
Some more advice if I may:
We used Semantic-UI (even though we used to love Bootstrap). The only word I can use to describe it is that it’s amazing. Comes with its own builder (even for Meteor). So you can customize your UI in seconds, rather than days. With Semantic you would be up and running with a professional-looking App in no time.
I heard Ionic is great too, albeit (I believe) too ‘Angular’.
2 Likes
Great advice, @ramez - thanks very much!
I’ll check it all out…
Also for the Semantic UI suggestion…
Are you using Semantic-UI with Blaze or React? We use the HOMER bootstrap theme in a couple apps. They have a Meteor version of the theme which really helped us put our UI together quickly.
I tried Semantic-UI some static sites but found it to be much more complicated than Bootstrap. The learning curve was very high for me. It was difficult to understand which files to edit to accomplish various things, and I had to keep reinstalling things every time the a remote design passed me updates. (It seems either of us knew the right way to collaborate in Semantic-UI). I ended up going back to Bootstrap, but your enthusiasm for Semantic-UI makes me wonder which UI framework I should use for a new project (which will use React). Maybe I just needed a Semantic-UI mentor to help me come up to speed.
Maybe @GaryBartlett can write a Semantic-UI tutorial too and show us how Deliberate Mastery could dramatically shorten the learning curve.
Thanks, @shilman. I bought the Discover Meteor package, as well. It seems, from what @sacha says, below - and the general direction of this discussion - that it may not be the best route, at this point.
But to be completely honest, I still think the best way to learn Meteor as a completely new user, would be to use Discover Meteor. Except maybe the Iron Router usage, everything else is up to date.
Thanks for the advice, @Spyridon - good to know that it’s still an option. I like the steps you’ve laid out, too.
We use Semantic-UI with Blaze.
The learning curve was a bit steep at the beginning, actually bought a video tutorial then had a ‘duh’ moment that it was much simpler than I thought. I started copying pieces of code from the website (which is amazing BTW, full of HTML snippets to do practically anything).
Our own custom CSS on top of Semantic is extremely short.
1 Like
Agreed @Spyridon, there is a shift away from new devs to established devs, on the path of profitability 
I am lucky to have started before that shift, as I feel Meteor may not be as accessible as it once was.
1 Like
Thanks for commenting, @sacha - very illuminating.
And I like your advice: and its context. I’ve had a quick look at your Study Plan - definitely some links I want to take a deeper look at.
Right now the most practical way of learning Meteor in my opinion is to learn React first. Most of your codebase’s code will probably be React code anyway, and it’s also a portable skill if you ever need to use a different stack.
So do you think that I should abandon Discover Meteor for the moment, in favour of starting with React? (I bought Discover Meteor last weekend).
What do you think of @ramez’s advice to stick with the ‘old’ Meteor/Blaze way - in my situation?
Do you “get” what I think is missing and would like to help contribute?
I would suggest learning React first (I recommend https://reactforbeginners.com), and then coming back to Discover Meteor and going through it while substituting React for Blaze, and FlowRouter for Iron Router. So using it more as a general guide instead of a step-by-step textbook.
Of course, I’m also happy to refund your purchase if you think you’re not going to use the book
1 Like
if you’re too busy to update Discover Meteor, have you thought about outsourcing the work? I imagine there are probably some other community members who would taken it on. You could have a contest whereby candidates translate a Blaze/Iron-Router chapter to React, and you can judge who did the best job. Perhaps you could structure it as a revenue share, as it would just be extra revenue you wouldn’t otherwise see.
Cheers!
1 Like
Sorry, I don’t think that plan is very realistic… people are more than welcome to write their own book if they want to though!