3 ms·

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 th

by tomc1985 11y ago

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 11y ago
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?
tomc1985 11y ago
(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?
- Vendan 11y ago
  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.
  - tomc1985 11y ago
    thanks! That trick worked!
- codeisawesome 11y ago
  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.
  - tomc1985 11y ago
    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.
    - codeisawesome 11y ago
      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).
      - tomc1985 11y ago
        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
    - morgante 11y ago
morgante 11y ago
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.
- ssmoot 11y ago
  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.
  - falcolas 11y ago
    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.
  - oblio 11y ago
    Gmail also offered 1GB+ at a time when generous competitors offered 100MB.

gjolund 11y ago

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?

tomc1985 11y ago

(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?

Vendan 11y ago
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.
- tomc1985 11y ago
  thanks! That trick worked!
codeisawesome 11y ago
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.
- tomc1985 11y ago
  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.
  - codeisawesome 11y ago
    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).
    - tomc1985 11y ago
      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
  - morgante 11y ago

morgante 11y ago

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.

ssmoot 11y ago
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.
- falcolas 11y ago
  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.
- oblio 11y ago
  Gmail also offered 1GB+ at a time when generous competitors offered 100MB.