Proposal: The Future of Blaze, Autoform, Accounts and Meteor

blaze
1

  • Move it to the community (the “Blaze Community”)

  • Start a patreon account (or similar) to help fund some core developers/repo managers (the “Blaze Team”)

  • Start some sort of system for prioritizing (voting) on the best use of time of core develoers hired by the patreon funding… preferably you can only vote if you donated to the patreon account. But you can comment, send PRs, and everything else even if you didn’t donate. The people who really value blaze and are using it in production will be happy to throw 10, 20, 50 bucks a month at the project, especially if they can have a strong say in the direction of the work. Others can contribute just like they would to any open source project and there will be the Blaze Team there to work on taking in their PRs.

  • Make it so Blaze can be an NPM package

  • Get clarity on the future of Atmosphere and Meteor… is there a need to move Atmosphere to community too? or can atmostphere packages be ported to NPM? I would be concerned investing too much in atmosphere being around in 2 years (if it were on MDG to keep it up-to-date. Not throwing shade on MDG at all. They have limited resources/time/mindshare).

  • Make accounts a part of “core” (blaze community should take up the PR/Issues with the core accounts-related package(s) )

  • The “Blaze Team” should take over the autoform package (if aldeed is okay with it). This is core to the blaze value proposition and huge number of issues and PRs should be moved forward along with the new Blaze Community

  • “Blaze Community” should consider forking meteor 1.2 (or making a package to add 1.2 functionality to whatever meteor x.x.x is out). I like being able to move my file structure around, rename files, and not worry about import/exports too much… especially in the early stages of development.

There are a lot of ideas up top, the core must-haves for me are:

  1. fund it properly with some mechanism for showing best places to invest work
  2. get it on npm (I suspect this may be the first thing to get out of the way)
  3. bring in autoform to get worked on
  4. bring in accounts to get worked on
  5. consider other stuff like view-model, etc.

I think if we tackle the majority of these points, we can save blaze/meteor/atmostphere from extinction.

Let me know what you would add; what you would take away; how you would prioritize each action.

1 Like
2

Why fork 1.2? Why not just use 1.3+ and have the option of using imports or not. You can still [quote=“a.com, post:1, topic:26237”]
move my file structure around, rename files, and not worry about import/exports too much
[/quote]

in 1.3 if you keep all the files out of the imports folder.

3

okay I will axe that suggestion

4

You don’t have to worry about Meteor Blaze going extinct. [Tools don’t die.] (Tools Never Die. Waddaya Mean, Never? : Krulwich Wonders... : NPR). Fork the repo and in 25 years you can still pull 1.3.

carbon paper (still being made), steam powered car engine parts (still being made), Paleolithic hammers (still being made), six pages of agricultural tools from an 1895 Montgomery Ward & Co. Catalogue (every one of them still being made) . . .

But what’s the motivation in continuing Meteor Blaze development? We put our first Meteor application in production back in version 0.6 and developed several more over the past few years, up until the present (1.3). But now we are doing new application development in Meteor + React + Redux and feel it’s a better framework for our development. And we’re looking forwarding to Apollo, which looks like a much more marvelous approach to querying data.

We kind of wonder if Meteor has any future at all. Instead of seeing a dedicated team of code custodians working to maintained Meteor, we’d rather see talented developers devoting their energies to next generation tools. Atmosphere can be replaced with NPM leaving Meteor’s pub/sub, reactiveDict and things like accounts. But pub/sub stuff could be replaced (hopefully) with Apollo, and Auth0 gives you all the advantages of account-ui and more.

React syntax is kinda weird, but once you get past the initial learning curve, we find that it feels like a more mature way to build reusable UI components which have better separation of concerns.

We also find ourselves working more productively than ever thanks to Kadira Storybook. Storybook allows us to design and develop our React UI components, writing stories to represent each state. And if you configure Webpack to hot compile your LESS on file save, then you don’t even need to run Meteor (webpack does it faster than Meteor’s build process).

Then there is Redux, which allows you to do things like store your entire application’s state. We’ve been using state machines in our Meteor + Blaze apps for years (thanks to the advice of @natestrauser) to manage complex UI like shopping carts and checkout pages. So Redux felt like a natural extension of an approach we were already using on an ad hoc basis.

