Hacker News Reader

Comment by pault | Hacker News Reader

This is interesting, especially since I just spent the last two weeks setting up a boilerplate for a universal react/redux SPA on spec for a new client. I enjoy the flexibility but the need to develop a deep working knowledge of several independent libraries, transpilers, and build tool configuration files (each of which has several competing options with their own way of doing things) just to get to hello world is cost-prohibitive for most people, I'm sure. At the same time, I'm hesitant to go "all in" on a stack that I haven't heavily researched myself. If the developers are reading, can you go into some details about how you handle routing and data stores? Are you using off the shelf libraries or have you rolled your own?

View on HN

I'd like to second this by suggesting the docs include a recommendation on how to incorporate this within an existing React app. Apologies if this is available within the Yeoman generator but if so it wasn't obvious from the docs.

FWIW, I've found the isomorphic render examples within the Megaboilerplate examples for React [0] to be instructive.

[0] https://news.ycombinator.com/item?id=11861926

I've always used React Router for routing. It's super flexible and plays very nicely with Redux and server-side rendering. In terms of syncing up state to views, you might want to look into 'redial' and 'react-redux', which are just higher-order components that ensure your React components can injected with the necessary state.

If you're gonna use React Router and Redux, you should also check out react-router-redux:

https://github.com/reactjs/react-router-redux

This is exactly what I'm talking about though, how many different libraries are there for routing alone? How can anyone make a reasonably informed choice between them? It's madness!

I want a website that rates packages in npm with more possibly useful heuristics:

  num dependencies (shallow, deep)
  total size of node_modules
  installed size (correct use of npmignore etc)
  code quality (McCabe, jslint, jshint)
  typescript/flow/ jsdoc string types etc
  test coverage
  frequency of releases
  documentation coverage
  documentation text analysis: pretentiousness, overly laconic, bro speak
  has a F-ing README so we could at least have some idea what the hell it is
  number of blog and link references
  number of authors
  reputation of authors based on their other packages
  open/closed issues

Make the stats available so others can build indices and ranking algorithms based on these.

Time since last commit, as well as average size and type of the last few commits would also be useful ensure meaningful features or bug fixes are probably being made.

See if others are using it, read the documentation, read the issues list, and/or read the source code. React-router-redux only has 216 lines of code! (Not counting tests, etc.)

Yes, this is basically my heuristic too. The part that's maddening is the low signal to noise ratio. It might take you six hours of googling to realize the library you need is called cthulhu-suspenders or something. You might have been able to write your own module in that time, then upload it to NPM, thus perpetuating the vicious cycle. :)

My heuristic is:

1. Google for a blog comparing them, and eliminate any candidates with major red flags

2. Go with the one that has the most stars on it's github repo.

So if there are no blog posts (1) then we all do 2 and then we suffer from first mover lock in.

>then we all do 2 and then we suffer from first mover lock in.

I don't find JS has a "first mover lock-in" problem. If anything, it has the opposite...

IDK, I'm hoping that there are enough people who don't check stars and choose a repo simply because it was the first one they found or because they think it works better with their existing code or for other reasons. And honestly there are many times where I've been that person.

Make a decision and run with it. Be confident enough in yourself or your team that you can pivot off that decision if it ends up being the wrong one. Often before you have enough information to make the decision at a level of precision that makes you completely comfortable.

I'm coming up on a decade in web application development and I feel like this is one of the most critical skills. It also took me an embarrassingly long time to develop. I think engineering, in allowing transparency downward into each level of the "stack", engenders the opposite in it's practitioners.

I wanted to transitioned from browserify to webpack and test that sweet redux hot reloading. I mostly got webpack working but I never understood with certainty which hot module reloader was the current one. It seemed everything on GitHub was deprecated and any boilerplate was outdated (one month old ? Forget it).

That ecosystem can be impressive but it's madness to keep up with it.

Picking out libraries, to some developers I work with, has become the same as shopping for a TV as Best Buy. They try to get the one with the bestest of everything, and just end up with a POS that no one wants to watch TV on.

What can ya do? This is where we find ourselves today. It's a mess. But what if I told you there was another way...?

Well, obviously, the correct choice is to use React Server and let us make all the decisions for you ;)

Obligatory XKCD: https://xkcd.com/927/

;)

I eventually settled on universal-redux-router, but I'll check out redial. I have found the redux ecosystem to be generally high quality.

For routing of URL paths to "page" objects we use Yahoo's `routr`.

We've tried to keep data store selection out of React Server core. There are so many good options in the React ecosystem that picking one seems limiting.

The data bindings that the framework cares about are at the http request level. We have a wrapper around `superagent` that manages transfer of response data from the server to the browser. So, when the client controller wakes up in the browser and tries to make the same requests that the server just made while _it_ was rendering the page, the data is already present and the requests are short-circuited.

So I can keep using my preferred redux middleware? That is definitely worth checking out.

If you want a frontend framework than does the glueing for you and comes with a clean cli to setup new projects and generate views/controllers etc, take a good look at Ember.

You'll get a Hello World up in 30 seconds, upgrades are painless and you'll get the same rendering speed as with React thanks to the glimmer engine.

And thanks to the standardisation, all Ember apps have the same code and logical structure, which makes it easier to share code, and for developers to dive in new projects.

> I just spent the last two weeks setting up a boilerplate

Two weeks for setting up boilerplate? Is that normal for react?

No, two weeks to take a deep dive into all the associated dependencies for doing a universal SPA. Learning the details of webpack (which requires more googling than reading the documentation), auditioning several flux implementations (and there's relay if you want to go down the graphql rabbit hole), routing libraries, and server page rendering configurations. There's no single way to do this and everybody has their own boilerplate set up on github. You can just get started with one of those, but if you don't understand what's going on under the hood, you'll be up the creek when something breaks and you're on the clock. I'm extremely uncomfortable working with something professionally until I have a good understanding of the source at least at the highest level of abstraction. Unfortunately this seems to be the only way to survive in the NPM ecosystem, pulling down and spending an hour reading the source of every variation of large dependency you might need. Hence the two weeks. Not that it's such a bad way to do things, reading the source. It's just a lot slower than people generally expect web development to take these days.

I don't think so. I'm a somewhat-novice react dev, and for me, even in my first projects, setting stuff up was about a day. It's true though that during the next few weeks you'll have to tweak things while yo start to work on "real code".

I imagine your parent didn't literally spend two whole weeks just on that, but I might be wrong if he's very thorough.

In any case, the configuration of all the parts of the "canonical react stack" (let's not forget, react could be used without all of this junk too) is a pain, but I hope once you get the hang of it you can just reuse and don't think about it so much.

I feel like it's normal for web development

I'd say it's quite high. However, I'd echo that if one is coming at building a boilerplate while simultaneously wanting to learn and understand all of the concepts in the stack, I could see the boilerplate taking more than an hour or two.

(For example, I've seen some that implement some custom Redux middleware simply so that there's a conceptual reference right in the boilerplate as to how one would be done).

Are you thinking of getting into it? I heavily advise checking React out. I think it's fantastic!

what is "on spec"?

"Working on spec" is a term used in freelancing to refer to unpaid work done as preparation for paid work. Usually this involves doing some type of proof of concept for a client in order to have your bid accepted, and is generally frowned upon by freelancers. In this case, I just wanted to get to know the tech stack in depth for my own gratification, and figured it could be used in other projects as well.

Reply on news.ycombinator.com