[Poll] Meteor Prototyping Edition

RethinkDB works great with Blaze too… currently you need to use minimongo to get the data out but that’s ok too (unless you use the experimental Rethink package).

The reason Blaze was under ‘prototyping’ is because I feel it’s the fastest way to build out a UI. I’ve tried and tried to get Blaze to scale (as in team/codebase size) and have struggled with it (as has Arunoda which is why he has released so many Blaze experiments).

I don’t think React is a silver bullet, it just seems to be what Meteor is moving too (honestly I think Elm or Om is a better ‘technical choice’ but the big picture it isn’t a good tradeoff).

I think what is confusing with all of the upcoming changes is that 1.3 doesn’t seem like a minor bump but a major version release that could contain breaking changes.

I think Meteor should convert to SemVer and release all of the new changes on 2.0.0. This way the 1.x branch can still be maintained (if desired), 1.x is already fairly stable, people can choose which major version to use, and it will lay the future framework for new releases (3.x, etc) to keep up with future updates. Modules can choose which version to build for, and there wouldn’t be a separation in the Meteor world of where Meteor is going. Meteor should contain breaking changes, that’s the only way to advance the ecosystem.

Just my 2c.

3 Likes

Similar thoughts here.

However until the data flow and patterns with react are properly tested and easy to follow, then react in meteor is not yet a better solution than blaze for the beginner, nor for prototype/minimal viable product projects, as it will just create other problems and possess too much uncertainty and lack of reliability and predictability. Some key elements of the meteor react stack and patterns are still to be vetted out. But eventually it can be, given sufficient work.

In either case, it is not something that can be flipped right now or over night.

maintaining blaze for now, I imagine, is not much different from maintaining react and angular 1 and 2, but maybe urigo and dgreensp? can tell more about that.

as long as maintaining support for blaze, does not limit innovation and possibilities with babel, npm, es2015+, react, redux, webpack, hmr, code splitting, loaders, routing, etc, and anything else we need and want, then by all means.

Eventually when the documentation, patterns, guides, etc is up to par and things have been refined, then react can be just as good for prototyping and MVPs if not better, and with blaze compatibility as a layer on top, mdg need not maintain multiple tracks, it all comes down to add-ons.

But until then, and the tracks can merge or one becomes obsolete it does look like it is necessary to cater to each independently, in one way or another, and using packages for customising flavours should be sufficient, for clinical meteor and other vertical solutions as well, assuming the underlying core is flexible enough.

Ps.
I’m already on the webpack+react+redux etc innovation track, so the blaze support concerns is just to show respect to others, and lets be fair, onboarding new people may as well be via react soon when ready for that, so that’s not really an issue, the real concern should be for those with existing investments in blaze developments and deployments that need some return on their investment, and a little tlc and lts.

1 Like

This would be a waste of MDG’s time. But it would be a great community project. fork meteor or pin it to a specific version and pick a set of well defined packages that work well for rapid prototyping.

3 Likes

I think we could focus on a code generator (maybe with an IDE) without any modifications to meteor core. When core changes we just change the output of the code generator to reflect best practices.

In fact, this already exists but could be expanded upon: http://www.meteorkitchen.com/

2 Likes

After reading most of the discussion in the thread, I think the best way to achieve this would be a Meteor Prototype Edition package pack and guide website. Basically it should let you copy-paste your way to success.

You could pick a standard for everything - basically you could say bootstrap is the best CSS framework, have that tie into a bunch of pre-made bootstrap/Blaze components for all kinds of junk, etc.

6 Likes

I suspect that once the Meteor Guide is fully implemented, the desire for an official Prototype Edition will largely evaporate, because it will be so simple to role your own. For example, here’s the “Prototype Edition” I developed for my students:

Philip

2 Likes

You are putting too much stuff in one plate.

Some changes are good and should get in sooner than later. Others are a matter of taste.

An old saying in my country says that “to make happy everybody, you end up to make everyone unhappy”. That is exactly what it feels like. I think Meteor sometimes suffered of chasing the fads more than solving the biggies. There is too much relativism in the Javascript world today. Too many options and too many choices most of them with their pros and (do not forget) cons.
For example supporting Blaze, React and Angular is going to be quite a challenge. If you want to build packages you have to do it in the Angular way, the React way or the Blaze way… how much time is going to be wasted by the community to rewrite the plugin X that was originally written in Blaze for React or maybe for Angular… Now I also have to think “Which one is going to be the one that stick?” And try to do a good bet so I do not have to redo everything later when some options are abandon…