So I just kind of wonder why you’d prefer to see work continue on Blaze when these other technologies have been invented to address the shortcomings of those approaches to web development.

I use to write Visual Basic applications in the 90s, and I felt it was very disruptive when the .NET framework replaced VB with a more strongly-typed, OOP version of the language, I had to learn new concepts and new ways of doing things. Ultimately I came to appreciate C#/VB .NET as a more professional framework which allowed me to work even more productively and better organize my applications. Meteor was a bank robbery; a framework developed to finance work on Apollo. It was also a valuable technical exercise.

So just wanted to ask why you preferred Blaze? Have you played with React? Do you prefer a more muddled approach to business logic? :wink:

If you’ve ever written a Blaze template with a ton of logic before, you can see the benefit in [React]. Instead of muddying up our markup with a gnarl of nested if/else statements, we get a much cleaner method call, putting our logic where it should be: with our other logic…

[React is] new and a bit odd at first, but it’s something that you should definitely consider adding to your toolbelt. Hype aside, it is neat and has a major impact on how you think about organizing your application.

https://themeteorchef.com/blog/react-vs-blaze/

Cheers!

6 Likes
5

I looked into Auth0 and was very impressed, but decided in favor of Meteor accounts for my app.

  • Auth0 charges a monthly fee after the free tier’s capabilities have been maxxed out.
  • The Auth0 UI does not match my site UI. I can customize the Auth0 UI, but if I’m rolling my own Auth UI anyway, it’s easy to tie it into the Meteor Accounts package.
  • I would be concerned about having my users’ login data controlled by a company other than my own.

I had an excellent experience building my apps Auth UI and tying into Meteor accounts.

2 Likes
6

Is there any reason in particular that there isn’t an NPM package similar to meteor’s accounts? I know there is passport and SaaS options like Auth0 but I am definitely surprised there is nothing like meteor accounts out there.

I’ve used react a little bit. I’m still getting the hang of things. I find I can move so much faster using blaze components though. More react practice needed I guess.

How are you managing pub/sub with react? Is redux keeping track of that and each component talks to redux?

7

At $12 for 1000 active users. it’s about $0.01 per user per month. Pretty reasonable for a commercial app, but I understand there are some developers with no money at all and no viable business model for their application. Active users are people who’ve logged in within the last 30 days! So if you have 5000 users but only 800 have logged in in the past 30 days, it’s only $12 monthly. For us, the price is trivial.

Yes you can customize the colors and add your logo without writing any code. You can also design your own UI and integrate it with the Auth0 API. But the nice things about using their login form out of the box it that it’s already device agnostic. Make it work, make it right, make it fast, make it pretty. In that order.

But part of the value proposition is that

  • you can’t know for sure if you’ll stay with Meteor forever. You might want to migrate your app to another framework someday (Apollo?) and you’ll have to migrate your users by asking them to reset their passwords–which is bad UX. With Auth0 you can take your userbase with you.
  • Single Sign On (SSO) you can share your auth0 userbase between multiple apps (useful for us)
  • as a company fully devoted to user accounts as a service, Auth0 has simply invested many more engineering hours into accounts then the Meteor team every did. For example, the Auth0 API has provisions for linking accounts–with Meteor you’re on your own.
  • there are other benefits too, like one click Blocking of user accounts. Gotta write your own code to do that in Meteor accounts.
  • one-click impersonating of users. Generates a link that can be used once to log in as a specific user. Useful for troubleshooting. Gotta write you own code to do that in Meteor accounts.
  • supports multi-factor authentication
  • supports any identity provider
8

I’ll invite my CTO to answer that! @wallslide I believe he is using React, but I only have the executive overview :slight_smile:

9

I asked him for you. He said currently he’s creating subscriptions based on router events. Then when the data is queried it’s loaded into Redux, which makes it available to your components throughout the entire app. So it’s not too different from a Blaze approach, except that the data is more widely available without having the sometimes frustrating problem of marshaling data across nested templates.

10

thanks for taking the time. That makes sense.

