top | item 37178208

(no title)

bigmanwalter | 2 years ago

All this to get a feature that was already prevalent 15 years ago in oldschool PHP applications.

discuss

order

joshstrange|2 years ago

Spoken like someone who doesn't need and/or understand SPA-style features. Look I get it, I've been developing with PHP for close to 2 decades but let's not pretend that PHP+jQuery (or whatever you are using for frontend interaction) is anywhere near as powerful as a SPA+SSR. And yes, not every site needs to be a SPA but there are some sites where that absolutely is the right call and pairing it with SSR can get you "the best of both worlds".

esskay|2 years ago

If you're building an SPA for an Ecommerce site you've seriously misunderstood the web.

These days you can slap together a very capable PHP based Ecom solution using Livewire for those sections that need interactivity.

People really need to realise just how detremental to the user experience it is to have mountains of JS being needed just for an ecommerce site.

Aloha|2 years ago

Who does need an SPA?

jensensbutton|2 years ago

This is a weird comparison. You can use PHP to power an SPA with SSR. It's not an either or.

flimsypremise|2 years ago

15 years ago a frontend build was not a thing. You managed what few javascript and CSS dependencies you had via the order of the script and style tags in the header. Now a frontend build is a baked in requirement of any user-facing application, so whatever you end up doing in whatever language, you already have that one build to manage. If you choose to build your application in anything other than JS/TS, you are effectively adding an additional build to the project, with all of the associate overhead. If you stick with one language and one build, you are eliminating large swaths of unnecessary complexity right off the bat. Not to mention that you don't have to hire for the additional language for the dev team.

Unless there is a legacy system driving the requirements in a different direction, my default application architecture is always going to be server-side React at this point.

breckenedge|2 years ago

> Not to mention that you don't have to hire for the additional language for the dev team.

Or maybe hire people who can code in more than one framework.

bakuninsbart|2 years ago

User facing in what way? There seem to still be a ton of new RoR or Django projects without react/ or angular out there.

translucyd|2 years ago

I feel sometimes that we are running in circles in front end development. We had a good thing: Then we burned, step on it, and then recreated it because it was the best way to do things in the end of the day. :(

hinkley|2 years ago

You should feel that all the time.

But it’s not a circle, it’s an arc. If it were a circle, running as fast as you can in one direction would bring you back around to the former. Instead we hit the end of the swing and backpedal until we remember why we were going this direction in the first place.

kjkjadksj|2 years ago

I feel like this is the inevitability of more and more tooling being released. Eventually there will be so much tooling that its hard to even work effectively as the signal to noise ratio plummets over time.

ericmcer|2 years ago

You should really try something like NextJs, all the nightmarish parts of FE development are abstracted away. It makes me hopeful for a future where all the config files and tools are invisible and you just develop applications. All the TS, HMR, SSR, etc. is invisible to you and managing it is the responsibility of the people developing the frameworks.

fHr|2 years ago

front end is such a shit show these days endless and then stuff runs for 1 month stable and instead of adresing real issues they come up with another rewrite.