[Poll] Meteor Prototyping Edition

announce
1

I’m really looking for some community feedback for solving the issue with a large fragment of people not wanting change and would like a Meteor that is more like plugging in leggos and less configuring.

Unfortunately this means that Meteor can’t keep up with the latest and greatest and do both.

One idea I had was to create an official Prototype Edition that would be essentially frozen and would focus more on doing things really fast, even if that means creating a less maintainable app and not having the latest bells and whistles.

Beginners and prototypes both fall into the same category. You want to build an app super fast and with little configuration. Neither want the latest and greatest and both want things to be more stable.

User accounts UI is a great example. Most production apps won’t use this as is but for prototypes and beginners it’s perfect.

The Prototype Edition could be a version tag that packages could target so when you install the package it’s been tested to work against that and would make for an easy target.

If someone started with a prototype app and wanted to remove insecure for example, they can, as well as add React. However, the app is now possibly not compatible with Prototype Edition packages.

Meteor Prototype Edition:

  • Slow moving / frozen API
  • Blaze templates
  • MongoDB as the only database (instead of upcoming ones)
  • Packages can be marked ‘approved’ so they just work and continue to work
  • Everything is aimed at creation speed (insecure, autopublish, more stuff like this)
  • Aimed at assembling leggos that are semi customizable (like accounts-ui)
  • Rails style generator to make CRUD apps even faster (with standard layout)

Meteor

  • Focuses on keeping up with the fast moving JS world
  • Aims at keeping med/large apps maintainable yet easy to build
  • Flexible view layers
  • Flexible database layers
  • no default insecure or autopublish packages
  • Improved subscription (eg, declarative like Falcor/GraphQL)

Thoughts?

  • Sign me up, I want it!
  • No, this is not good
  • I don’t care either way

0 voters

Show results
1 Like
2

Hmm. My vote wasn’t counted in the category I chose (I wasn’t paying attention, so can’t tell you where it did end up, if anywhere).

3

To be honest, I don’t think this is a good idea, as it would only cause even more fragmentation in the Meteor ecosystem. For me, the Meteor USP was to get things up and running quick and have a solid, scalable foundation for it. Choosing between one or the other would not be an option for me.

PS: Are you sure the poll counts correctly? I voted “no” and it still shows 0%.

5 Likes
4

Mine is counted in total number of voters but shown as 0%. But if you click on “Hide results” it does show correctly (in green).

1 Like
5

I’d say “No” is not a valid answer after all :stuck_out_tongue:

2 Likes
6

I have had similar thoughts, in order for meteor to easily onboard new developers with convention over configuration, smooth upgrading, backwards compatibility, and a just works intuitively feeling, while not loosing developers as their needs for performance, scalability, configuration over convention become more relevant, where too much concern for backwards compatibility is considered costly, limits innovation as well as their potential.

a beginner/prototyper, is currently better off benefiting from the smooth work flow of the blaze template system views, helpers, events, hooks with flow router and jquery. It is super easy to communicate and work with, and tested. At some point they will hit a wall, but then they can follow the track to the intermediate and advanced levels.

If they were to get started at the current state of integration with meteor 1.3 and react they would be spending too much time on the stack rather than the product because there is heavy product innovation in progress and the integration/process is still unsettled and less clear. To get a flow with react something like redux is needed which in addition to streamline state management to some extend helps to achieve a clearer pattern like the blaze separation of views, helpers, events, hooks achieved.

an intermediate/advanced, is frustrated when backwards compatibility concerns, design and convention over configuration makes them jump through hoops to configure to their needs and limits natural adoption of winning technologies from the wide javascript node eco system. NPM modules and Webpack is what keeps me in meteor, otherwise I had difficulty justifying missing out on HMR, CODE SPLITTING (incremental/conditional/progressive/lazy/etc… loading), and a number of already made loaders for assets and various compilers that helps us do our jobs.

currently I’m working on 1.3, react, redux, router, and patterns for the data flows, and while I can understand some arguments for meteor’s own bundler/build system, it is somewhat frustrating sometimes because webpack solves these things already and better with HMR, code splitting, and loaders, and it can all be configured in the .babelrc, webpack.conf and package.json files. In that context configuration over convention is easier to get stuff done.