Next time you have a second, a couple questions about auth0…

  1. is there similar functionality like being able to call Meteor.user(), this.userId(), or Meteor.userId()?

  2. Do they give each user an _id similar to the mongo _id meteor gives?

  3. So I could use auth0 to do SSO across all my apps? Could I also use auth0 to offer Oauth to third-party apps like FB, Google, Twitter, GitHub, AngelList etc.? I would basically build that Oauth server with token/secrets that connects to my auth0, then provide the ui for people to get token/secrets (and the api documentation?)

11

Just to follow up. I’m definitely interested in seeing Blaze continue, and if that means it needs to be community-driven, then so be it.

To respond to the follow-up discussion questioning the need for Blaze:

I think nobody can deny that React can create unnecessary overhead for smaller projects, and especially for hobbyists, Meteor would be a tougher sell without it.

On the other hand, React is faster, and for creating reusable components, its obviously a great choice. But I think that too many “fatigued” js devs are looking at it as some kind of holy grail of frontend frameworks, thinking that since it can be adopted to almost any project, that the need for other choices has diminished.

I guess there’s a part of me that would still prefer having to research the (too many) choices in lieu of having one or two frameworks dominate the front end stack.

12 
export function TodoList(props) {
  const { todos, toggleTodo, addTodo } = props;

  const onSubmit = (event) => {
    const input = event.target;
    const text = input.value;
    const isEnterKey = (event.which == 13);
    const isLongEnough = text.length > 0;

    if(isEnterKey && isLongEnough) {
      input.value = '';
      addTodo(text);
    }
  };

  const toggleClick = id => event => toggleTodo(id);

  return (
    <div className='todo'>
      <input type='text'
             className='todo__entry'
             placeholder='Add todo'
             onKeyDown={onSubmit} />
      <ul className='todo__list'>
        {todos.map(t => (
          <li key={t.get('id')}
              className='todo__item'
              onClick={toggleClick(t.get('id'))}>
            <Todo todo={t.toJS()} />
          </li>
        ))}
      </ul>
    </div>
  );
}

just is not as easy to read as

