4 ms·

I honestly wonder if everything that is a best practice on the backend and frontend these days is a net negative compared to "Write your own PHP or Python code

by mg 3y ago

I honestly wonder if everything that is a best practice on the backend and frontend these days is a net negative compared to "Write your own PHP or Python code which outputs your own HTML+CSS+JS". Especially for indiemakers and startups by technical founders. All the frameworks add so much complexity and confusion. And I have seen several startups fail because when the developer was confronted with breaking changes of their framework, they said "Ok, that's enough. I'm not going to plow through this". The simple "PHP or Python talks to the DB and outputs an HTML interface" type startups have a pretty good success ratio on the other hand.

ransackdev 3y ago
I’ve rolled my own mvc framework before, In php even! This was years ago when CakePHP was the new hotness and Laravel didn’t exist. Take it from someone who had your mentality and set off to make a tiny and no bs mvc that just gets the job done, the amount of work these frameworks are doing for you (backend frameworks) that you don’t consider, is why you should run a framework. You don’t want to deal with processing a raw http request from the web server. You don’t want to split headers. You don’t want to sanitize input params, deal with character encoding, content types, gzipping, cache control, etags, basic authentication, flushing headers, chunking bodies, file streaming, tcp sockets, slow client avoidance, and probably 1000 other things I can’t recall. No matter how unnecessarily complex you think a http framework might be, I assure you, it’s saving you from a mountain of already solved by people smarter than you or I complexity.
- mg 3y ago
  You don’t want to deal with ... Well, I do all that and it works just fine for me. All my projects are 100% my own code down to the core. No frameworks, nothing. There might be some traces of jquery in there from when browsers were more unreliable. I don't even use that these days. To get to know those frameworks, I built some projects with Symfony, Laravel, Django and some others. But it didn't stick. They are too aggressive in their "do it my way, don't worry what happens behind the scenes, let me do the magic" approach. I had the best impression of Django. That is the only one I might give another try.
  - ransackdev 3y ago
    How’s your vulnerability reporting process and how much experience do you have interpreting complicated pen tester bug reports about some buffer overflow zero day in your homebrew query string parser? Huge difference between working fine, and working right. The security implications of rolling your own, is why I say “you don’t want to…” Also, none of that code has anything to do with the product you’re actually trying to build. Imo it’s additional maintaining, tech debt, attack surface, and it’s a solved problem by a large community and has more knowledge from the security community baked in, and more eyes finding and plugging holes.
    - pragmar 3y ago
      In the aughts, when everyone was rolling their own framework, security and maintenance were a nightmare. It's undeniable. We traded one problem for another, however, and we've gone too far. I think the question at hand is which is more secure/maintainable: 10kb of custom utilities or 100mb of mystery-meat modules that, let's face it, will never be reviewed. It's not a simple answer.
      - ransackdev 3y ago
        Smaller file sizes or less LOC is not inherently safer than larger sizes or more LOC. if you’re building web apps, you’re more than likely reaching for a handful of packages, and so are millions of other people, and so are multi billion dollar companies, companies with staff who’s job it is to do supply chain security, PCI compliance auditing, security assessments, who hire pen testing firms, and some even write browsers and can sway the direction of our entire industry and the internet as a whole. Countless static code analysis is ran on the millions of CI jobs a day on builds that pull in the package, etc. If you’re using popular and maintained open source packages, people are looking at them. Shy away from no name packages with no usage unless you personally look at the code. That’s my take on it. I tend to trust the open source community to all be working towards the shared goal of well crafted and secure code for the world to use and benefit from
  - mattgreenrocks 3y ago
- iamcalledrob 3y ago
  > You don’t want to deal with processing a raw http request from the web server. You don’t want to split headers. You don’t want to sanitize input params, deal with character encoding, content types, gzipping, cache control, etags, basic authentication, flushing headers, chunking bodies, file streaming, tcp sockets, slow client avoidance, and probably 1000 other things I can’t recall. The Golang stdlib does all this for you, no framework needed :) I honestly think Golang SSR with html templates + a sprinkling of Javascript to enhance is an extremely pragmatic way to go. You build your entire service into a single binary (assets included with go:embed). You shed the complexity of the framework AND the web server AND deployment in addition to React etc.
  - ransackdev 3y ago
    Golang is in a special class on its own. Write some handler functions and pass around a context struct and call it a day. I wish every stdlib took care of all that stuff :)
