[question] Thanks for great book. I'm also looking a few other technologies

[SteveALee]

Thanks for an excellent book very well written. I chose it as it I wanted a quick start for a new project using newer technologies, especially alt and webpack

I'm picked a few slightly different technologies in the name of simplicity. I wonder if you had any thoughts or pointers for these?

• Rather than React I'm using riotjs
• Rather than mocha et al I'm using tape
• I'm almost certainly using Hapijs as a HTTPS endpoint
• I may split up and go microservice architecture at some point using docker and perhaps also use senecajs if it fits.

I also see you removed the isomorphic parts but I'll still read them despite your reservations. I'm keen to use server rendering for Progressive Enhancement, not so much isomorphic.

Thanks

[bebraw]

Great to hear you are finding the book useful. Commenting below:

Rather than React I'm using riotjs

Riot can be a valid choice. There are a lot of light alternatives like this including vue.js and Ractive.js.

The reason I like React is that it has a strong ecosystem around it. Currently the situation is a little fragmented. I hope in the future standards will allow us to collaborate across library boundaries. I'm especially hopeful about Web Components but we'll see.

Rather than mocha et al I'm using tape

Yeah, tape is a valid choice. TAP is a powerful format especially because you can find a lot of third party tooling for it. I considered using it in the book but I ended up using Mocha instead given it's so popular.

I'm almost certainly using Hapijs as a HTTPS endpoint

I don't know Hapi that well. If you want something RESTful, swagger-tools can be worth a look. Swagger allows you to describe your API using JSON Schema. The nice thing about this is that you get form generation, validation, and API documentation for free. RAML is a comparative approach.

Falcor and Relay are more forward looking options and may represent future. RESTful APIs are nice up to a point but they are not ideal for modern application development. These solutions solve a lot of the pain points for you. Given they are so new technologies, it's sort of bleeding edge, though.

I may split up and go microservice architecture at some point using docker and perhaps also use senecajs if it fits.

I don't have a strong opinion on microservices. Fowler has written about them so that may be worth a read. I understand there's a lot of hype around microservices. Now we also have solutions like Kubernetes for orchestrating those containers. It's a brave new world.

I also see you removed the isomorphic parts but I'll still read them despite your reservations. I'm keen to use server rendering for Progressive Enhancement, not so much isomorphic.

Yeah, I did that to manage the scope and keep the book focused. The problem is that if I bloat it too much, the pricing of the upcoming print version won't make any sense. :)

[SteveALee]

Thanks for answering and introducing some new options to explore (so many choices!)

There are a lot of light alternatives like this The reason I like React is that it has a strong ecosystem around it ended up using Mocha instead given it's so popular

This is the tension I'm exploring. For an open source project I want to minimise the barriers to contribution and aim to minimise the learning curves presented by more complex frameworks. Plus you gotta be willing to debug and fix any module you depend on. Lean an mean is good. However using common popular frameworks means more people with the skills are around both for maintaining the dependency and for help with the project. Vue tempted me as I like reactive, but I felt it might again raise the barriers

RESTful APIs are nice up to a point but they

For my requirements id don't need real time yet, but I have some features in mind that will benefit for something like websockets. However REST is what make the web so good right now (OK so I read Fielding's dissertation). But evolution happens. I'd forgotton about swagger, I think I came across it when researching Azure API services

It's a brave new world.

Fowler is always worth reading :) I see even Microsoft are embracing Docker with them in mind. Microservices address many problems but introduce more challenges (as you say there new orchestration tools, Apache Mesos is another). However I plan some vertical client/server modules/components anyway and microservices have some series energy behind them which will no doubt out live the hype.

Yeah, I did that to manage the scope and keep the book focused

Cutting stuff out is a great and underrated skill. :)

[SteveALee]

PS I'm not holding my breath over Web Components, after several years we're still way off (and there are some accessibility concerns without "is a". I love the idea having used XBL in Mozilla XUL (the only place to implemented that w3c standard) but also want to think about Progressive Enhancement for now.

[SteveALee]

PPS - re microservices, I can recommend this book. Sam Newman is also from ThoughtWorks.

[bebraw]

This is the tension I'm exploring. For an open source project I want to minimise the barriers to contribution and aim to minimise the learning curves presented by more complex frameworks. Plus you gotta be willing to debug and fix any module you depend on. Lean an mean is good. However using common popular frameworks means more people with the skills are around both for maintaining the dependency and for help with the project. Vue tempted me as I like reactive, but I felt it might again raise the barriers

Yeah. This is actually one of the main discussion points when you are trying to figure out whether to use frameworks or compose out of libraries. The benefit of frameworks (Angular, Ember, ...) is that they "lock" certain opinions. This means it might be easier to bring new people to the project. In a library based approach it's easier to end up with ad hoc architecture and the initial learning curve may be higher. React projects are like snowflakes. Framework based ones are closer to cookies that come out of the same mold. You just decorate them differently.

This is the reason why I hope Web Components, or some other standard, picks up speed. Currently we're wasting a lot of energy on re-inventing wheels around the ecosystem. It would be nice if we could at least agree on a basic component definition to consume across solutions.

Fowler is always worth reading :) I see even Microsoft are embracing Docker with them in mind. Microservices address many problems but introduce more challenges (as you say there new orchestration tools, Apache Mesos is another). However I plan some vertical client/server modules/components anyway and microservices have some series energy behind them which will no doubt out live the hype.

I think the main argument against microservices is that they can be painful to debug. Mistakes cascade across a network of systems. Good luck with that. Perhaps it's possible to mitigate this somehow. Maybe it's just a matter of using stronger development practices such as chaos engineering.

I can see that microservices are valuable especially if you want to be technology agnostic. Let people use the technology that fits the problem instead of trying to shoehorn all problems through certain technology.

PS I'm not holding my breath over Web Components, after several years we're still way off (and there are some accessibility concerns without "is a". I love the idea having used XBL in Mozilla XUL (the only place to implemented that w3c standard) but also want to think about Progressive Enhancement for now.

Yeah, I agree the progress has been too slow. There's no way standards can keep up with the development, though. There will always be some inevitable delay as there are politics involved. Web moves fast.

[bebraw]

Closing. Feel free to continue over email/gitter/... .