<template name="todo_template">
 <div className='todo'>
 <input id="todoInput" type='text' class='todo__entry' placeholder='Add todo' />
   <ul class='todo__list'>
      {{#each todos}}
          <li id="todoClick">{{todo}}</li>
       {{/each}}
    </ul>
  </div>
</template>

and
``

Tempalte.todo_template.helpers({
    todos: function(){
          return todos
    }
});

Tempalte.todo_template.events({
    'submit #todoInput': function(e){
          let todo = e.target.value
          Meteor.call('insertTodo, todo)
    },
    'click #todoClick':function(){
                  //do something with this._id
    }
});

Once you’ve worked in react for months, I guess you just pick up on the pattern quickly but while I’m learning all I can think of is… why??? Even with a bunch of {{#if}} statements and other junk, I still find blaze so much faster to grok. To me it seems like react is only better if you know react and know it well.

The thing I hear most cited is that you only need to look at one file, but couldn’t you just throw in a script tag to the template if the major issue is having two files? The other thing you hear about is speed, but at the end of the day, I think devs are the only ones that really notice this micro-optimization in speed. You average user is not like OMG that shadow dom rendered .0001 milliseconds so much faster then the other web app i used.

That said, I’m learning react because the demand is insane, and the demand for blaze is essentially non-existent (although you could segway your blaze knowldge into ember.js and .hbs)

3 Likes
13

@maxhodges Thanks for these excellent points. I have no doubt Auth0 is the right choice for many organizations.

When I first looked into Auth0, their Meteor package didn’t seem to be working with the latest Meteor release. I asked their support department about it and it was 10 days before I heard anything back. By that time I had already finished my accounts-ui based login system. I would have some concern that a new Meteor release could break Auth0 accounts.

I have a question for you about one of your points:

You might want to migrate your app to another framework someday (Apollo?) and you’ll have to migrate your users by asking them to reset their passwords–which is bad UX.

Would I not be able to access the same database from another framework? Does Meteor not use industry-standard password encryption/decryption?

Thanks in advance for your thoughts.

1 Like
14

That should be possible. In fact we learned how to authenticate directly against the Meteor database in order to migrate our user accounts to Auth0. For security concerns we disable Meteor’s accounts package when implementing Auth0 for an existing account. Then on a users first login after the switch, we authenticate again the Meteor database then migrate their user account to Auth0.

So yes, you could do that, but if the next version of your application is not built on Mongo, it kinda sucks to maintain a highly-available mongo database, just for accounts. I guess you could migrate the data into a new structure, like rethinkdb or whatever, but auth0 kinda gives you the same thing with less ad hoc development effort. In theory at least!

I agree their team has been poor in keeping their Meteor implementation example app up to date. I’ve been pestering about this myself. I think they’ll be updating it soon.

15

Maybe better than patreon?

https://opencollective.com

1 Like
16

I agree with the points you raise, but at the same time after building some large complex Meteor apps with Blaze, we never really got much reuse out of our templates. Part of the problem was that when you have complex “components” constructed out of multiple nested spacebars templates, the data-flow can get tedious, and template helper logic feels fragmented all over the place.

a few quotes from React docs with sources links

React is all about building reusable components. In fact, with React the only thing you do is build components. Since they’re so encapsulated, components make code reuse, testing, and separation of concerns easy.
https://facebook.github.io/react/docs/why-react.html

###Components are Just Like Functions

React components are very simple. You can think of them as simple functions that take in props and state (discussed later) and render HTML. With this in mind, components are easy to reason about. . .

We strongly believe that components are the right way to separate concerns rather than “templates” and “display logic.” We think that markup and the code that generates it are intimately tied together. Additionally, display logic is often very complex and using template languages to express it becomes cumbersome.

We’ve found that the best solution for this problem is to generate HTML and component trees directly from the JavaScript code such that you can use all of the expressive power of a real programming language to build UIs.

https://facebook.github.io/react/docs/displaying-data.html

While it may be a little more typing than you’re used to, remember that code is read far more than it’s written, and it’s extremely easy to read this modular, explicit code. As you start to build large libraries of components, you’ll appreciate this explicitness and modularity, and with code reuse, your lines of code will start to shrink.
https://facebook.github.io/react/docs/thinking-in-react.html

Blaze isn’t bad! I enjoyed working with it for the most part and still think we’d be faster building some things in Blaze (but maybe we’ll get faster as we are still new to React). But we feel like there are time savings in troubleshooting and generally higher code quality overall. It’s easy to test the states of your React components. You can just set the state as see how it behaves! With Blaze we often had to manually insert some data in the database to test something, then manually jump though various interface hoops to get to that template (like place an order as a customer, purchase that item as a buyer, then release to package to the customer’s mailbox so we could test the shipping options template…stuff like that). It’s a breeze to test your React components without even running your application.

here’s some stories for some components we are putting together for a new app. Sorry it looks like crap. I’d need to tweaks things to deploy the image and icon assets for this GitPages static site, but don’t feel like digging into it right now

https://white-rabbit-japan.github.io/blackship-design/?selectedKind=account&selectedStory=IconField&full=0&down=1&left=1

I should add that I’m the CEO at my company; not the CTO and not a full-time dev. I’m more like a product manager. So if Blaze was a faster better way to do things, I’d want my team use Blaze, because ultimately I don’t care if they use the latest cool tools or not; I care about time to market, maintainability, and code quality. Devs like to learn and use the latest cool thing, but as a business owner, what matters most is getting the job done. And from all I’ve learned in trying to make these decisions, I’m feeling the advantages of React will ultimately allow us to deliver better apps faster. (I pray I’m not wrong!) But your milage may vary. A lot if it depends on existing skills and experience and what you are building, etc. But I doubt a lot of people who successful transition to React end up going back to Blaze. We could do a poll!

17

Meteor itself seems to have inspired a lot of alternative “real-time” frameworks. It seems new ones are appearing all the time. Perhaps we’ll see a lot of new frameworks which take the best ideas from React but improve on various things (like it’s odd ball syntax). I doubt React is the end of history. There’s gonna be a lot more innovation to come. We thought Meteor was the killer framework a couple years ago. It seems web dev frameworks a shorter half-life than a new iPhone.

1 Like
18

I hear that. I am currently adding Apollo to my app, and don’t relish the thought of maintaining a MongoDB just for accounts. I’m hoping MDG may be able to fully support Apollo for accounts sometime in the next 4-6 months. :slight_smile:

19

I wonder if there is money for MDG in a similar service to Auth0 but tied to apollo.

1 Like
20

That’s a very cool idea!