The boilerplate you have to write (and handle) is minimal. This is more important to me than the number of packages I have to install for development.
And, only React, ReactDom and Firebase (which has to be required in the page html, unfortunately, due to Firebase issues) actually ship down to th client
While I can appreciate the benefit of keeping your entire codebase small (especially the bits that aren't yours), I'm not entirely certain of the wisdom of trying to build a react/es6/less/sass transpiling development environment with as few external dependencies as possible :)
JavaScript dependencies are to Unix philosophy as C++ is to object-oriented programming... In name only, and seemingly in complete misunderstanding of the concept.
IMO JS hits all of the points of the unix philosophy:
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
Following that, babel reducing its "main" code down to a "useless on it's own" core, and allowing all functionality via plugins fits perfectly in that ideal. Then there are "presets" which can be built on top of them to include many of those plugins as one dependency, and a package to polyfill things that can't be "compiled" at compile time (babel-polyfill).
If i don't care about optimization, i can just throw everything in there and it'll work. If i want to cut down on the size, i can look at my target browsers and drop things (like babel-polyfill, or in some cases even most of the plugins from the babel-preset-es2015), and can install and run only what is needed.
it also makes writing new features into something like babel simple as hell, you can do it in a 10 line plugin. That makes it extremely simple to avoid bloating other plugins with options/features and instead encourages new plugins that do what the option/feature wanted.
Well, in fact all of them should be devDependencies because the artifact of a build would contain everything, none of those things would be needed at runtime.
Most of those should be "devDependencies", as they're used for build-tooling not for the actual codebase, but I'll be honest I'm right there with you: my major drama with modern front-end dev at the moment is the sheer amount of dependencies that are "required" in a traditional toolset.
That said, leveraging Browserify, Bubleify[0] and Ramda[1] alone can get you pretty far in a seriously maintainable way with modern code, which is super nice: keeps compile times stupid quick and reduces some of the cognitive overhead (and possible maintenance drama) that too many third-party deps introduce.
There's a balance to be struck here, and it's a hard problem, I think.
I dunno, I think what you are describing is a practical stack, not a minimal one.
For me, a minimal stack is just an HTML file(possible with a JS file as well) that loads React and Firebase via CDN, and then relies on browser's shipped ES6 capabilities to write code.
But in that sense I might be trolling here since nobody actually does that :)
Apologies for the question but what benefits do I get if I build on firebase?
From the people I talked to it seems that the main audience for firebase is mobile engineers that either don't have the skillset or the time to learn how to build a backend system. Most people I talked to also told me they wouldn't use firebase if they could build a backend.
With firebase you can just write a front-end single page app and never think about servers or anything like that. It takes seconds to start using and very little knowledge about how it works.
Firebase is also useful for "rich prototyping". I work with a skilled front-end developer who can also work with Firebase. The result is that a functional app can be created quickly. Then it's up to the client to decide if they wish to replace Firebase or live with its limitations.
Firebase gives you a real-time database with no initial setup. The only really big competitor I know of it is RethinkDB. Having "three-way" databinding in a SPA is pretty cool and wouldn't be something that would be trivial to setup without either of these two databases.
I could see Firebase being a great go to for a certain size of project in the small to medium size that would rather pay for this feature set that using AWS, Azure, Rackspace, etc.
In addition to the other comments, by only needing to write frontend code you can also host your website much cheaper and scalably (via something like amazon S3 & CDN). You'd pay more like several pennies for 100's of users (ignoring any scaling costs w/ Firebase) rather than a min of ~$10/mo.
Another benefit that others haven't mentioned, is that if active server behaviours are needed, you can attach a 'server' like a client.
In some circumstances, interacting with users via the database as a messaging system can protect them from issues with your server code, and server outages: if your server goes down, users will still be able to log in and interact with the database via client side code - they'll only lose access to server related functions.
Except that the default is read/write for all users[0]. This starter kit doesn't mention security at all, even just to warn the user about full read/write.
Thanks. Let me make an issue to update the docs on that.
I've been using Firebase a while, and so I didn't fully think through the experience for users unfamiliar with firebase.
By necessity, this repo use of firebase is somewhat opinionated. I intend to add comments and docs to explain the architecture and how to set it up to work with different kinds of persistent data (ie - shared and public data as well as user related docs). And, of course, to set up secure separate docs for different users.
Nicely done! I did a similar thing with the VueJS/horizon.io combo. It's a little rough around the edges - I just wanted to have some sort of scaffold for personal stuff. Link is https://github.com/kylestlb/vuex-horizon-scaffold for anyone interested. And yes, there are tons of devDependencies so I wouldn't call mine minimal I suppose :)
Awesome! I've been using horizon.io in combination with React (and Redux, because I'm all hip and stuff!) for 'scratch-my-own-itch' projects and on the whole I've been very happy with the process.
While there are some obvious limitations to using Horizon, it's incredibly convenient for quickly getting something working that 1) is online, public-facing, but secure (OAuth), and 2) provides a CRUD back-end very quickly with little work.
I've run into a bug or two so far, and the documentation isn't entirely up to snuff, but I can highly recommend Horizon for some use cases.
Specifically, Horizon is great out-of-the-box if you're creating an app where there's authenticated users who can do pretty much anything to entities owned by themselves, and where a client-side interface suffices. A todo app, or journalling app would be a typical example: the user can do whatever he pleases with his own todos/journal-entries, provided that he's authenticated.
Any greater complexity server-side probably needs an Express app (or Hapi, Koa, etc.), but there's really quite a lot you can do with a 'vanilla' Horizon server.
Agreed, and I think a good solution is to build specific services that do the complex things which talk to the same db, and then just use horizon for the reasons you mentioned.
I am starting on a big SPA project.
react+horizon+rethinkdb seem ideal for the read-only parts, but i worried about how to integrate some business logic which will require relational transactions on the backend
I think in that case you can just build a separate express API that talks to the same rethinkdb instance, no? After all, horizon is basically just a front-end driver that wraps rethinkdb changefeeds.
Yup. It should be pretty easy to set up an Express server that uses Horizon for some of the simpler stuff, and your own routes/logic for more complicated work.
It's intended for static hosting, where there is no server-side rendering (much of the point of firebase). At the moment it just does concatenation and minification, but the files are rendered on the client.
This isn't ideal, obviously - it's still unclear to me whether Google successfully crawls ajax sites. I would like to add build-time rendering, but it's of debatable value for static sites, since obviously, it can't be dynamically generated.
The hack for now would be to hard code 'content' into the React render target `<div>`, so that it lands immediately.
39 comments
[ 4.7 ms ] story [ 81.4 ms ] threadSorry, but with those many dependencies, I could hardly call that minimal.
And, only React, ReactDom and Firebase (which has to be required in the page html, unfortunately, due to Firebase issues) actually ship down to th client
While I can appreciate the benefit of keeping your entire codebase small (especially the bits that aren't yours), I'm not entirely certain of the wisdom of trying to build a react/es6/less/sass transpiling development environment with as few external dependencies as possible :)
babel-core, babel-loader, babel-polyfill, babel-preset-es2015 and babel-preset-react can be considered one dependency (it's babel...).
react and react-dom are another.
webpack, the dev server, and 3 webpack plugins can be considered a 3rd.
That's 3 "real" dependencies. If that's a lot, then i'd love to see a "real" minimal setup.
Just because javascript dependencies tend to take the unix philosophy to the extreme doesn't mean that each of those should be treated equally.
IMO JS hits all of the points of the unix philosophy:
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
Following that, babel reducing its "main" code down to a "useless on it's own" core, and allowing all functionality via plugins fits perfectly in that ideal. Then there are "presets" which can be built on top of them to include many of those plugins as one dependency, and a package to polyfill things that can't be "compiled" at compile time (babel-polyfill).
If i don't care about optimization, i can just throw everything in there and it'll work. If i want to cut down on the size, i can look at my target browsers and drop things (like babel-polyfill, or in some cases even most of the plugins from the babel-preset-es2015), and can install and run only what is needed.
it also makes writing new features into something like babel simple as hell, you can do it in a 10 line plugin. That makes it extremely simple to avoid bloating other plugins with options/features and instead encourages new plugins that do what the option/feature wanted.
That said, leveraging Browserify, Bubleify[0] and Ramda[1] alone can get you pretty far in a seriously maintainable way with modern code, which is super nice: keeps compile times stupid quick and reduces some of the cognitive overhead (and possible maintenance drama) that too many third-party deps introduce.
There's a balance to be struck here, and it's a hard problem, I think.
[0] https://github.com/garthenweb/bubleify
[1] http://ramdajs.com/0.21.0/index.html
For me, a minimal stack is just an HTML file(possible with a JS file as well) that loads React and Firebase via CDN, and then relies on browser's shipped ES6 capabilities to write code.
But in that sense I might be trolling here since nobody actually does that :)
From the people I talked to it seems that the main audience for firebase is mobile engineers that either don't have the skillset or the time to learn how to build a backend system. Most people I talked to also told me they wouldn't use firebase if they could build a backend.
I could see Firebase being a great go to for a certain size of project in the small to medium size that would rather pay for this feature set that using AWS, Azure, Rackspace, etc.
I've added an issue to document the process for uploading to firebase after building a production version.
In some circumstances, interacting with users via the database as a messaging system can protect them from issues with your server code, and server outages: if your server goes down, users will still be able to log in and interact with the database via client side code - they'll only lose access to server related functions.
[0] - https://www.firebase.com/docs/security/quickstart.html
"By default, your app has rules which grants every request full read and write permissions to your database"
I've been using Firebase a while, and so I didn't fully think through the experience for users unfamiliar with firebase.
By necessity, this repo use of firebase is somewhat opinionated. I intend to add comments and docs to explain the architecture and how to set it up to work with different kinds of persistent data (ie - shared and public data as well as user related docs). And, of course, to set up secure separate docs for different users.
While there are some obvious limitations to using Horizon, it's incredibly convenient for quickly getting something working that 1) is online, public-facing, but secure (OAuth), and 2) provides a CRUD back-end very quickly with little work.
I've run into a bug or two so far, and the documentation isn't entirely up to snuff, but I can highly recommend Horizon for some use cases.
Specifically, Horizon is great out-of-the-box if you're creating an app where there's authenticated users who can do pretty much anything to entities owned by themselves, and where a client-side interface suffices. A todo app, or journalling app would be a typical example: the user can do whatever he pleases with his own todos/journal-entries, provided that he's authenticated.
Any greater complexity server-side probably needs an Express app (or Hapi, Koa, etc.), but there's really quite a lot you can do with a 'vanilla' Horizon server.
I am starting on a big SPA project. react+horizon+rethinkdb seem ideal for the read-only parts, but i worried about how to integrate some business logic which will require relational transactions on the backend
Got to check out your stuff - I've heard about vue.js but am not very familiar.
I have four of these little repos now, all forked from each other, all with that spelling mistake, no doubt.
It's intended for static hosting, where there is no server-side rendering (much of the point of firebase). At the moment it just does concatenation and minification, but the files are rendered on the client.
This isn't ideal, obviously - it's still unclear to me whether Google successfully crawls ajax sites. I would like to add build-time rendering, but it's of debatable value for static sites, since obviously, it can't be dynamically generated.
The hack for now would be to hard code 'content' into the React render target `<div>`, so that it lands immediately.