At different times I used Blaze, React and Angular. My favorite is … It does not matter. But this relativism “Meteor is just a collection of packages, choose your favorite flavors” leads to confusion and waste ton of community time in rewriting, refactoring, dealing with each different edge case of the permutations of the plugins…
Part of Ruby On Rails’ success came from making things opinionated and simple. When I used Backbone, I used to find 3-4 ways to solve a problem and wasting time to find out why different people used those different solutions.

I think that sooner than later it is better to make bold decisions and stick with them. Evolve them but unless something it is clearly 4x or more better, do not disrupt the past. I think that sooner than later it is better to make bold decisions and stick with them. Evolve them but unless something it is clearly 4x or more better, do not disrupt the past. And frankly in this matter, waiting a little is a good strategy. Time wipes fads and make good choices to stick around.

As an entrepreneur I want to spend time building my product, not chasing the latest changes and waste 50%+ on my time on refactoring code that is already good and work just because I want to run on v1.3 best practices instead than v1.2… because it is going to be pretty much the same story with for v1.5, v1.6, etc.

3 Likes

I agree, since i know Blaze is a gonner, i have been overthinking options and my projects are stalled.

1 Like

@vjau hmm… no need to stall your projects.

  1. keep developing/maintain your current blaze projects, until you have an alternative viable for a switch
  2. startup 2 more branches
  • a - react + blaze, via react-template-helper so you can replace your blaze templates with react components from the bottom up, and get a feeling with react as an alternative
  • b - react pure, without the mix, so you can get a feeling for react in a more pure environment, consider adding redux, router and webpack when your confidence level increases

the thing is that your projects are normally much more than purely a technical matter, and much of the work you do has blaze or react as only a fraction of the bigger picture. eventually you can move your user base and UX design and experiences over on top of a more efficient technical foundation as you evolve.

currently for blaze there is no solution in sight for code splitting and other performance and scalability related challenges, so while it works now, then eventually if you are succeeding you’d be looking to enhance your initial technical solution anyways.

for both blaze and react, with meteor and the live query nature of using oplog, mongo, stateful websockets, etc, there will be a problem with both vertical and horizontal scaling. while meteor made real time data relatively easy it made it easy by sacrificing scalability, a problem not solved, so it seems, although it can be pushed for a while higher hosting cost. in short: an efficient scalable design is missing.

so… for now - if you want…, carry on, and spend on r and d for your future. it is necessary. there are no magic, just things people don’t understand. when they get under the hood, it becomes science. and you realise you have to do the work.

1 Like

I have two main projects, one old and big (++), and one more recent and less advanced.
For the big one, i have no intention to rewrite it in React, it’s too big. I have started to do a mobile version, i considered React Native but it needs a “traditionnal” backend, for which Meteor is not really useful atm. I have considered to write a JS frontend with meteor and react, but 1.3 beta is not really usable atm, and i can’t stand writing in 1.2 with everything global.
For my smaller project, i have started rewriting everything in React with Webpack since this summer. But “getmeteordata” feels awkward, and i’m not sure it won’t be a gonner too. So i have started considering other options like redux, but i stlll don’t understand how it plays with databse. I have considered Graphql too, but it seems not mature enough.
I’m a bit lost, before the meteor/react “fiasco” i was very productive, now i have lost confidence, and i’m looking for an exit plan.

one possible exit plan is to make your frontend in react components, which lets you more easily switch between frameworks as it has more support than blaze, it also works well with webpack so that’s another concern covered.

also check out yeoman.io , actually back in 2012, while evaluating different nodejs frameworks and integration stacks, after having run with node, node+connect, node+connect+express, node+connect+express+railwaysjs/compound I was looking around and while finding derbyjs’s documentation and organisation too messy, and yeoman without clear end to end scope, meteor seemed like the more stable bet.

