Comment by tomc1985 | Hacker News Reader

Comment by tomc1985 | Hacker News Reader

Parent Full thread

How does a LAMP/RAILS app share server side rendering code with the client?

It doesn't, because I don't need/want it to. Any data that needs to be passed to the client is rendered as JSON. Client-side get committed to the database via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST.

How does a LAMP/RAILS app share data models between the server and client?

Again, not needed.

How does a LAMP/RAILS app provide search engines with indexable dynamic pages?

Uh, through clever use of jquery AJAX and postgres indices?

How does a LAMP/RAILS app preserve client state between page reloads?

A serverside redis cache? In the database? In the cookie? LocalStorage? C'mon man.

How does a LAMP/RAILS app synchronize client state between multiple connected clients?

By pushing a hash with current state to all clients via polling? Websockets? Whatsitcalled where you don't close the original HTTP connection? Did you know postgres has some pretty awesome realtime pubsub tech? I suppose if I have some extra time I could send changesets and load them with $.merge()

...

I just want you to know that you are doing nothing to improve my image of the JS-scene-writ-large as immature, spoiled, and childish. There are isolated pockets of brilliance, for sure, but the everyday talk scares me.

(gjolund: I can't reply to you directly, but consider this my reply)

Because they're simple? They're relatively standard? They're compact? Because I don't have to learn a new god-damned framework for every single new assignment? When did software development become a paint-by-numbers exercise? There is a difference between spaghetti-code and engineering.

Why do you want to write all that extra code instead of just picking the right tool for the job?

Because I can do it in less lines, in less time, with no new dependencies, and -- again! -- I don't need to learn another new framework!

PS- Please understand, I know the difference between good code and bad. That's why I've automated most of my job title and am able to spend 97% of my working day helping the rest of my team solve their problems! Oh and did I mention I handle the infrastructure, enterprise integration, telemetry, and sales reporting for my company?

just fyi, if you don't get the "reply" link, you should be able to click the "X minutes ago" and post a reply that way.

thanks! That trick worked!

It's a lot easier to learn React than what all of you think. It's especially easier to learn these frameworks when you tried to solve the problem without them and experienced the pain of not having them.

As a user of React, I disagree -- unless you are using React in a javascript runtime, in which case you're probably fine. But I resent react for all the extra cognitive load it forces me to worry about when all I really give a shit about is its shadow DOM implementation. And then, only when I've got page(s) full of data I need to update without lag.

Are you talking about ReactNative? I haven't played with that yet, but it's one reason I chose React in one of my projects (eventual plans to use our web browser components at least partially in Native).

No, more specifically, using React with Rails through the react-rails gem. I am considering ripping out all my JSX and replacing it with our React JS

I'd like to correct some misconceptions you seem to have regarding React.

> unless you are using React in a javascript runtime, in which case you're probably fine

React is written in JavaScript. It runs exclusively in JavaScript. If you've somehow managed to run it outside a JavaScript runtime then I'd actually be delighted to learn about how.

> all I really give a shit about is its shadow DOM implementation

React doesn't have a shadow DOM.

Well, react-rails is how. And it's messy as hell.

React-rails doesn't run JavaScript outside of a JavaScript runtime, FYI. It just provides hooks for communicating between Rails and JavaScript.

We didn't collectively decide to move rendering to the client side for no reason. It is unquestionably more complex to build a SPA than to have a traditional web app.

We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.

If Gmail used your approach, it never would have succeeded.

> How does a LAMP/RAILS app provide search engines with indexable dynamic pages? Uh, through clever use of jquery AJAX and postgres indices?

I have to assume you're just throwing out terms you've heard of but never understood. Database indexes have literally nothing to do with making your site indexable for search engines.

Most SPAs feel substantially slower IME.

The users didn't demand this. They were perfectly happy when you delivered a website that performed a full-round trip in 50ms a decade ago containing more data than your average SPA can handle before choking on it.

The users want it to work. They want it to be fast. They want it to be pretty. That's about it.

I'm tired of hearing about why GMail succeeded. It's revisionist. GMail succeeded because they had the best spam filtering, in a simple design, and you were probably using Google search anyways. Plus Hotmail was always going down for hours (days?) at a time.

I've never experienced bugs in the web like I have with SPAs. I'm very thankful that even if my budgeting software is built in Ember, making it slow and buggy, my bank's site isn't. Making it predictable, and very fast to render. Time to Render is atrocious on many "modern" sites.

Gmail was also originally a traditional webapp - in the early versions Javascript added to the experience, but there were still page transitions when viewing emails and composing new emails.

Opinion time: I miss that version. There's so many bells and whistles on Gmail now that I prefer to use a local mail client to logging in and attempting to work through all the clutter to do basic things like viewing and replying to emails.

Gmail also offered 1GB+ at a time when generous competitors offered 100MB.

Great point. In the time before Dropbox, S3, etc Email was THE way to share your 50Mb zip file. And routinely having to clean your mailbox because you ran out of storage was a huge pain.

No, you can build your own full-text search engine with dynamic pages with postgres' fulltext index types. You can subscribe to changes through LISTEN/NOTIFY, or by outputting log entries in trigger functions, among other techniques. That fulfills the 'dynamic' part of the question.

I don't know how you read that question (well, ok, I do), but it's not how I read it. Whiff of an insult duly noted.

We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.

Dude! Whoever said we were railing on SPAs? But since you bring up Gmail I'd just like to note that gmail has been a slow, bloated mess for many years now. It takes a half a minute for the page to stop janking on my dev box with 50mbps internet, so I think Gmail in its current state is a poor choice of example. Gmail of old, back before they tried to cram 80 million things into it, was a pretty good example.

> I don't know how you read that question (well, ok, I do), but it's not how I read it. Whiff of an insult duly noted.

I don't know how you read "provide search engines with indexable dynamic pages" as implementing your own search engine. It was pretty clearly referencing the well-known challenge of making your JavaScript-rendered pages indexable by Google/Bing/etc.

> Whoever said we were railing on SPAs?

You are. When you say we should just abandon all this JavaScript and instead render everything through Rails, you're arguing against building SPAs.

That's the opposite of reality. Users hate it. Overwhelmingly. You did do it for a reason, but the reason was "look I think this is cool!". Users suffer for the fashion driven choices of the web development world.

> That's the opposite of reality. Users hate it. Overwhelmingly.

You have absolutely no evidence of that.

On the contrary, there is abundant evidence that SPAs increase engagement.

You're living in an echo chamber if you actually thing the average user would like to return to the web of the 90s. They love things like the infinite scroll on Facebook, Google instant search, Slack, Trello, etc.

If you think the huge companies implementing these things haven't done extensive user testing to show that people prefer these experiences, you're letting your political agenda cloud your judgement.

An echo chamber? Where? Show me this echo chamber. The echo chamber is the one repeating the same baseless nonsense you are. And where on earth do you get a "political agenda" from pointing out the fact that user testing shows javascript messes are bad?

I love infinite scroll. I don't count though, hm?

I love peach pie. What does this have to do with anything?

Answer: a bunch of singular solutions that may or may not be tested/documented

Why do you want to write all that extra code instead of just picking the right tool for the job?

Reply on news.ycombinator.com