[HN Gopher] Server side rendering is now good idea?
___________________________________________________________________
Server side rendering is now good idea?
Thanks to the speed of the internet, I'm beginning to feel that
logic on server side with PHP or other server side technology, is
just as interactive as JavaScript - without the complexity of
React, Angular [insert framework here] and associated package and
state management. Oh, and security! Thoughts?
Author : mrvenkman
Score : 12 points
Date : 2023-01-06 20:41 UTC (2 hours ago)
| sergiotapia wrote:
| It's a lot simpler for sure these days. I've built my indie
| startup with Phoenix Liveview. It's all server side rendered,
| with liveview sprinkling in interactivity.
|
| Can you tell it's server side rendered?
| https://www.gamedrop.gg/lists/slymilano/exciting-game-releas...
|
| https://www.gamedrop.gg/game/hogwarts-legacy
|
| I think there are similar tools in other platforms like Rail's
| and Laravel.
| comrad wrote:
| Oh, are we now full circle back to good old server side
| programming again. Just like in the 90s? I mean it's not bad -
| but it's definetly not new...
| v3ss0n wrote:
| Even in J's world they are back to server side rendering, check
| astro
| endisneigh wrote:
| I'll be a contrarian here. Client side rendering is just getting
| started. With faster storage for cheap and fast internet there
| will be less and less reason to put things in a server. Add in
| things like wanting end-to-end encryption, privacy issues and
| most things will be in the browser, imho.
| speedgoose wrote:
| Always has been.
|
| I think that you do need interactivity through JavaScript at some
| point. And I find react and similar easier to maintain than an
| HTML/JS soup generated by PHP, JSP, or RoR.
|
| I would take a look at https://fresh.deno.dev/ or
| https://kit.svelte.dev/ or https://nextjs.org/
| eyelidlessness wrote:
| Others worth a look:
|
| - Qwik[1]: code is very similar to React, only the interactive
| parts are sent to the browser, and they only execute on demand
| (eg when you interact with the thing)
|
| - Astro[2]: probably the most popular "islands" framework, lets
| you bring your own interactive framework
|
| - SolidStart[3]: doesn't mention in the docs yet for some
| reason, but also supports "islands" in SolidJS, which is also
| one of the fastest client frameworks and also will feel
| familiar coming from React
|
| [1]: https://qwik.builder.io/
|
| [2]: https://astro.build/
|
| [3]: https://start.solidjs.com/getting-started/what-is-
| solidstart
| andrewfromx wrote:
| checkout how rails does best of both worlds with something called
| "turbo" https://www.hotrails.dev/turbo-rails/crud-controller-
| ruby-on...
| pbedat wrote:
| Turbo is just a JS library, not tied to rails. I use it with
| golang and I love it! It offers a nice tradeoff between heavy
| custom HTML attributes and too much 'convention over
| configuration'. Also pairs nicely with alpine.js
| smackeyacky wrote:
| Security definitely. You are leaking far less of your web
| interface by rendering everything on the server. There are a lot
| of neat SPA out there, but anything that is doing a boring old
| CRUD kind of job really should be server side just to reduce the
| attack surface.
| thinkmcfly wrote:
| It always has been the best. You can't even scroll down on a
| modern js heavy site without having to wait for content to load.
| caprock wrote:
| You might want to look into what the creator of htmx has to say
| about this topic. He's here on hn and may even show up for this
| thread.
|
| Here are the essays:
|
| * https://htmx.org/essays/
| mrvenkman wrote:
| Fantastic article. And I appreciate you sharing it with me.
|
| The idea of introducing a new attribute to a HTML tag, whether
| it be "_" or "_foo" or "_do" doesn't quite sit properly with
| me.
|
| Especially if it's not part of the HTML5 standards.
|
| For your scenario the attribute name being "_" may work. But
| [deleted]
___________________________________________________________________
(page generated 2023-01-06 23:02 UTC)