5 ms·
I think this is right on. They are completely different environments and I can't imagine very many instances where you'll be able to write a generic function yo
by taternuts 10y ago
I think this is right on. They are completely different environments and I can't imagine very many instances where you'll be able to write a generic function you really want on both front and back end. I certainly haven't run into any in real life
- akamaozu 10y agoI think a good example of a function you'd want in the front and back end is one that takes data and outputs a template.
- imagist 10y agosigh I'm afraid to hear your answer, but I'm going to ask anyway: what would compel you to output the same template on both the client and server sides?
- 15155 10y agoPossible, possibly dubious: search engine optimization.
- imagist 10y agoI'd argue that this points to a poor design. If something is static enough to be crawled by a search engine, then it doesn't make sense to be generating it dynamically every time on the client side. It's static, generate it statically, and then all you have to do is serve it up (caches are a variant of this approach, but not the only one).
- akamaozu 10y agoI'm currently working on an unofficial interface for Readability because they aren't working on it anymore and their Android app is really broken. The webpage needs to work offline (whole point of the project) but should be able to work without js if need be. I create templates server-side and serve them to the client, If js is available, it takes over and renders any further client-side interactions. Does this sound like poor design or a valid reason to be able to render on the server and client?
- imagist 10y agoIt sounds like a poor design. Webpages don't work offline. All the user has to do to break everything is hit "refresh". What your business users wanted was an app, and you gave them a webpage instead. I also don't understand why you would do rendering both server and client side. That's an overcomplicated architecture that doesn't buy you anything. If you chose one, you'd have a simpler architecture. And before you claim "optimization"--did you profile?
- akamaozu 10y agoYou're pretty opinionated for someone who doesn't seem to understand a lot of things ;) 1. Hitting refresh doesn't break everything. It resets your current state to the default. I default to the url combined with locally stored state, so you will lose text in an input field, but not much else. 2. I want a website not an app, thank you very much. I'm really just displaying text. I don't need to download an app for that when I have a perfectly good browser on every device I'd like to read from. 3. Maybe it's over complicated to you, but the same function that renders on the server is what I use to render on the client. Zero difference. It's not a choice I have to make so I can use either when I feel it's appropriate.
- imagist 10y ago> 1. Hitting refresh doesn't break everything. It resets your current state to the default. I default to the url combined with locally stored state, so you will lose text in an input field, but not much else. Really? 1. Go to your website. 2. Disconnect from the internet. 3. Hit Ctrl+Shift+R. How's that app you wrote as a website working for you?
- akamaozu 10y agoWorks well, actually. It's called appcache. Works in most browsers. You should look it up ;)