So I think the idea has potential. At least two tracks. 1) beginners/prototypers (convenience and convention over configuration) where things just work and is quick to get started with. For now with blaze until a react with eg. redux, and a router, and possibly a smooth blaze on top of react layer is ready, tested, and fully ironed out. Meteor react is still too young for that. 2) advanced (freedom and configuration over convention)

maybe a third track with intermediate balancing and serving as a mid way between the two. More importantly that specifying and locking expectations to a specific library at each level, is defining the mode.

Personally right now I just want to move forward, and not be held back by legacy. If I should be purely selfish I’d say stop spreading us thin by spending on blaze since I currently work on react, but with respect for trust and others who are not able to migrate right away, I understand. If separating the vehicle with different rockets that can be dropped when no longer an asset to propulsion, then so be it.

1 Like
7

Right now I just want to write apps, but I don’t want to do it with Blaze since it’s essentially dead. I’m now focused on React/Redux and eventually will look more at Relay/GraphQL. Learning all this stuff and learning how to make practical use of it within the context of Meteor are totally different matters though. I don’t think I’m the only person looking to make the leap from Blaze to React. I’d rather see forward-thinking guides on using React/Redux than this.

4 Likes
8

I think this is an important topic to discuss, but generally I think it is a bad idea to use polls for deciding such stuff. Opinions with very different views and expressed statements are a lot more complex than simple poll options - it is hard to fit with constructive feedback in such polls. On the other hand, polls help to represent general opinions, but when it comes to reasons and complex opinions they will fail. In cause of that I want to share my opinion.

The draft of that idea feels good and intuitive, but in the long run it will fail in my judgement. In the fast moving tech world, supposed standards are coming and going. The trends of today will be obsolete and out tomorrow. If you don’t jump on the moving train, it will be soon far away. And then it will be even harder to reach it.
If we split meteor and our ecosystem in two versions (slow moving, simple and beginner friendly version and an actual bleeding-edge like version that will fast move and tries to be flexible), there will be an emerging gap. With every iteration of changes (like spark to blaze to react), it will be harder to maintain compatibility. In other words, the ‘prototype edition’ will drop behind the train and will dismiss all the new features and enhancements. It will be just stuck there without the ability to catch up (because it tries to keep long-term-support in different aspects that are chained together).
Especially in the fast-moving JS world that will be a problem, the gap between the two versions will rapidly increase. Is that slow moving at prototyping aimed edition really the right way to go? Who benefits of an old-fashioned platform prototyping their apps? When you come into business, there will be a much larger migration path that can in the worst case scenario even fail your complete start-up (because time is money and migration can take a lot of resources). When you just started to develop with the trendy frameworks and tools like webpack, react or graphql it will take longer to achieve your first working prototype, but that prototype will work and there will be less work to go into production.
When you want to address beginners, the problem is even more serious. I don’t think it is the right way to let beginners start with an outdated platform. When they struggle into first problems and begin to scent the air of new technologies the frustration will be even further. It is much harder to readjust than to just learn something from the beginning right (or following the actual trends).

But I like the idea to enhance prototyping. Meteor is a great plattform, simple to use and widely enough integrated with the larger JS ecosystem. There are many great tools that you can use and will be able to use simply with npm in meteor 1.3. Packages like “insecure” or “autopublish” are great ways to just write your app without struggling about configurations and other stuff like security. Later the packages can be removed and you can simply add the things you had not to struggle about before - That’s the way to go! In my opinion we really don’t need to split meteor, the community and the eco-system. It is hard enough for meteor to keep on the fast-moving train - why should we make that problem event bigger? If we guarantee support for blaze and other parts that are possibly in progress of being “deprecated” and dropped for atleast a year or so, we will be on the good side. If prototypes, beginners and large projects starts with actual technologies like react, there will be less migration required and they will be happier. The ‘prototype edition’ will just interfere the developers, and the whole transition, enhancement and development of meteor.
This is just my opinion I wanted to share and sorry if it is hard to read or so (English is not my mother tongue).

4 Likes
9

I think this would cause too much fragmentation of the eco system and harden the path for beginners, who eventually want to deploy their apps to the real world.

In my opinion, a cleaner atmosphere in combination with a good meteor guide(this is no critic, i <3 the new meteor guide ;)) is already a step in the right direction.

