To be fair then you need someone to take a frontend developer role. Some designers can write nice frontend markup and create awesome designs.
Every designer i’ve worked with that made markup prefered to have their own static html templates and I took them and put them into PHP/Ruby/etc… Why does everyone think that designers can’t write Ruby templates but for some reason because it’s JS they have to be able to use it…making JSX a non starter.
just my opinion.[quote=“eleroy, post:215, topic:13561”]
I had to do another rewrite to integrate FlowRouter in place of Iron-Router, because of the infamous re-rendering issues, and now you’re telling me I’m going to have to rewrite my templates?
[/quote]
This should be less of an issue as authors start to decouple their code. Now FlowRouter is very decoupled and switching to React templates was a 3 line change. They’ll have to use good coding practices to work around multiple DBs and view layers.
It’s a huge con that often goes unaddressed in the discussion of tradeoffs of front end frameworks that implement Shadow or Virtual DOM’s. (I found it troublesome when I first tried Angular). However, it seems necessary for better performance. Blaze seemed unique in its strategy, given that all other frameworks began to use some DOM abstraction. It’s certainly the direction front end frameworks are moving, so I guess it will be the demise of jQuery and jQuery plugins. In a sense, by deprecating Blaze, and transitioning to React we’re trading one walled garden for another since there are a certain set of tools from the old paradigm of direct DOM manipulation that will no longer play nicely. It’s painful, but the benefits will hopefully outweigh the setbacks as the React repository of components grows. I am particularly looking forward to the performance boosts in this transition.
A lot of people is/was using Blaze since until recently it was practically the only presentation layer available, so it’s natural that it has a lot of action under its belt - people used it extensively in almost every imaginable implementation, hence a lot of open issues;
Not enough developers are taking care of issues (this seems to be the general state lately) - probably due to the fact that many developers did their custom workarounds and fixes which on the other hand never ended up merged (nor submitted) into the main code (also partly due to Blaze’s unclear future)
So, basically I see two possible outcomes:
Drop Blaze entirely since it gives you too much headache (which you obviously already chose to do);
Hire more developers and get the issues fixed + augment it + assure developers (us) that Blaze stays for good, so they’ll gladly (finally) contribute.
I simply can’t see the logic in dropping the tech in which so many effort is put in, and so many developers depend on, all in favor of a ‘cutting edge’ tech, especially since you recently enabled its NATIVE use anyway.
I’m certain that maintaining backward compatibility with this hybrid solution will make your heads spin and ours fall off.
That won’t save any time for people in the Meteor community who invested in what you have created right now. It’s very sad that backward compatibility is not rule number 1. Meteor is actually used in real world applications, with customers, investors, families and changing things in this way will not help neither the community to grow nor new people adopting the framework.
Couldn’t have said it better. This was exactly my first impression: MDG is a group of geeks who are loving technology, but can hardly see the business implications of their decisions. In fact, change and transition management is one of the most important parts of software engineering. Been there, done that, for many, many large customers.
If this really was the goal of Meteor, they would focus on different things than the UI layer (which is working, not perfect, but working). Things like Mongo oplog handling for scalability, supporting other database systems etc.
So MDG is trying to attract people from “the Javascript universe” to “Meteor” even if this may upset a number of “Meteor inhabitants”.
I don’t know if this is good or bad.
This could be one good reason to fix these bugs, instead of dropping the whole thing because you’re chasing the latest cool kids. In my point of view, Meteor has already lost a lot of its “credibility” due to its instability (like changes in 1.2 that broke a lot of packages, or the unpredictable packaging system).
I managed a software company for many years, and know the issues you’re facing. And yes, we would have loved to drop certain parts of our own software, because they became unstable and unmanageable over time. But: we also had to care for our customers, so we often refactored these components instead, to keep them up and alive for those who had invested in our products.
To be honest, I don’t think that the recent decisions of MDG will attract any corporate customers. On the contrary: if I was a decision maker in a large enterprise company, I would look for a more stable and more reliable framework. Sad to say this, because I still have a lot of excitement about “the Meteor way”. At least how it was.
I think this sentence is exactly what I am trying to address. I’m saying that we are trying to switch to a less bug-filled and much more adopted platform, with a vast amount of wider community support, packages, and tooling, which has a lot of the features (and required API changes!) we would have wanted to build in a future version of Blaze.
The decision to switch wasn’t a light thing to chase cool kids is all I’m trying to say - the way you are phrasing it is a false dichotomy that assumes that the only reason to build the future of Meteor’s frontend on React is because it’s trendy.
Well, if you ask me, there is already a framework out there that covers exactly that. It’s called the MEAN stack; if you like puzzles. And its shere complexity made me look for a more opinionated approach, which made me end up with Meteor.
I think I got that. But I think you underestimate the power that arose out of Blaze’s simplicity. Anyway, we’ll see what the future brings.
So if it’s so superior why even bother with Blaze 2 in the first place?! Just drop it altogether and send us all to React.
At least we will know what to expect in the next six months.
All we know now is only that for the next couple of months you’ll be working on some hybrid presentation layer with a very vague specs that won’t be compatible with our current development anyway, so we’d be better off switching to React right now and not even look back at Blaze anymore.
Responsible for one of these large corps, I can say that sadly the focus is completely wrong. Stick to your UI and router choices please and focus all you can on making it all, including the DB layer, robust, secure, predicatable. Corps ask consistency and hate the “latest greatest”.
Well think of it like “The Mentalist”, this might be the perspective all the time, to create rumour of Meteor moving towards the React ecosystem to force the majority of people to switch to React anyway and then they just drop React as the replacement since it is the most opted frontend by Meteor developers.
LOL sorry no offence meant to anyone, maybe I’m just watching too much TV(Can’t stop watching - The Mentalist series)
<^ just trying to lighten it up, since this topping has generated too much heat ^>
Seems you are still missing the main concern and you again use technical arguments.
The point is that each time you make a paradigm switch such as Blaze/Angular/React or leave community dangling such as coffee/je, flow/iron, you split your legacy, not a bad word, eco system, Google,Stackoverflow, by half. You minimize yourself into dust if you keep using the technical argument of the day.
So if it’s so superior why even bother with Blaze 2 in the first place?! Just drop it altogether and send us all to React.
Both Blaze and React have good and bad sides. The ideal for Blaze 2 is to take good sides from React and Blaze and drop the bad ones.
Problem lies in the fact that from technology point of view it makes more sense to implement it by creating Blaze 2 on top of React, pushing it to behave like Blaze, than to create Blaze 2 on top of Blaze and push it to behave like React.
I understand the reasoning behind it. My concern is not purely technological but business-wise as well.
But, for the sake of argument, let’s stay at the technological level: do you honestly think that by the time MDG launches its first productive-ready version of Blaze 2 (or whatever it will be called by then), let’s say (my empirical yet optimistic estimation in the next 4-6 months, React will just sit there, first row, popcorn and all, and not evolving as well?
Quite possibly, by then React will leave Blaze 2 in dust, with at least half of current developers already migrated to it.
Again - why bother? To me it seems like a lot of effort - (too) little gain.
It makes more sense to continue to build Blaze in a way we all wish it to work - as a part of unified platform, and leave React as an option.
Wow this thread is crazy and great to see such feedback, I believe if the community does not speak about what they want then there is no point it’s up to MDG to listen and decide. If they want the community support or just alienate it.
@sashko it feels like you’re getting defensive, I think for good or bad this is great feedback.
I do believe MDG added Angular support, React and is now looking to change out Blaze is more about marketing and growth. Maybe I’m wrong but it feels like it and I can understand why but I wonder at what point to do start to lose your core community that have been using Meteor since day one.
in the next 4-6 months, React will just sit there, first row, popcorn and all, and not evolving as well?