3 ms·
As a developer, doesn't it make you _itch_ when you repeat yourself? Do you feel that itch when you repeat the same application logic on the server as you do on
by JohnDotAwesome 11y ago
As a developer, doesn't it make you _itch_ when you repeat yourself? Do you feel that itch when you repeat the same application logic on the server as you do on the client? Getting the client-side validation in-sync with the server validation? This is where JavaScript is fan-fucking-tastic.
All of my recent projects have been isomorphic react apps. I build my app like it were a fully client-side single page web app, but I get server rendering when there's a new http request. Once the page has rendered, the web app takes over and uses history pushState. There are very few pieces of code that aren't used in both places. Once you get the hang of it, you very naturally create mockable interfaces that can be swapped depending on environment.
In my opinion, this is pretty much the only category that makes JavaScript "Best-in-class"; It's the easiest language to build isomorphic web apps.
- it_learnses 11y agoWhat are your thoughts on Meteor?
- morenoh149 11y agogood for prototypes. Just build your software.
- brndn 11y agoWhat does your software stack look like for that?
- JohnDotAwesome 11y agoCurrently- * Babel - ESNext - JSX * Gulp * Browserify - Incremental * Express * React router * Rolled my own flux - This was interesting because I didn't truly understand flux when I started - I _get it_ now The routes on the server are the same routes on the client. When the server renders, React/ReactRouter take over on the client and use history pushState. And that's actually about it. There aren't any other major libs that change the nature of the project. One thing I'm looking to do next is get hot reloading working and to somehow cut down on the initial compile times.