[petewailes]

Christ on a bike...

I spend a reasonable amount of time developing and maintaining a reasonable sized js based front end to an application, which uses React heavily (40k lines). Looking at this, I can't help but think that isomorphic JS apps make life far more miserable than separate back and front end applications.

To get a decent server running on a linux distro - Nginx, Mariadb, PHP/Python/etc. An apt-get and your updates are handled nicely for you. Dependency management via Gulp is better than nothing, but jeez it still sucks so bad.

Building a nice, RESTful API on a more sensible back end infrastructure is far less complex, has a vastly smaller toolchain (just a small library for routing and db connection handling would do), plus you get the joys of things like Schemas and ACID from a proper RDBMS (because seriously, Mongo? We really still think that's a good idea?).

That's before we even get on to Step 4. ES6 Crash Course. Or, here's things to know about a language that you can't use on the client browser, because it's not actually a thing there, so you can't use all that you'll learn here when you write JS.

It's insane that people think you need to do all this just to get a live updating counter. What's wrong with a tidy back end with ZeroMQ for your pubsub style socket handling to allow real-time event based change publication, and a separate front end?

It feels like you have to do a hell of a lot of work to get JS + your favourite V8-based server to do anything, and none of it easily.

[verroq]

There is just a lot of friction. Want es6, get ready to put gulp in your work flow. Want to sanely include frontend dependencies? Time to add throw in bower. Want those js/css to be injected into the page? Throw in wiredep or bite the bullet and chuck in the wirepack.conf.js. Don't want that and want to use a skeleton? Install yeoman and run the isomorphic js generatior that gives you a 1k+ line project and you haven't even made your app yet.

[TheAceOfHearts]

I made a scaffold [0] that tries to give you a reasonable starting point, without tons of extra cruft. It was important to me that the scaffold handle all 3 basic environments: development, testing, and production.

It's basically a single webpack config (that's heavily commented, btw!) and a set of npm run-scripts. You don't need gulp to build an application! And I would not call bower a sane way to include frontend dependencies... Not by a long shot.

[0] https://github.com/cesarandreu/web-app

[quicksnap]

I was looking at this a while ago, and it's a really nice starting point! I too am aiming to remove Gulp from my workflow when possible.

[Gigablah]

It's like people want complexity in their app, then complain when they get it.

[lewisl9029]

jspm can actually remove a lot of the friction you mentioned:

1. seamless ES6 transpilation at runtime (no build steps needed)

2. load libraries in any package format as ES6 modules (Globals, CommonJS, AMD, ES6) from any source (local repo, Github, NPM)

3. no need for injection (you can import css and html programmatically using extensions)

It does introduce some friction of its own due to it being a relatively new project, but not enough to offset all the benefits it brings, in my experience.

[testguy34]

> It's insane that people think you need to do all this just to get a live updating counter.

Dismissing this guy's tutorial because he didn't clone Facebook is kind of short sided. Everything is about trade offs. You don't need to make your React app isomorphic if you don't mind a slower initial load and lack of SEO. You don't need to use Mongo, you can pass data from your RDBMS directly to your components as props when you render server side or have them call your REST API using an isomorphic request library. You don't need to use ES6 if you use something like webpack and babel.

[petewailes]

Don't get me wrong, it's a massively comprehensive piece of work. I'm jealous of the author's chops - they know more about this than I do. But after all this time writing applications small and large, doing isomorphic JS dev feels like a massive step back.

[k__]

I think it isn't needed for 99% of all web-apps.

But if you have heavy competition and need a snappier first load experience, it is an option you have.

[hello_there]

Can you elaborate on you stack and toolchain? I'm curious about what's simple and works well with React.

[guscost]

Not the OP but I've really liked working with the Django REST Framework. Top-notch work and I suspect it would scale pretty well to a point.

[petewailes]

Django is pretty nice. A little heavy for my liking (I prefer libraries to frameworks), but as frameworks go, it's a solid one.

[petewailes]

For sure. The stack is designed to make hiring and maintaining simple, rather than to be completely elegant, so with that in mind:

Server is Nginx. Evaluating HHVM for migration is an ongoing concern, but there's some edge cases we run in to where it does wonky things. That said, within the next ~12 months, I expect we'll be on it.

MariaDB, with query results cached on Memcache. The data we deal with is massively relational, with some very large tables and result outputs, so there's no way around using a tidy RDBMS for us, and consistency is a big thing.

PHP, with a few tiny, high speed libraries for DB connection management and routing. As far as possible everything uses PHP functions that map directly on to underlying language equiv, and we make a lot of use of streaming and generators, which makes memory overhead nicely manageable. When HHVM becomes a thing for us, we'll then start pulling some of this over to Hack.

That's all set up as a bunch of RESTful APIs, which are reasonably HATEOAS in their outputs. Output format is either JSON or HTML, depending on request params.

Front end is a bunch of React bits. We're slowly converting into React, so initially we used HistoryJS to manage URL history, along with React to render stuff. Qwest for XHR handling, and a few little libraries and helper functions (of note: moment.js and numeral.js).

Everything then gets executed on the client. Current roadmap is to build something akin to React router for managing loading of assets and better history management, and to pull the entire front end into a single application. At the moment, it's better thought of as a bunch of distinct SPAs, operating over a common middleware.

Architecturally, the back end services are written MVA, with data going through our own DAL, with RBAC sitting in front of everything. Caching is handled in the DAL, so everything acts as a black box - models don't know where the data came from, adapters don't know where the model got it's data etc...

The front end is written loosely around a Flux style architecture. Data is held in a single area, as are all methods that interface with state. Those parts sit at the top, and pass data as props down to UI components, written to be dumb as to where there data comes from.

IO is mostly via single HTTP requests, but with the option to hook onto ZMQ for real time interaction.

Hope that helps! I'm currently writing some lower level thoughts on React on our blog (https://builtvisible.com/blog/) with some more advanced stuff coming shortly.

Apologies for the various TLAs. If you need anything explaining further, shout.

[renke1]

It's a shame the blog of yours doesn't have a RSS or Atom feed.