6 ms·

Show HN: A minimal setup for React/ES6 sites with a Firebase back end

59 points by WalterSear 10y ago

xuejie 10y ago
https://github.com/Jon-Biz/simple-static-react-firebase/blob/master/package.json#L21-L32 https://github.com/Jon-Biz/simple-static-react-firebase/blob... Sorry, but with those many dependencies, I could hardly call that minimal.
- WalterSear 10y ago
  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 :)
  - Klathmon 10y ago
    Yeah, how is this a lot of dependencies? 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.
    - pavlov 10y ago
      JavaScript dependencies are to Unix philosophy as C++ is to object-oriented programming... In name only, and seemingly in complete misunderstanding of the concept.
      - Klathmon 10y ago
        Can you expand on what you mean? 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.
- chvid 10y ago
  Should some of those not be dev-dependencies?
  - pietro 10y ago
    Yes, the ones related to Babel and Webpack.
    - diggan 10y ago
      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.
  - WalterSear 10y ago
    Pretty much all of them, except for React. Sloppy setup by me :(
- girvo 10y ago
  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. [0] https://github.com/garthenweb/bubleify https://github.com/garthenweb/bubleify [1] http://ramdajs.com/0.21.0/index.html http://ramdajs.com/0.21.0/index.html
  - xuejie 10y ago
    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 :)
dvcrn 10y ago
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.
- hiou 10y ago
  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.
- intrasight 10y ago
  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.
- soundoflight 10y ago
  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.
- mazlix 10y ago
  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.
  - WalterSear 10y ago
ben_jones 10y ago
Has anyone here dealt with Firebase's authentication / authorization model in production?
- nc 10y ago
  Yup, it's pretty solid, no issues to report.
  - dsp1234 10y ago
    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. [0] - https://www.firebase.com/docs/security/quickstart.html 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"
    - ben_jones 10y ago
      Which is exactly what new developers (who are attracted to these kinds of services) ignore.
    - WalterSear 10y ago
      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.
kylestlb 10y ago
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 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 :)
- mercer 10y ago
  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.
  - kylestlb 10y ago
    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.
  - yazr 10y ago
    Is there any source/sample you can share ? 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
bshimmin 10y ago
/pubic/ output directory. Put your assets in here next to the compiled js and css. Splendid!
- WalterSear 10y ago
  :groan: I have four of these little repos now, all forked from each other, all with that spelling mistake, no doubt.
hiimnate 10y ago
How is it not a security issue to serve the API key in `public/auth.html`?
- WalterSear 10y ago
  It's a public key, if I'm not mistaken.
conqrr 10y ago
Does this come with Server side rendering out of the box?
- WalterSear 10y ago
  No. 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.
mandarlimaye 10y ago
Demo Pls
- WalterSear 10y ago
  I'm making an issue. I'll host one on firebase shortly.

59 points by WalterSear 10y ago

https://github.com/Jon-Biz/simple-static-react-firebase/blob/master/package.json#L21-L32 https://github.com/Jon-Biz/simple-static-react-firebase/blob... Sorry, but with those many dependencies, I could hardly call that minimal.

WalterSear 10y ago
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 :)
- Klathmon 10y ago
  Yeah, how is this a lot of dependencies? 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.
  - pavlov 10y ago
    JavaScript dependencies are to Unix philosophy as C++ is to object-oriented programming... In name only, and seemingly in complete misunderstanding of the concept.
    - Klathmon 10y ago
      Can you expand on what you mean? 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.
chvid 10y ago
Should some of those not be dev-dependencies?
- pietro 10y ago
  Yes, the ones related to Babel and Webpack.
  - diggan 10y ago
    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.
- WalterSear 10y ago
  Pretty much all of them, except for React. Sloppy setup by me :(
girvo 10y ago
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. [0] https://github.com/garthenweb/bubleify https://github.com/garthenweb/bubleify [1] http://ramdajs.com/0.21.0/index.html http://ramdajs.com/0.21.0/index.html
- xuejie 10y ago
  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 :)

dvcrn 10y ago

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.

hiou 10y ago
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.
intrasight 10y ago
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.
soundoflight 10y ago
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.
mazlix 10y ago
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.
- WalterSear 10y ago

ben_jones 10y ago

Has anyone here dealt with Firebase's authentication / authorization model in production?

nc 10y ago
Yup, it's pretty solid, no issues to report.
- dsp1234 10y ago
  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. [0] - https://www.firebase.com/docs/security/quickstart.html 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"
  - ben_jones 10y ago
    Which is exactly what new developers (who are attracted to these kinds of services) ignore.
  - WalterSear 10y ago
    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.

kylestlb 10y ago

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 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 :)

mercer 10y ago
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.
- kylestlb 10y ago
  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.
- yazr 10y ago
  Is there any source/sample you can share ? 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

bshimmin 10y ago

/pubic/ output directory. Put your assets in here next to the compiled js and css. Splendid!

WalterSear 10y ago
:groan: I have four of these little repos now, all forked from each other, all with that spelling mistake, no doubt.

hiimnate 10y ago

How is it not a security issue to serve the API key in `public/auth.html`?

WalterSear 10y ago
It's a public key, if I'm not mistaken.

conqrr 10y ago

Does this come with Server side rendering out of the box?

WalterSear 10y ago
No. 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.

mandarlimaye 10y ago

Demo Pls

WalterSear 10y ago
I'm making an issue. I'll host one on firebase shortly.