chrisco255 3y ago
Do they have a good success ratio? Do you have some data to back that assertion up where you've analyzed startup success by whether they used SSR or CSR? My own personal experience has been working at a large enterprise SSR app that ultimately failed to keep pace with increasing competition (but certainly achieved some success with basic SSR forms in the early 00s), then later worked for a team that had a $500M exit for which the CSR app and backend Node.js API was built with a minimal team size of just a few dozen devs.
- joenot443 3y ago
  I'd be pretty surprised if someone had gone to the effort to organize startups by SSR and CSR and then tried to make an empirical point with it. Just seems like a fool's errand to me, too much noise to get a useful signal. I have no doubt someone will bring up levelsio (hey Peter!) and his slew of wildly successful sites SSR sites powered by JQuery and PHP, but I've always felt his stack choice was secondary to his ability to market and quickly ship. It's a bit of a truism, but I've really come to accept these days that the best stack is whichever one your team is most productive with.
mattgreenrocks 3y ago
Mostly because it lowers the bar for execution. And that is not just a one time thing: it affects how fast you can on-board, ship new code, and refactor. And that iteration speed is key for chasing down product market fit, which is way more dangerous to a company than suboptimal tech.
grumblingdev 3y ago
100%. People get so intimidated by these huge frameworks and get FOMO, that they never try to build something from scratch. React seems simple, but if you tried to understand what is going on under the hood it would take you months. Simple should be: can you trace through all the code yourself. Like Backbone.js for example. Plus, there is already so much rendering complexity under the hood in browser engines. The DOM and CSS are already incredible abstractions available for you to use. I really don't get what is so bad about just having some object to manage a dom element's rendering. Create a single relational source of truth for your data. Then create some view models that listen to this source of truth. Then make your objects listen to these view models. This vdom diffing stuff is so overated. If you have a list of items, and a new item is inserted, I can just insert that directly into the dom. If I render a different entity and it uses mostly the same dom elements, it's really not that hard to tell say: here are some new props, compare them with your old ones, and do what you think is best. React promises this for the entire app but its all magic. I want control of my rendering so I can make things fast. Debugging perf issues in React is insane. Good luck debugging anything.
deleted 3y ago
[deleted]

by mg 3y ago

ransackdev 3y ago

I’ve rolled my own mvc framework before, In php even! This was years ago when CakePHP was the new hotness and Laravel didn’t exist. Take it from someone who had your mentality and set off to make a tiny and no bs mvc that just gets the job done, the amount of work these frameworks are doing for you (backend frameworks) that you don’t consider, is why you should run a framework. You don’t want to deal with processing a raw http request from the web server. You don’t want to split headers. You don’t want to sanitize input params, deal with character encoding, content types, gzipping, cache control, etags, basic authentication, flushing headers, chunking bodies, file streaming, tcp sockets, slow client avoidance, and probably 1000 other things I can’t recall. No matter how unnecessarily complex you think a http framework might be, I assure you, it’s saving you from a mountain of already solved by people smarter than you or I complexity.

