undefined | Better HN

0 pointscharlysisto11y ago0 comments

I appreciate this effort and will give it a try.

One of my main problem with javascript frameworks is having to drift away from the original server HTML. Not everybody wants to go the whole way down the Single Page Abbit hole. It's not only a question of speed or SEO.

I think many devs are both backend & front-end craftsmen, and as so build the backend first and then wish to 'grow' their frontend part on that foundation. Or ideally wish they could. Instead they have to fork the project into 1). the Good Ol' server HTML part 2). the API SPA part.

No matter how close angular or react (with jsx) stays to HTML, you still need to rewrite the whole view to comply with it's templating needs. There's no incremental evolution there, and worse : having to duplicate and sync maintenance on both ends, breaks the DRY principle which is fundamentally bad - since you end up with 2 sources of truth.

Pre-rendering the view with react on node (even if your on rails or whatever) may be a solution I don't know yet. Another take I guess would be to render your server html files with a template which complies with their JS counterpart. Yet another take would be to use HTML as the API instead of JSON - which is proven to work quiet well.

Anyways, just to conclude I think devs would feel more confident if they could rely a little more on the servers end while the frontend finds its ways and stabilizes a little.

0 comments

3 comments · 2 top-level

pmontra11y ago· 1 in thread

Exactly. Rewriting views is something I really don't want to do. Example: I'm building pages server side and using AJAX PATCHs to update data on the server. The server responds in JSON with a html attribute contaning the very same HTML Rails partial used to create the page. This spares me from having to build a SPA (which for many reasons is not OK in this project) or two different views, one Ruby and one *.js which would be unbearable (as you wrote).

I looked at intercooler supeficially with the hope it could be a foundation to standardize my AJAX calls (I did something myself but it still fluid). I'm not sure I like the way it puts so much information in the attributes of the DOM elements actions are bound to, but I'll keep reading. I prefer doing those stuff all in JavaScript and minimize the impact of frameworks on the DOM. It's still no time to commit to any of them. Let's wait until the dust settles.

carsongross11y ago

Someone just posted to the intercooler list about implementing a feature where the intercooler attributes could be specified separately in javascript:

https://groups.google.com/forum/#!topic/intercooler-js/FyPBo...

You might want to jump in on the thread and we'll see if we can coordinate a syntax you find amenable to your style of programming.

swah11y ago

I've been looking at other server-side options for pre-rendering React code.

Java/Clojure with Nashorn works easily (you need JDK8 though).

I couldn't get anything working w/ Go other than Otto, a JS interpreter written in Go, which is too slow.

j / k navigate · click thread line to collapse