Just don’t want you to get your hopes up. Blaze was created at a time when front end was a challenge. Now you have React, Vue, MarkoJS and others, so there is no reason to invest there.
Blaze is solid, so use it until your app reaches a certain volume level (if that’s the purpose) then migrate (that’s what we are planning at our end when our desired featureset is fully covered).
I wrote an application in Visual Basic 6 in 1998 - its still in use today. Thanks to Microsoft ensuring backwards compatibility, the app began development on Windows 95, and the customer has upgraded their client OS from that all the way through to now on Windows 10, and the app still runs fine.
That’s 20 years.
I think if what we’ve seen from Meteor with their backwards compatibility, I think @jayme won’t have any issues in the future.
As a noob getting on board these days, I came here trying to find what router should I use for my first app.
It has been quite a joyful and easy ride. I followed the Blaze tutorial (React seem too complex and verbose for my needs at this time; liking @ramez last reply). I continued developing my app since and am starting to love meteor for its client-server integration, fast development, clear application structure, reactivity, etc…
Frankly I’ve never been this quickly in love and at ease learning a new stack… up until this moment. This situation is quite troubling and worrying indeed. I would love to see some updates to the Guide and up-to-date official recommendations for beginners and small projects (blog post anybody?). I feel but am still unsure that React or Vue are the way to go for bigger projects, but all big projects starts small.
TLDR; Hoping I’m not hijacking this thread, I would love to hear what router are you using. Is it still ok to use Flow-Router with Meteor 1.6.1? What about Iron Router or Flow-Router Extra (which looks more actively maintained)? Are there other alternatives to use with Blaze templates?
[EDIT:] I’ve gone ahead and tried Flow-Router Extra: Works like a charm! (at least for basic routing features I’m interested in).
Glad you’re enjoying thus far. I’d suggest opening a new thread for the router, but generally I’d stick to the meteor guide (flow router) or with flow router extra by extension if using Blaze since it’s keep the routing layer as thin as possible.
It is true that no one can be confidente in 10 years from now about any piece of software. In the other hand, I’ve been developing software for more than 25 years, and I can tell you, many of the Software Systems that I wrote back in 1989 are still on production.
In the company that I worked for 10 years up to date, we have a piece of software that was written in 1985 and refreshed in 2000. It still represents a good source of revenue and we depend on IBM to keep the technology updated as they have diligently done so far. Millions of dollars would be required to rewrite in any other platform.
Another important App was a SaaS software created in 2001, made with PHP. A major rewrite happened in 2005 when we migrated to PHP 5 and still going strong.
We created another app in 2008 on top Sharepoint. It was a fiasco. Had to rewrite it 4 years later.
We wrote native mobile apps for Palm, Blackberry and Pocket PC; those handheld devices are dead by know. The one we wrote in 2010 and 2011 for iOS and Android still go strong and we rely on the technology upgrade.
With the previous context, my friend, I see JavaScript is going strong, there is not a turn point anytime soon, in that line of thought and the vision of this new App that we developing, I need a framework that I can rely on for years, 10 if possible.
What could be quite confusing is that a lot of the examples in the official documentation are still using Blaze. Blaze no longer has any official support (not even for bug fixes or security patches) and should therefore not be recommended for new projects.
Could you clarify which official documents are pushing for Blaze? as far as I can tell, all the docs seems to be neutral with regards to the view layer.
Specifically, tutorials are written for React, Angular and hopefully Vue ( there is an open issue on Github to contribute to Vue docs, strangely despite a lot of folks being vocal about the “official” Vue support, no one in the community contributed to this issue yet) and also the Meteor guide list all the major view layers.
Blaze has been open sourced, so I don’t know how different is that from React or Angular in terms of integration and “official support”. MDG seems very clear, at least for me, that they don’t have the bandwidth nor interest to officially maintain view layers, which I think is better, they can focus on the build tool and data layer. The view layers seems to be very subjective and ever churning layer, there goes no week without a new view layer being proposed.
Good list, I see your point. It’s the docs/guide that is biased toward Blaze in some sections and not in the marketing material or overall strategy so it seems.
I think the docs should be neutral to the view but given how Meteor (being Blaze first) the docs has a places where Blaze usage is assumed.
Do you think we should open an issue for that? I see few potential enhancements:
Routing: I’m not sure how meaningful is discuss this without coupling it with the view layer, so in my mind this should be a subsection of the view.
Users/accounts: accounts has a backend component which is view neutral, but we have a front-end component specific to Blaze, so I think those need to be de-coupled
Collection: again I think this could be front-end neutral
Mini-mongo, tracker and session: these can surely be view independent, although in Blaze their usage can be emphasized
Account UI/markdown: I think these are fine but they need to be highlighted as Blaze only packages.
Overall I agree with your sentiment, I think the guide needs some refactoring, and I’d suggest an open issue and I’ll be glad to help with that as well.
@tab00 - I am not sure I agree with you - Blaze is alive and well and used by many in the community. It is stable, very easy to learn, very effective for many tasks that arguably Vue, React, Angular and other frameworks might be considered overkill for.
It is community supported and IMHO still a very good choice for engineers just starting out with Meteor. I would not want to see it removed from the docs. I think if we sweep Blaze under the rug it would be a dis-service to the Meteor community.
There may be a middle ground though. Since Meteor is front-end-framework-agnostic for the most part, perhaps we treat all these options as just that, front end options that play nice with Meteor. Perhaps the direction we should be taking is listing them all as options with objective pros and cons to help devs decide for themselves which direction to jump in on their Meteor journey.
I would advice not. Meteor used to be great, very easy to use with one recommended way to do things. It was very easy to learn and super productive.
Now, there are dozens of alternative. You have to choose everything.
On another hand, I have personally lost trust in MDG. I have invested a lot of effort in building an application built over a great technology that have suddenly become obsolete over night. Now, I am supposed to invest even more time to port my application (that is currently working great) to different technologies that are currently maintained. Which in turn are not guaranteed to be supported on the long term.
Meteor currently has no clear guidelines of what is considered the recommended way. it has transformed from being a very opinionated framework into being a general build system where everything is possible but things are chaotic enough that you have to do a lot of effort to figure what to choose and how to combine things. You can still do great things, but you have to figure out what to use and how to use it correctly first… Obviously, I am very frustrated.
Thank you @ahhatem, what are the over alternatives that you like the best?
One thing that I found quite interesting, is that the tutorials are a good start point, I found that a few of those things were outdated once I started to create something simple. I know that there is a comment somewhere on this thread saying that the tutorial is a starting point only and shouldn’t be the base for a new project. What are some of your frustrations so far?.
It might be worth for the community to consider other options with an open mind, everything for the best life of our projects.
@ahhatem, I generally agree with you that MDG has issues. Here is what I learned, avoid the noise. The JS world is moving too fast for us to be upset about one framework over the other. We still use Blaze for now (and it’s work well). So why fret and get worried. If things go sour, we’ll deal with it then. In the mean time, we are growing, selling, making money, developing etc.
The only constant is change.
On another note, look at the MDG team: https://www.meteor.io/team/ It’s very small and doing great things. Don’t expect miracles, just do your part and all will move in the right direction.
I mostly agree, MDG is doing a great job from a technical perspective. It just that, for me, it has lost its place as a low risk platform. At some point, I would have answered the question of “should I start a 10 years long project on meteor” question with a yes. That was when MDG managed to put together a great opinionated platform that is very easy and very productive and they had a clear vision. Now, they are still doing great things, but I simply can’t trust that they won’t stop supporting something in a month. I guess back to the JS world.
About classical meteor, I totally agree. I am doing the same thing. Keep working on what is working and make money. Worry about the change latter since it doesn’t seem that there is a clear upgrade path to anything.
But, I can’t really answer the question of whether Meteor is a relatively low risk investment with a yes. Currently, it s a high risk like the rest of the JS world. Funnily, I am in the exact same shoes, I am starting a relatively small 10 years project and I can’t stop thinkinig that I want to start it in meteor classic… but who with right mindset would invest in product that is no longer maintained by its inventor… Sadly, I will have to pick another solution… I would appreciate recommendation by the way
@Jame, most tutorials are still based on classical meteor. The vision that Meteor is no longer embracing. To be honest, I am not even sure what Meteor is becoming right now. Almost every single component in meteor classic is no longer maintained by MDG. They are all maintained by the community… They still work great… but no more big updates…
I believe the meteor documentation should be updated to clear state and clarify what is Meteor and its vision because currently, it is a bit misleading. It is not logical that the view layer they are no longer maintaining is the default and is all over the documents…
The same points are being repeated so many times that you can find most of the answers just by reading this same thread or the many similar threads on this forum. MDG made an announcement in 2015 to open source Blaze, shift it’s development to the community and position Meteor to be agonistic to the view layer so that they can focus on the build (Meteor), data layer (Apollo), hosting (Galaxy), and here we’re in 2018 still answering what MDG plans are for Blaze. This is an open source tech, so the community need to step up eventually to support and maintain it.
And for the folks who wants guarantee that a tech will exist for the next 10 years, well good luck with that, even economist can’t guarantee half of the jobs will exist in less then two decades. Just pick what works today and learn to adapt/evolve/refactor with the changes.
I hope this thread get locked, it has a clickbait title!
This thread has certainly run its course and seems to be getting some fairly predictable waves of the same feelings again and again. Thanks very much for all the positivity and constructive criticism. We hope Meteor continues to be useful for those who use it, well into the future.
As always, if you think something really needs some work — don’t hesitate to jump in and help out. We can all be a team, and this is open-source software at its finest.