1 Like
10

First of all, I love your contributions and your ideas. Basically, what you are proposing is already happening in Meteor world.

I consider Meteor out-of-the-box the Prototype Edition; using it for MVP strategies and as a nifty tool has been really, really awesome.

What I call “Beyond the Tutorial”, is where Meteor is heading now; Webpack, React, modules and smart(er) collections, GraphQL are some really cool topics. With the guide (@sashko awesome progress!) things are quickly evolving there.

So, basically what I want - is already here. I expect that breaking changes in 1.3 will most likely create the division what you are proposing.

Just to be part of the solution: Java (the platform, not the language) comes with SDK’s in the way you propose - Standard Edition, Enterprise Edition, etc. That might be a roadmap to follow. You might want have the opinion of @gschmidt regarding the future of Meteor in this matter.

4 Likes
11

One thing I wanted to clarify for my definition of prototypes… I’m referring more to the kind that are throw away or at least have no expectations of being stable. A business experiment of sorts. Like building a prototype car in clay. That will never hit the production line but will give a lot of insight for the business. They’re also able to move fast because they don’t care about production lines.

I also think if a Prototype Edition would work it would need some more quick and dirty packages and a file generator (like flow router setup already, etc…) that can spit out changes at lightning speed.

This could also be a very bad idea, but the idea struck me and I decided to put it here so everyone can poke holes in it to find out what the worst parts are.

Yea this was definitely a concern of mine. The only way I think it could work is that an ‘edition’ is only a version constraint so that it’s not a separate product. Still, very tricky.

However, the difference in view layers might be confusing as time goes on.

For me, the Meteor USP was to get things up and running quick and have a solid, scalable foundation for it.

In general I believe that you can only optimize for one thing if you really want to do a thing well. Otherwise you risk something being average or mediocre. I’ve found that Blaze is very unmaintainable but fast to write (Arunoda had the same issue with Kadira and re-wrote twice).

Are you sure the poll counts correctly? I voted “no” and it still shows 0%.

Not sure but when I hit show or refresh it worked for me.

This is along the same lines as I was thinking. However, to play devils advocate, one could argue that a total beginner would have an easier time learning react first instead of blaze and jquery (although this wasn’t aimed at beginners specifically).

Personally right now I just want to move forward, and not be held back by legacy. If I should be purely selfish I’d say stop spreading us thin by spending on blaze since I currently work on react, but with respect for trust and others who are not able to migrate right away, I understand. If separating the vehicle with different rockets that can be dropped when no longer an asset to propulsion, then so be it.

Yea I think I share a lot of the same sentiment. Also if MDG is planning on deprecating things like Tracker and Session, etc… then this idea would be a major burden as Blaze really requires those.

In the fast moving tech world, supposed standards are coming and going. The trends of today will be obsolete and out tomorrow. If you don’t jump on the moving train, it will be soon far away. And then it will be even harder to reach it.
If we split meteor and our ecosystem in two versions (slow moving, simple and beginner friendly version and an actual bleeding-edge like version that will fast move and tries to be flexible), there will be an emerging gap.

I agree. However, my intent was more for prototypes that have a short life, usually a throw away so they can be built in a production system. Like a hackaton app. I don’t think it would be good for an app that’s constantly iterated on until it’s ready. You would be better off just writing a normal Meteor app.

I’ve found that this creates security holes and is a real struggle to get good performance when these are an afterthought.

This is just my opinion I wanted to share and sorry if it is hard to read or so (English is not my mother tongue).

Perhaps not enough true prototypes will be built and this would cause a lot of confusion. Very good points though!

I’m starting to think this too actually.

2 Likes
12

I think this is a good idea. Many developers don’t understand the business-side of things where MVPs (aka prototypes) are vital. (note: This isn’t because they can’t understand, just that they are focused other places, and haven’t given this side of things as much thought).

That said, my guess is most people on this forum will not like this idea. However, it doesn’t mean it isn’t a good idea.

1 Like
13

I’m not sure about such a radical statement.
Meteor MUST be easy to configure and maintain, that’s great for everyone, and should not be treated as reason to break community apart, but instead as community primary aim and objective.