mg 3y ago
You don’t want to deal with ... Well, I do all that and it works just fine for me. All my projects are 100% my own code down to the core. No frameworks, nothing. There might be some traces of jquery in there from when browsers were more unreliable. I don't even use that these days. To get to know those frameworks, I built some projects with Symfony, Laravel, Django and some others. But it didn't stick. They are too aggressive in their "do it my way, don't worry what happens behind the scenes, let me do the magic" approach. I had the best impression of Django. That is the only one I might give another try.
- ransackdev 3y ago
  How’s your vulnerability reporting process and how much experience do you have interpreting complicated pen tester bug reports about some buffer overflow zero day in your homebrew query string parser? Huge difference between working fine, and working right. The security implications of rolling your own, is why I say “you don’t want to…” Also, none of that code has anything to do with the product you’re actually trying to build. Imo it’s additional maintaining, tech debt, attack surface, and it’s a solved problem by a large community and has more knowledge from the security community baked in, and more eyes finding and plugging holes.
  - pragmar 3y ago
    In the aughts, when everyone was rolling their own framework, security and maintenance were a nightmare. It's undeniable. We traded one problem for another, however, and we've gone too far. I think the question at hand is which is more secure/maintainable: 10kb of custom utilities or 100mb of mystery-meat modules that, let's face it, will never be reviewed. It's not a simple answer.
    - ransackdev 3y ago
      Smaller file sizes or less LOC is not inherently safer than larger sizes or more LOC. if you’re building web apps, you’re more than likely reaching for a handful of packages, and so are millions of other people, and so are multi billion dollar companies, companies with staff who’s job it is to do supply chain security, PCI compliance auditing, security assessments, who hire pen testing firms, and some even write browsers and can sway the direction of our entire industry and the internet as a whole. Countless static code analysis is ran on the millions of CI jobs a day on builds that pull in the package, etc. If you’re using popular and maintained open source packages, people are looking at them. Shy away from no name packages with no usage unless you personally look at the code. That’s my take on it. I tend to trust the open source community to all be working towards the shared goal of well crafted and secure code for the world to use and benefit from
- mattgreenrocks 3y ago
iamcalledrob 3y ago
> You don’t want to deal with processing a raw http request from the web server. You don’t want to split headers. You don’t want to sanitize input params, deal with character encoding, content types, gzipping, cache control, etags, basic authentication, flushing headers, chunking bodies, file streaming, tcp sockets, slow client avoidance, and probably 1000 other things I can’t recall. The Golang stdlib does all this for you, no framework needed :) I honestly think Golang SSR with html templates + a sprinkling of Javascript to enhance is an extremely pragmatic way to go. You build your entire service into a single binary (assets included with go:embed). You shed the complexity of the framework AND the web server AND deployment in addition to React etc.
- ransackdev 3y ago
  Golang is in a special class on its own. Write some handler functions and pass around a context struct and call it a day. I wish every stdlib took care of all that stuff :)

chrisco255 3y ago

Do they have a good success ratio? Do you have some data to back that assertion up where you've analyzed startup success by whether they used SSR or CSR? My own personal experience has been working at a large enterprise SSR app that ultimately failed to keep pace with increasing competition (but certainly achieved some success with basic SSR forms in the early 00s), then later worked for a team that had a $500M exit for which the CSR app and backend Node.js API was built with a minimal team size of just a few dozen devs.

joenot443 3y ago
I'd be pretty surprised if someone had gone to the effort to organize startups by SSR and CSR and then tried to make an empirical point with it. Just seems like a fool's errand to me, too much noise to get a useful signal. I have no doubt someone will bring up levelsio (hey Peter!) and his slew of wildly successful sites SSR sites powered by JQuery and PHP, but I've always felt his stack choice was secondary to his ability to market and quickly ship. It's a bit of a truism, but I've really come to accept these days that the best stack is whichever one your team is most productive with.

mattgreenrocks 3y ago

Mostly because it lowers the bar for execution. And that is not just a one time thing: it affects how fast you can on-board, ship new code, and refactor. And that iteration speed is key for chasing down product market fit, which is way more dangerous to a company than suboptimal tech.

grumblingdev 3y ago

100%. People get so intimidated by these huge frameworks and get FOMO, that they never try to build something from scratch. React seems simple, but if you tried to understand what is going on under the hood it would take you months. Simple should be: can you trace through all the code yourself. Like Backbone.js for example. Plus, there is already so much rendering complexity under the hood in browser engines. The DOM and CSS are already incredible abstractions available for you to use. I really don't get what is so bad about just having some object to manage a dom element's rendering. Create a single relational source of truth for your data. Then create some view models that listen to this source of truth. Then make your objects listen to these view models. This vdom diffing stuff is so overated. If you have a list of items, and a new item is inserted, I can just insert that directly into the dom. If I render a different entity and it uses mostly the same dom elements, it's really not that hard to tell say: here are some new props, compare them with your old ones, and do what you think is best. React promises this for the entire app but its all magic. I want control of my rendering so I can make things fast. Debugging perf issues in React is insane. Good luck debugging anything.

deleted 3y ago

[deleted]