some concerns, such as SSR and incremental loading never had a solution in sight, although @dgreensp @avital once started lining up a 3 point road map for it after the spark to blaze move, but it never came through all the way. I wonder what happend to the plan and them? dgreensp did solid work and suddenly no news for quite a while. now webpack+babel+react can deliver that, and redux can provide for a more predictable flow, but the data patterns and scalabilty still seem to be a place of uncertainty.

donejs, and maybe there are similar projects, what are angular folks using as their defacto build, dev and backend system? may also be of interest.

getmeteordata is a mixin and like the entire data layer with meteor, it raises some concerns so it needs time to settle and find its nature, instead of mixins higher order components seem to be the deal, but again we need to use getmeteordata ? so, go for something that works for now, establish the certainties possible and accept the uncertainties needed. maturity is also a matter of establishing predictability for which redux is a key. expect some work to be done on the data integration later, it raises too many questions.

for react, don’t start with anything less than 1.3-modules-beta.2, and roll your react packages and modules from npm only. with 1.3, thereactivestack/meteor-webpack will also be much better integrated, both using node_modules and package.json and global’s can be a thing of the past. (but I guess you are comfortable with this already since you wrote you’ve done react + webpack since summer)

you may or may not get your blaze apps rejuvenated when/if blazereact and or blazecomponents work on top of react in a way that it integrates seamlessly with the underlying react foundation, and thus can benefit from the webpack+babel HMR, codesplitting, and such. same for a possible relief for the data backend and oplog livequery scaling issues.

1 Like

Is Blaze really dead? I hope not. I must have been out of the loop. I made two projects with React after a lot of time spent figuring it out. And it seems that React just takes much more time to write and the results are almost the same. I’m going back to Blaze for future projects.

1 Like

Amen. Except I didn’t know Blaze was already declared a “goner”. I hope not. I’ve already lost a lot of time and $$ because of this split.

You’re joking, right? You actually took the time fully learn React (React and what, Tracker?) and built two projects with it, and you’re not satisfied with the effort it took or the results?

Will you elaborate on your experiences please? For example, what do you mean by the results are almost the same? How/Why does React take more time?

One of the main benefits of React is maintainability. This won’t really show until your app gets more feature requests and different changes. Debugging is a close second… the debugging tools available for React are nicer.

That being said, if the time to write is important than Blaze would be a great fit.

W[quote=“jaredmartin, post:38, topic:15288, full:true”]
Is Blaze really dead? I hope not. I must have been out of the loop. I made two projects with React after a lot of time spent figuring it out. And it seems that React just takes much more time to write and the results are almost the same. I’m going back to Blaze for future projects.
[/quote]

And the first indications of the React hype bubble beginning to pop. :smile:

For what it’s worth, there’s quite a large group of folks whose business and staffing models rely on the templating layer for designers, junior devs, and others to interface with. So, the Spacebars API will probably stick around via Sideburns, Blaze 2, etc.

It might very well migrate to React underneath; but the Spacebars API will stick around, since HTML is part of the W3C standards.

Maybe MDG will migrate away from Blaze; but even if they do the same as they did with D3, the worse that will happen is it will go to the community for support, and someone will create a custom distro to add it back in.

1 Like

I’d like to chime in and say I’m also not happy with React currently… I really miss how simple building Blaze templates was - converted components have become fairly verbose.

Haven’t had to use the debugging tools yet either & I agree with:

it seems that React just takes much more time to write

Also not a fan of being unable to use jquery to easily manipulate DOM & SSR just blew up the server when I tried it (CPU usage, most likely a lack of configuration on my part however).

Not to mention the browserify overhead which caused 25 min+ build times

The only reason I’m still using it is because I wanted to use material-ui but considering reverting back to Blaze though, now that Materialize has a component I want to use…

3 Likes

… converted components have become fairly verbose.

It sounds like you may need to break up the components into smaller chunks. I’ve found this article really helpful:

https://facebook.github.io/react/docs/thinking-in-react.html

Typically if a component gets more than 50 lines long I get a twitching feeling in my eye :laughing:

SSR is def. a hassle… I personally don’t bother with it. Services like https://prerender.io will allow you to get SEO without any of that hassle. And you’ll save a bundle of CPU cycles! They only charge per cached page so free or $15 a mo. fixes it.

1 Like

I will have something on this soon :slight_smile:

2 Likes