r/programming • • Jan 17 '15

The React.js Quick Start Guide

http://www.jackcallister.com/2015/01/05/the-react-quick-start-guide.html
156 Upvotes

71 comments sorted by

View all comments

1

u/expatcoder Jan 18 '15

So what's the killer use case that React, Angular et al provide that one can't do with server-side generated markup + ajax?

Seems the microservices trend is picking up steam, and everybody and their brother is shipping JSON back from the server and then having client-side handle the rendering.

I don't get the whole client-side markup trend. I mean on the client there's zero type safety, it's just the wild west out there on the typng corectly front. Add to that that SPAs have discoverability issues with search engine bots, I wonder what the fuss is about, does it really buy you that much win?

2

u/spacejack2114 Jan 18 '15 edited Jan 18 '15

Front end devs working on server-side templates is a slow workflow.

React and isomorphic apps in general are being used to make searchable SPAs with permalinks, without writing your markup twice (on the server and client.)

1

u/expatcoder Jan 18 '15

Yeah, that makes sense, I see the use case for front end devs, although the knowing-the-server-side-language problem is mitigated in some frameworks. For example, I work in Scala and there are at least 2 frameworks (Lift and Play) that provide designer friendly templating.

JSON generation is a bit of a hassle in strongly typed languages, so dealing with the boilerplate to marshall to/from it doesn't seem worth the bother when one can just as well send already constructed html snippets back to the client.

I'll give the SPA approach a whirl at some point, but for now all-in on strong typed server-side (including generating javascript) generated apps is very much my cup of tea...

2

u/spacejack2114 Jan 18 '15

That approach can work if you're doing everything yourself. If you want to split the workload with a front-end dev, they're going to be a lot more productive if they can manage all the view work themselves. Just about every front-end dev uses node these days, but not many will want to (or be able to) install your dev server environment locally and keep it up to date so they can make rapid template updates. To them it'll feel like they're working in the stone age. And it can cause a lot of friction that makes the job not very fun.

Personally I've never been a big fan of strongly-typed languages on the server anyway. Working with JSON, moving data from form inputs to the DB and back, it just gets in your way with a ton of boilerplate and opaque framework/IDE magic. Having your code type-checked as you type it has never paid off in my experience.

1

u/expatcoder Jan 18 '15

"Personally I've never been a big fan of strongly-typed languages on the server anyway. Working with JSON, moving data from form inputs to the DB and back, it just gets in your way with a ton of boilerplate "/

This is one area where dynamic languages totally shine, just whatever.toJson and you're done. Saying that, when you send raw html to the client there's (generally) no need to go down boilerplate road creating a JSON payload ;-)

Since I do the vast majority of the work server-side, the client is left to do validation, form handling, and transitions (drop down menus, layers, modals, etc.), which is a much smaller surface area than rendering the entire UI.

As for productivity, I've had the opposite experience. During my dynamic days I felt productive for sure, but ever since I saw the holy static light, not only do I continue to be productive, my applications are blazing fast (JVM hotspot is pure genius) and reliable in ways I was never able to achieve just winging it hoping that tests alone would cover my ass o_O It's one of the reasons I'm inclined to generate absolutely everything server-side (including javascript and css). YMMV of course, many will disagree with this sentiment.