How does a LAMP/RAILS app share server side rendering code with the client?
How does a LAMP/RAILS app share data models between the server and client?
How does a LAMP/RAILS app provide search engines with indexable dynamic pages?
How does a LAMP/RAILS app preserve client state between page reloads?
How does a LAMP/RAILS app synchronize client state between multiple connected clients?
Your lack of experience working in a professional front-end environment is telling, and is the source of your confusion.
Server side logic MAY be simpler in SOME cases. Overall applications have become a lot more complex over the last 20 years and your oddated methodologies have been replaced by tested thorough solutions built and used by some of the biggest companies in the world.
HN is not a complex app.
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.
Why do you want to write all that extra code instead of just picking the right tool for the job?
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?
> 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.
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.
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.
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.
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 "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.
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.