I hope, blaze 2 will come and bring back the ease of prototyping.
The only really thing meteor lacking on a current state is model. It’s harder to begin a project, in case most meteor practices are getting outdated. No recommended project structure, no recommended module architecture, no possibility to begin with a scratch every time you caught up a new thought.
But all that just a matter of time. IMHO.

1 Like
14

Does meteor have a Yo CRUD generator equivalent?

1 Like
15

Are the deprecation of Tracker and Session just musings on a hypothetical scenario? Or was there discussion about this somewhere that hinted at this?

(I dont mean to derail the topic)

16

There are a few. I made one here thats not done but uses actions instead of ‘controllers’:

My previous generator has a concept of pages and controllers, which are basically functions for a domain.


[quote="moberegger, post:15, topic:15288"] Are the deprecation of Tracker and Session just musings on a hypothetical scenario? Or was there discussion about this somewhere that hinted at this? [/quote]

Mostly musings based on a lot of chatter. Lots of complaints about Tracker being unmaintainable in Blaze because it’s unpredictable and hard to debug. Tracker is very inefficient with getMeteorData and causes a laggy UI in certain cases with React (other cases works fine).

Session, and template variables via ReactiveVar and ReactiveDict are overlapping quite a bit with React’s setState and is completely replaces if you use Redux.

Being that Blaze2 will be a thin wrapper to separate JSX from JS (from what I understand) then it will inherently have the same issues as React and will work better (from a performance standpoint) with Redux.

However, I doubt they’re going away I just doubt they will be improved.

17

IMHO, the problem is not about MDG introducing too many new features (as long as the code is of good quality, which has been the case so far), but about them maintaining the old ones.
If they want to concentrate their efforts on React, that’s fine with me as long as they keep maintaining Blaze (i said maintaining, not adding new features). More than a “prototype edition” which i think would give them two times more work, i would prefer a LTS edition.

18

You’ve got the right approach, but expand on it a bit. This is the same underlying issue as the discussions about long term stable release and industry vertical release tracks.

Meteor Prototype Edition:
Long term stable API
Blaze templates
MongoDB as the only database (instead of upcoming ones)
Packages can be marked ‘approved’ so they just work and continue to work
Everything is aimed at creation speed (insecure, autopublish, more stuff like this)
Aimed at assembling leggos that are semi customizable (like accounts-ui)
Rails style generator to make CRUD apps even faster (with standard layout)
TinyTest/Mocha for testing

Meteor Business Edition
Focuses on keeping up with the fast moving JS world
Aims at keeping med/large apps maintainable yet easy to build
Flexible view layers
Flexible database layers
no default insecure or autopublish packages
Improved subscription (eg, declarative like Falcor/GraphQL)
Chimp / Velocity for advanced testing

Meteor Clinical Edition
Extended long term stable API
Blaze templates to begin (React/Sideburns/Inferno in the future)
MongoDB as the primary database (with SQL interface)
Curated packages from the clinical meteor track
Everything is aimed at legal compliance (FDA, HIPAA, CLIA, etc)
Aimed at assembling cards for a Card UI
Nightwatch / Gagarin / StarryNight for advanced testing
D3 as the data visualization layer
Rails style generator to make CRUD apps even faster (with standard layout)

6 Likes
19

As someone who teaches Meteor to newbies as part of my software engineering course, I am not in favor of a “frozen” prototype edition for the simple reason that some of the “fast moving” features of Meteor/Javascript will make Meteor easier for newbies to learn. For example, Meteor 1.3 with ES 6 modules will make both testing and application modularity way, way easier for newbies.

I think the simplest way to satisfy the Newbie Demographic is to make sure that the introductory tutorial (and related intro materials like Discover Meteor) get no more complicated with each release, and ideally, get more simple. Among other things, I think that argues for continued availability of Blaze as an “onboarding” UI, even if most future development energy is spent on React.

8 Likes
20

This is a bad idea. Generally (and philosophically) when you come to a cross road you choose one direction or the other and make peace with whatever you have chosen. Having an option open will lead to the law of unintended consequences and lead to more confusion.

If the requirement is to prototype fast and for beginner then we need to figure out better approaches in the existing environment with react or what ever might be the toolset. Maybe better guides for beginners, or more standard plug and play packages etc. Also even newbies require clear upgrade paths for their skill sets. Forcing them to work with frozen release will not help them in the long run

5 Likes