Make this project a module

[wmertens]

This seems like a wonderful project but because of the git clone nature, it is hard to keep up with improvements of the base.

It would be great if the project setup is done through a configuration object, and all the heavy machinery is in a module. Kind of like keystonejs does it.

[mattkrick]

i've played around with this idea, but i'm still not sure how to do it eloquently. IMO, frameworks are dead (or dying). Boilerplates like meatier, although kinda verbose, are probably the best way forward since they're really flexible and there's no "magic"-- you see and control how everything works. While this angers folks who don't care to take the time to grok things, I'd argue it's healthier in production apps & if I can weed out the "javascript fatigue" demographic at the same time, it's a win all around. Sticking with the mantra of something like "maximum flexibility with reasonable defaults" makes the most sense to me & if you have any suggestions to stick with that, I'm totally open to it.

[jeffreywescott]

Yeoman, while dated, might be worth a shot.

[mattkrick]

yeoman & plop are good, but i just can't get into them because every project is just different enough to eliminate the benefit. I know there's a better solution somewhere, but it hasn't bothered me enough to bother researching a better alternative

[wmertens]

Actually, I am wary of generators like Yeoman. They tend to add lots of boilerplate and there is no way to differentiate boilerplate from your own code.

There is also no way to upgrade generated code so you're pretty much stuck with what happened to be the preferred code at the time of generation.

On the other hand, if the project is split in parts that typically require very little configuration and with minimal boilerplate for the parts that do, the former can be put in modules with a stable API, which allows updating.

So, for example, I as a user of meatier want authentication in my app, but I don't care how it is implemented, as long as it is secure. With configurable authentication, the implementation can be changed (even to the point of replacing the underlying protocol) without my code having to change. My code is now more secure because this project is more likely to notice and fix security issues that I am.

The same goes for React and Redux: implementing the best way to load the html and scripts is not my main interest. I want to write applications and have them talk to persistent storage via GraphQL. I want to write minimal server-side functions for mutating data, not having to worry about authentication, retrying, etc.

So IMHO meatier has the opportunity to provide the frame of an application, where users only need to create React modules and server mutation code.

To avoid the monolithic blob that Meteor is, meatier has to thread lightly and make maximum use of third-party libraries, perhaps to the point of having multiple implementations of some parts like the react initialization and database. There are a million options out there, and a big part of the value of meatier is in making the right choices so the user doesn't have to.

[bartekus]

What if we wrote custom generator ala hackathon ? This way on the first run we could force user to specify the intended use and thus enable / disable features and needed?

[wmertens]

@Bartekus That is the thing, if you use generators to create an entire project for you, you have no idea what is your code and what is generated code, and a few months down the road you have no idea why a certain line of code is there. If you clone the repo, at least you can go look at the blame info.

If instead the project is configured declaratively with meatier being a module, all the changes you made versus the default project are right there in your configuration, since you wouldn't configure defaults.

Then when a new way of doing universal rendering comes along, you don't need to change a thing in your configuration, you only need to upgrade

meatier.

Wout. (typed on mobile, excuse terseness)

[bartekus]

I hear what you are saying, but I can't help but shake the feeling that if we go about having meatier as a module then the huge aspect of the beauty that it has will be lost. Being able to see entire build, exactly how it is, add's to the end developers ability to scan thru code and thus learn faster from it. Look at Rails, they too use generators, and I think that's the best solution given that while it generates the code for the user, the code that it generates is the same code that user can put together themselves to achieve the same thing. We could have the generator itself being a module which would obscurificate the necessary code from the user and allow to both, keep the meatier as it is, and when necessary generate additional code thru modular extension.

[patrickleet]

Maybe some macros via sweetjs could be used? (Not sure how, but just saw them and think they are neat!)

http://sweetjs.org/ https://github.com/mozilla/sweet.js https://github.com/jlongster/sweetjs-loader

[bartekus]

@patrickleet that's pretty interesting, macros and webpack-loader could be a very potent combo... I'll have to look into this and try to understand it more

[wmertens]

