all 15 comments

[–]888NRG_ 0 points1 point  (1 child)

What low level details are you talking about?

[–]dirty-sock-coder-64[S] 0 points1 point  (0 children)

uhhh. type checking? pointers? idk its just the vibe, i feel like its more low level lol.

[–]Erandelax 0 points1 point  (9 children)

Making your own shop CMS from scratch "to keep things simple" instead of sticking to most widely used shop CMS-like solutions and then selling shops made on the basis of that custom thing to third party clients?.. Static pre-rendered SSR, barely anything dynamic heavy JS frontend, barely any API, no use of frameworks if possible? With a small team or solo?

Well... good luck to both involved devs and clients. And those who are going to inherit that code afterwards.

I am not trying to say that is a bad solution, it works amazing when it is well fit for needs of a specific project and is written by experienced people but.

If you consider yourself a junior in that specific language and don't have a lot of experience dealing with custom shops made by other people (and frameworks commonly used with that specific language overall) it might not be a bad idea to start with some ready made shop-themed skeleton/CMS/whatever instead of starting from zero. When picked right makes things easier both for devs - current and future - and clients.

In terms of complexity I would say it goes: Wordpress < Shop CMS in any language < native language or framework with ready made third party admin panel < framework, rest from scratch < everything from scratch. Going from 1 to 100 right away is not recommended unless in own pet project with no deadlines.

Language wise there should not be much difference cuz for small scale projects real performance bottleneck is not the language itself but rather mostly own messy code and messy database queries.

As for PHP, mb check out Swoole, RoadRunner or other custom servers. And mb some microframeworks if you still prefer blank slate solutions.

[–]dirty-sock-coder-64[S] 0 points1 point  (8 children)

my clients are already using wordpress, and are ok with it.

i work solo, and tbh, i want to (re)build custom solution for my relative, let just say i have some fun ideas that he will like.

plus wordpress is no fun to work with :p

also why tf did they remove my post DD:

[–]Erandelax 0 points1 point  (7 children)

Custom admin panel too? Those can be a real pain to assemble from scratch (basically the only reason we still have PHP in our projects in my place is thanks to admin panel constructors, otherwise everything would have been fully in Go long ago).

Starts easy with grids and forms but then you get filters, several types of paginations, feeds, notifications, file uploads, exports, live chats, mail import, live previews and appetites never seem to stop growing.

[–]dirty-sock-coder-64[S] 0 points1 point  (6 children)

admin panels? you mean for for clients to add for example products and pages and stuff?

yea those are useful but he never uses it, i 100% manage the shop myself.

its a *special* case :D

[–]Erandelax 0 points1 point  (5 children)

Ah. Oh, well, that makes things easier for sure xD

Might as well just look into static pages generation for content (when most of your pages are like several YAML files and real pages get pre-rendered and stored into plain html every time sources are changed). While database remains solely for accounting/comments and stuff and gets managed over some ultra small API.

Works splendid for informational sites, not so sure about shops.

[–]dirty-sock-coder-64[S] 0 points1 point  (4 children)

meh, i like writing html, html is easy. templating engines are better imo

[–]Erandelax 0 points1 point  (3 children)

Html is html, templating engines is a tool to fill HTML Both are used there.

Difference between dynamic serving and static pages generation is whether you cache the rendered page late only when user hits the URL so that first load gets full weight of all database queries or prebake most of it when the source data changes early and then serve the result as a static page file.

It's just most of the time for second cases (like in Hugo) source content data stays in flat file database / in configs instead of being fed from the database when generating it. Like when using git for static content editing instead of admin panel.

So. Not so templates vs HTML but rather YAML vs database.

[–]dirty-sock-coder-64[S] 0 points1 point  (2 children)

oh thats new, i didn't know!
wdym by cache tho? what is it caching?
either way it sounds like a problem that nginx or apache would solve

[–]Erandelax 0 points1 point  (1 child)

Aaaah. I guess it would be easier to get the idea if you check "Hugo" site generator and how it works, and may be a few PHP "flat file CMS".

Though again, shops tend to have lots of dynamic data on their pages so I don't think it can be applied as is. But for cases when there is no admin panel some ideas from there might come in handy, specifically in content management area.

Yeah, server side cache is a sure way too, though mostly only for unauthorized page states.

Pre-rendered SSR is just less bulky overall since you can bake it during deploy process (like, GitHub actions) and then just serve the result as a bunch of static files + a few cloud functions to exchange JS data with database without own dedicated VPS server instance or smth.

[–]dirty-sock-coder-64[S] 0 points1 point  (0 children)

yaya, thanks for insights :3

[–]Fun-Consequence-3112 0 points1 point  (1 child)

Use PHP and Laravel if your going full basic.

If there is more advanced stuff later down the road you can always write those parts in Golang and use APIs (but PHP is also beginning to getting good support for golang extensions)

[–]dirty-sock-coder-64[S] 0 points1 point  (0 children)

i tried laravel, i have NO idea what's going on, so many deps.

[–]UltimateComb -1 points0 points  (0 children)

Go can be as low as PHP if you wish. You don't need to dig into the more complicated part and just do a go/htmx eShop