I've thought about it some more and the smallest step in this direction would be to make the more static parts of meatier accept configuration, but still in the project.

For example, the redux store setup from #85 uses an array of middleware, so there could be a config function elsewhere that gets called with this array before applying it. Then whenever the makeStore.js changes the forks likely can simply pull the change and it won't change their customizations.

For the routing, a similar setup can be done.

For the app itself, the login dialog could accept a React element that shows the login dialog, defaulting to the current one. The sky is the limit on that one.

As for Ruby on Rails and macros, RoR uses a DSL to write routes etc, which pretty much amounts to writing configuration with macros. If a generator would generate 3-line files for routes etc, that's certainly acceptable. However, I am not a fan of DSLs since editors have no clue about the new language, so I would rather use functions that would do what the macros would do. A little more verbose but without magic.

[mattkrick]

@wmertens i think this gets closer to what we want. IIRC @AdamBrodzinski from the Meteor community wrote something that packaged up a router, redux, etc with reasonable defaults. It's a fine line to walk between making something user-friendly and making something for people too lazy to learn what's necessary to manage a production-ready app.

For example, I just released a redux store enhancer that solves all the problems that complicated apps face (https://github.com/mattkrick/redux-operations). Meatier would never use this, but things built with meatier would...

[noxtri]

Just my opinion you could create exported functions to simplify thinks so you can go to production faster,for example lets create db and tables

myapp/engine/server/database/dbFunctions.js(where engine is your generators/functions)

import r from './rethinkdriver';

export async function setupDB(name) {
  try {
      await r.dbCreate(name);
    } catch (e) {
      console.log(e);
    }
    await r.getPool().drain();
}

export async function setupTables(db,obj) {
  try {            
      let indices = [];
      const tables = await r.db(db).tableList().run();     
      await Promise.all(obj.map(table => r.db(db).tableCreate(table.name)));
      obj.forEach(table => table.indices.forEach(index => indices.push(r.db(db).table(table.name).indexCreate(index))));
      await Promise.all(indices);
      console.log(indices);
    } catch (e) {
      console.log(e);
    }
    await r.getPool().drain();
}

export async function dropTables(db,tables) {
  try {
    await Promise.all(tables.map(table => r.db(db).tableDrop(table)));
  }catch (e){
    console.log(e);
  }
  await r.getPool().drain();

and from myapp/server/db.js call the functions

import * from '../engine/server/database/dbFunctions.js';
const db = 'demo12';
setupDB(db);
const table = [
  {name: 'users', indices: ['email']},
  {name: 'lanes', indices: ['userId']},
  {name: 'notes', indices: ['laneId']}
];
setupTables(db,table);

//dropTables(db,['notes']);

sorry for any mistake i havent use rethinkdb or react im currently try to learn them so mostly copy paste your code.This was just one example you could create functions/constructors for templates,reducers,etc.I will try to add them myself while at the same time learning react,redux,etc..

[bartekus]

Hey, every contribution, is a good contribution. You live, you learn, so keep on experimenting.

[AdamBrodzinski]

@wmertens i think this gets closer to what we want. IIRC @AdamBrodzinski from the Meteor community wrote something that packaged up a router, redux, etc with reasonable defaults. It's a fine line to walk between making something user-friendly and making something for people too lazy to learn what's necessary to manage a production-ready app.

@mattkrick I agree with this sentiment.... once you start covering too much up it makes it very very hard to just tweak little things. You then lose all the time savings fighting it. IMHO the best way to save time is to make yourself a boilerplate and tab-triggers (in leu of CLI generators). I have one that's more less a 'master template' for most apps that I build: https://github.com/AdamBrodzinski/awesome-stack

FWIW, here's the link to simple-redux-react

[bartekus]

Problem is, boilerplate is too little, while going on with too opinionated framework is too cumbersome. Thats the beauty of meatier, it has everything you'd want and thus it's a perfect start for a lot of apps. I know many people who don't wanna bother with authentication or server side rendering, thats why meatier is popular and will be even more - it comes with these things so right out of the gates, it's one less thing you gotta worry about.

[mattkrick]

I think it all depends how you work. As is, you clone the repo, delete the kanban folder, and start making your app, which in my case usually includes copying a bunch of different components from previous projects, eg oauth, graphql schemas, etc. How are you guys starting apps differently?

[wmertens]

For me the big problem is maintenance. I have a project starter based off the webpack one and I've used it several times now, always cloning from the last project, stripping out the specifics and continuing from there. This means that for upgrading React/Redux/etc, or other improvements, I need to go backport those changes to all the other projects, not always trivial.

If the projects were more modular in their layout, that would be easier, but even then I tend to tinker with the layout.

[mattkrick]

Meh, no need to always rock the latest. If you don't need to upgrade, why bother? There will always be breaking changes, and the vast majority will be in able to allow for features you don't need, be it a bugfix, minor, or major. No matter how modular a starter is, upgrading something will always guarantee a possible break.

On Tue, Feb 23, 2016, 5:03 PM Wout Mertens notifications@github.com wrote:

For me the big problem is maintenance. I have a project starter based off the webpack one and I've used it several times now, always cloning from the last project, stripping out the specifics and continuing from there. This means that for upgrading React/Redux/etc, or other improvements, I need to go backport those changes to all the other projects, not always trivial.

If the projects were more modular in their layout, that would be easier, but even then I tend to tinker with the layout.

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/72#issuecomment-187935955.

[wmertens]

Well, I still think that this project can make it easier to upgrade and start. Choosing good frameworks and making good decisions for the dev helps, and allowing to use them in a way so there is minimal change should the underlying framework be changed as well (for example, putting all DB interactions in one place via internal APIs vs all over the project)

---

Here's a list of things I think meatier should do/already does:

• Provide a kit to make websites that have a server component with a database
• Database defaults to RethinkDB but can easily be swapped out for another one
• ES2015/ES2016 throughout, using WebPack or JSPM(*) for module loading
• Easy dev experience
  • Quick install
  • CSS pipeline with Sass or Less or whatever, vendor prefixing etc
  • Hot reloading
  • Stretch goal: Server-side hot reload of graphql modules :grin: (*)
  • Devtools like logging etc
• High-quality compiled sites (response compression, optimized HTML/JS/CSS, …)
• Universal rendering
• Responsive design and internationalization should be easy (*)
• React + Redux for site logic
• Server communication uses GraphQL for query and mutation
• Supports websockets for instant updates to clients
• Legacy Express endpoints supported (even via Koa) for easy migration path

(*) Not in meatier yet

Did I miss something?

---

So a typical scenario might be:

1. Clone meatier, install modules, decide on optionals like Less etc
2. Run dev server
3. Create components, reducers, actioncreators etc in client
4. Create DB models and graphQL endpoints in server
5. Repeat previous 2 steps until done

If an update to meatier happens, just pull it in, your changes will not conflict.

This means that the default App needs to be very modular as well and it only includes the Kanban app as a default. The developer should not be changing the example code.

[wmertens]

And one thing that Keystone does very well is that because it wraps Mongoose to define the DB Schemas, it creates an admin API that lets you change the DB data. Very handy, provided you mark the pieces that should be read-only as read-only.

[mattkrick]

Great stuff! Thanks for all the thought you put into this, as I've had a lot of the same thoughts myself. Here are a couple responses:

Provide a kit to make websites that have a server component with a database Database defaults to RethinkDB but can easily be swapped out for another one

This is impossible unless you have a stateless server & don't use sockets. Each socket package is gonna have its own client API. To minimize the pain of server/DB switching I try to keep everything compartmentalized, eg to change DBs change all the GraphQL resolve functions and you're set. In that way, it's kinda like a default.

ES2015/ES2016 throughout, using WebPack or JSPM(*) for module loading

webpack provides a lot more than jspm or rollup. I think the build step is one of those critical processes where we need to minimize the number of options by picking a winner (or maybe 2) and throw the power of the community behind it to make it the best. If I can be opinionated here to get more people into webpack & just 1% of those people make a PR to webpack, that's a win for everyone. Side note: Interestingly enough, some React Native solutions are already moving away from webpack towards a no-build solution.

CSS pipeline with Sass or Less or whatever, vendor prefixing etc

As a community I think we need to run, not walk, away from things like Sass, less, and stylus. Again, they split the community. Heck, sass is even split between sass and scss. They served their purpose, but now we have css-modules, postcss, etc and I can build an entire site using vanilla css files, or css is js, etc.

Stretch goal: Server-side hot reload of graphql modules :grin: (*)

This would be AMAZING. But you've gotta think about the use case. graphQL modules change relatively infrequently, so does it make sense to incur a 3 second rebuild cost for something that you'll change once a day/week? I think a better solution would be to have a "server development" mode that runs in a production NODE_ENV, but uses piping so any change to any server-only file will auto restart the server (and of course use the pre-build client/universal files). This also forces best practices on the dev: don't develop on the server & client simultaneously.

High-quality compiled sites (response compression, optimized HTML/JS/CSS, …)

I offer gzip & streaming as an example, but in reality, if your production site isn't using a CDN, you're doing it wrong.

Responsive design and internationalization should be easy (*)

i18n is something i really have no production experience with, but is on the roadmap (by people who are better at it than me)

Legacy Express endpoints supported (even via Koa) for easy migration path

Nope nope nope. No legacy. I'm really stubborn about this. You want backwards compatibility, don't upgrade. Bloating logic to support old versions is very ugly and eventually ends up in a performance sacrifice. This is why frameworks die. If you don't believe me, look at Meteor's Accounts package.

[jakobrosenberg]

I love the idea of Meatier, but in its current form it's too verbose for me. I feel like I'm using a framework where someone lumped framework and source code into the same folder. From a separation of concerns point of view, I'd like to separate the underlying mechanics of an app from the business logic.

[jeffreywescott]

What frustrates me about this thread is:

1. The whole joy of JavaScript is the relentless focus on modularity. Everything is moving toward fewer interdependencies, not more. Most of the best JS developers I know are relentless about this point.
2. Meatier is open-sourced, so if you want to "framework-ize it" (which @mattkrick clearly doesn't), you can do so. Have at it! Enjoy!

I'm actually not using "meatier" the repo, at all. Instead, I use it as inspiration for the things I build. package.json FTW.

[mattkrick]

@jakobrosenberg you gotta get the idea of framework outta your mind. frameworks are dead in production use. If you wanna make an MVP, meatier is overkill anyways. If you want something professional, your "framework" will be highly dependent on your business logic (eg poll vs subscribe). My next project is going to replace rethinkDB with neo4j and node with AWS lambda. I'd still consider it meatier (or maybe lambchops :laughing:)

[jakobrosenberg]

@mattkrick I think it's the file structure that makes me feel like I got tossed into the deep end. 115 files in 65 folders and I'm left with a very vague idea of where to start. For me that's not "trading a little simplicity", it's trading all the simplicity.

I miss a hierarchy that separates low level files from high level; configuration files from "system" files; source files from "framework" files (I know you don't see Meatier as a framework, but I hope you get what I mean). For instance, rethink.config.js is a no-brainer. I need to configure it to for my app to work, but what other files do I need to edit? What do I do if I want to start from a clean slate without the kanban example, what files do I remove? Is removing them even the right answer or do I need to edit some of them instead.

Ultimately I feel like I'm hacking the example app rather than creating my own. Whether hacking the example app in Meatier is better than hacking the framework in Meteor I don't know. I feel each approach is too far from the "middle" for me.

Sorry if I came across a bit muddled. I think what you're doing here is brilliant and I hope some day there will be a more intuitive approach for intermediate developers like me.

[jamesdwilson]

+1 for upgrade path. i don't know the right answer but i do know i'd like a way to easily upgrade.

[mattkrick]

I miss a hierarchy that separates low level files from high level; configuration files from "system" files;

Again, there are no "system" files. In a production environment, your system is defined by your business logic. Take auth for example. Meatier currently reuses the same component for login & signup. It doesn't implement a captcha for signup. It validates inputs on the client for login. It doesn't throttle or debounce or blacklist anything on the server. It tries to intelligently log in from the sign up page. These are reasonable defaults for a production app, but chances are your team will go through a week of meetings to decide if these are the correct decisions. When that time comes, you don't want anything more involved than a folder with code that is easily editable.

If this is your first app or if your app is so small that this is not true, then you don't need meatier. The target market will always be for a production-ready app. You gotta trust the process; I'm not doing anyone any favors by hiding complexity because if your app becomes successful, you'll eventually need all the flexibility you can get.

[jakobrosenberg]

"System files" as lack of better words. I lack the vernacular to clearly express my concerns.

I get the impression that this project is solely intended as inspiration for elite developers. That's your prerogative, but it has the potential to be so much more. You have something that could really take on Meteor.

Even abstracting all files (except server.js) from the src/server folder into a subfolder ("src/server/meatier"?) would make it more approachable. Server.js could contain the configuration for everything serverside and src/server could be for user-files/folders that could extend or replace files from src/server/meatier.

Beneath the surface all the "cogwheels" would still be available to developers. Those who want to mangle the content of the "meatier" folder can do so and those who prefer to extend or replace outside the "meatier" folder can do so. This would allow a separation of concerns. Ie. you'd only have a worker.js file in src/server if you want to extend/replace the original worker.js.

[bartekus]

@jakobrosenberg Please take a look at this structure and let us know if this is more in line what you are expecting. Keep in mind that abstracting based on subroutines is not only unfeasible, it's a anti-pattern imo. Structure should be reflective of the function that it performs and should not be fractured any more than to one common denominator that multiple functions share. So in this case, your suggestion about subdividing the server folder simply makes no sense; if you we're to open all the files in that folders you would see that they are not massive in size, are very well organized and self-explanatory to anyone willing to spend 5 minutes to learn about the inner workings.

[jakobrosenberg]

Hi @Bartekus, what am I looking for? The server folders seem identical.

I agree that structure should be reflective of function, but not beyond the respective concerns. I'm not concerned with the inner workings of most node modules and I'm perfectly happy with them residing in node_modules. If I do concern myself with a node module I'll import it and configure/extend/replace it as needed where needed. Meatier assumes I'm concerned with the inner workings of everything it itself offers, which is very far from the case. I'm not concerned with SSR, let alone its code. Nor am I concerned with workers, assuming they function as expected. Ultimately I'm not very concerned with the inner workings of Meatier as long as everything works as expected and should a part not work as I want it to, then and only then would I concern myself with it.

A global app- and/or server-config that allows me to override healthy defaults in various parts of Meatier would make it a lot easier to grok. It would allow newcomers to quickly grasp the power and flexibility of Meatier and configuration entries could be used to search the project for code of concern.

I might be overestimating the learning curve and complexity of Meatier since I have very little working experience with React and GraphQL.

[bartekus]

I certainly understand what you are saying but you have to understand that such approach while easier to initially grasp also has a learning drop-off, being that when user is not aware of the code the user will not be inclined to learn anything beyond it. We aim it at trying to make it easy to get into but also force the users to learn - without learning there is no progress - without the progress the momentum dies - when the momentum dies so does the project. Programming is an evolution, not just means to produce. We want to encourage active participation of everybody involved by exposing them to all the inner working of the build. You can't tell me that this approach doesn't work because rails has been build on similar ideas and that has proven to be extraordinarily powerful. While our roots might be coming from meteor, ideologically we take the rails approach - to build a community not a framework. If you look for a framework I highly recommend Angular 2. But neither meatier, nor r3stack are a framework, they are solution. Solutions that you can adopt either full, in parts or just look at to gain an idea/perspective of how you want to build the stuff yourself. In the end we'll provide a lot of ready-made components but we certainly won't be hiding code from end users. Code is poetry, if all you care is to have something working without having even slightness idea of how it work, it kinda defeats the purpose of being a programmer or developer, no?

[wmertens]

Be that as it may, it would still be nice for the code to be structured in such a way that implementing your own app doesn't touch the meatier code much.

That way, when the next redux api change happens, devs can simply pull in the changes without merge conflicts, and observe what needs to be done to the rest of the code.

Eg. The entire example app could reside under modules/meatier that you leave in place as inspiration. Something similar on the server side?

On Wed, Mar 2, 2016, 10:52 PM Bartek Kus notifications@github.com wrote:

I certainly understand what you are saying but you have to understand that such approach while easier to initially grasp also has a learning drop-off, being that when user is not aware of the code the user will not be inclined to learn anything beyond it. We aim it at trying to make it easy to get into but also force the users to learn - without learning there is no progress - without the progress the momentum dies - when the momentum dies so does the project. Programming is an evolution, not just means to produce. We want to encourage active participation of everybody involved by exposing them to all the inner working of the build. You can't tell me that this approach doesn't work because rails has been build on similar ideas and that has proven to be extraordinarily powerful. While our roots might be coming from meteor, ideologically we take the rails approach - to build a community not a framework. If you look for a framework I highly recommend Angular 2. But neither me atier, n or r3stack are a framework, they are solution. Solutions that you can adopt either full, in parts or just look at to gain an idea/perspective of how you want to build the stuff yourself. In the end we'll provide a lot of ready-made components but we certainly won't be hiding code from end users. Code is poetry, if all you care is to have something working without having even slightness idea of how it work, it kinda defeats the purpose of being a programmer or developer, no?

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/72#issuecomment-191449361.

Wout. (typed on mobile, excuse terseness)

[bartekus]

True @wmertens, However I've try to implement what you describe on r3stack, both authentication and kanban are clearly separated from the basic app itself. It's probably not perfect, but it's a move in the right direction I believe.

[jamesdwilson]

+1 something like this would make updates easier

On Thu, Mar 3, 2016 at 12:22 AM, Bartek Kus notifications@github.com wrote:

True @wmertens https://github.com/wmertens, However I've try to implement what you describe on r3stack, both authentication and kanban are clearly separated from the basic app itself. It's probably not perfect, but it's a move in the right direction I believe.

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/72#issuecomment-191599911.

Thank you,

James D. Wilson http://jameswilson.name http://lnked.in/technologist https://github.com/jamesdwilson https://twitter.com/thejamesdwilson https://twitter.com/thejamesdwilson

[jakobrosenberg]

I certainly understand what you are saying but you have to understand that such approach while easier to initially grasp also has a learning drop-off, being that when user is not aware of the code the user will not be inclined to learn anything beyond it.

Couldn't the same reasoning be used about every single node module? Every module author could insist on exposing their code for the benefit of learning. Obviously that wouldn't work and good documentation would be a much more efficient way to educate.

Frameworks, modules, languages, patterns, structures, etc. all serve as a means of productivity. Even learning serves as a means of productivity. But if I'm forced to deal with something that doesn't concern me for the sake of learning, it becomes counter-productive.

At the end of the day, despite the joys of scripting and programming, it's about productivity. Sure, it's great to learn, but it's not possible to learn everything, so you have to pick and choose what information is pertinent to your goals. Even if I became omniscient and there was nothing left to learn, I still would strive to structure my projects in a way that allowed me to deal with code on a need-to-basis. Alas, for now, I think abstraction and documentation is the best option.

[patrickleet]

This reminds me of a quote - "how do you eat an elephant? One bite at a time."

Just start with the example project and hack away. One step at a time. You'll get there. Watch videos and read articles to fill in the knowledge gaps. It's definitely a steep learning curve, but you'll appreciate the flexibility when you for example decide you want to no longer use CSS, and replace all of it with inline CSS with radium, or use mongodb instead of, or as well as rethinkdb.

On Thursday, March 3, 2016, Jakob Rosenberg notifications@github.com wrote:

I certainly understand what you are saying but you have to understand that such approach while easier to initially grasp also has a learning drop-off, being that when user is not aware of the code the user will not be inclined to learn anything beyond it.

Couldn't the same reasoning be used about every single node module? Every module author could insist on exposing their code for the benefit of learning. Obviously that wouldn't work and good documentation would be a much more efficient way to educate.

Frameworks, modules, languages, patterns, structures, etc. all serve as a means of productivity. Even learning serves as a means of productivity. But if I'm forced to deal with something that doesn't concern me for the sake of learning, it becomes counter-productive.

At the end of the day, despite the joys of scripting and programming, it's about productivity. Sure, it's great to learn, but it's not possible to learn everything, so you have to pick and choose what information is pertinent to your goals. Even if I became omniscient and there was nothing left to learn, I still would strive to structure my projects in a way that allowed me to deal with code on a need-to-basis. Alas, for now, I think abstraction and documentation is the best option.

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/72#issuecomment-191723351.

[jamesdwilson]

that's great and all, but when there is an update it will still be a pain to upgrade if it is not separated.

On Thu, Mar 3, 2016 at 7:52 AM, Patrick Scott notifications@github.com wrote:

This reminds me of a quote - "how do you eat an elephant? One bite at a time."

Just start with the example project and hack away. One step at a time. You'll get there. Watch videos and read articles to fill in the knowledge gaps. It's definitely a steep learning curve, but you'll appreciate the flexibility when you for example decide you want to no longer use CSS, and replace all of it with inline CSS with radium, or use mongodb instead of, or as well as rethinkdb.

On Thursday, March 3, 2016, Jakob Rosenberg notifications@github.com wrote:

I certainly understand what you are saying but you have to understand that such approach while easier to initially grasp also has a learning drop-off, being that when user is not aware of the code the user will not be inclined to learn anything beyond it.

Couldn't the same reasoning be used about every single node module? Every module author could insist on exposing their code for the benefit of learning. Obviously that wouldn't work and good documentation would be a much more efficient way to educate.

Frameworks, modules, languages, patterns, structures, etc. all serve as a means of productivity. Even learning serves as a means of productivity. But if I'm forced to deal with something that doesn't concern me for the sake of learning, it becomes counter-productive.

At the end of the day, despite the joys of scripting and programming, it's about productivity. Sure, it's great to learn, but it's not possible to learn everything, so you have to pick and choose what information is pertinent to your goals. Even if I became omniscient and there was nothing left to learn, I still would strive to structure my projects in a way that allowed me to deal with code on a need-to-basis. Alas, for now, I think abstraction and documentation is the best option.

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/72#issuecomment-191723351.

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/72#issuecomment-191767709.

Thank you,

James D. Wilson http://jameswilson.name http://lnked.in/technologist https://github.com/jamesdwilson https://twitter.com/thejamesdwilson https://twitter.com/thejamesdwilson

[mattkrick]

Closing as I think we explored all possibilities & realized that there's no way to make this more modular without sacrificing flexibility and ease-of-use when it comes to building anything more than a basic example. If I'm wrong, and I hope I am, please create an npm package & submit a PR to replace boilerplate with an import to the package.

As I see it, this is really 2 issues: hiding complex code to decrease the learning curve, and making upgrades suck less. The former is an anti-pattern because if you're putting an app in production, you should understand how it works. If you don't, you're a bad developer & it's meatier's job to force you to learn.

As for the latter, updates are always going to suck. Even the most stable packages have accidental breaking changes at the bugfix semver level. Anyone who blindly updates all their packages at once in a production environment is going to have a bad time. Meatier itself isn't a package, it's the glue that holds packages together. It's stable, it's secure, and it's a jumping off point for your new app. If you're 2 months into building your new product & the next version of meatier comes out, there's absolutely no need for you to get the latest. It already saved you 1 month of setup time and taught you a couple best practices along the way. It did its job.

So, when it comes to updates I see 3 options, in order of preference:

• don't update the package
• update the package & update your code via codemod or reading the package changelog and carefully amending your code
• merge your project with a new version of meatier, if you never touched the file it'll auto-merge, if you did touch the file, manually fix the merge

Feel free to keep the conversation going & I'll look for those PRs :wink: