4 ms·

Have you tried PHP? :) I jest, but really I feel like we've made things so complicated it just gets in our way. Our Javascript pipeline is huge, complicated, a

by speg 6y ago

Have you tried PHP? :) I jest, but really I feel like we've made things so complicated it just gets in our way. Our Javascript pipeline is huge, complicated, and requires you to sit down and wrap your head around it every time you want to modify it. If I get to greenfield another project, it's going to be so bloody simple.

Waterluvian 6y ago
I'm writing applications for people to manage fleets of thousands of robots in real-time from the other side of the planet. There's no room for "bloody simple" =D They don't resemble traditional websites/CRUD apps a whole lot. Much closer to Sim City + Factorio. When it comes to making your standard issue website/webapp, I think some of them could stand to be simpler.
folkrav 6y ago
> If I get to greenfield another project, it's going to be so bloody simple. It's always simple when it starts up. It's after months/years of iterating without having a decent battle plan that it becomes complicated.
- OJFord 6y ago
  I agree things grow to be complicated, and that's somewhat unavoidable (accepting usual constraints), but they don't have to start out complex. I think that's the same point GP is making.
  - folkrav 6y ago
    Fair enough.
whalesalad 6y ago
PHP has to bootstrap everything on every single request. It is definitely great for reloadability and local development but terrible for production performance. Most teams that do not need PHP or love it (Laravel is great I know) have moved to using languages and frameworks that provide a long running application server.
- mjburgess 6y ago
  The "run once and die" model of php applications however, it extremely clarifying and simplifying. It is a bit like the unix philosophy of "simple apps, in sequence" -- in the sense that it clarifies what development should be. PHP apps, at their best, were multiple "run once and die" endpoints -- the drive to "Front Controller" and "run long" apps throws away much of the value of this paradigm. Part of the community problem, id say, is that this paradigm was never well-articulated; and always associated with "a mess". People like rasmus tried: yes have your long-running apps (eg., in Java), but your front-end should be die-quickly.
- toast0 6y ago
  PHP isn't that bad for production performance, if you have the right mindset. Another way of saying PHP has to bootstrap everything on each request (which is a bit of an overreach; it doesn't reload C libraries, and you can do opcode caching and data caching, etc), is that PHP throws away everything you've done after each request. That means everything that you build that isn't output somewhere is garbage. If you spend a lot of time making a sculpture out of garbage, only to throw it away, you'll have poor performance. If you use the minimum of scaffolding to send out the bytes you want to send, you can get pages (or api responses, whatever) with a few ms of overhead in addition to your underlying data fetches. You could certainly go faster with something else, but PHP can be decently fast. On the other hand, your code won't look at all like what people think of as 'modern' PHP.
- allan_s 6y ago
  I'm really sorry to say this but you're spreading FUD 1. slack backend is written in php and other big companies. 2. php is actually faster than python/ruby 3. opcache in production (which is both simple to activate AND a well-known best practices among people doing php professionally) eliminate the performance hit you will get. 4. your backend language performance is often far from being the bottleneck in most endpoint where performance do matters , it's often either a database optimization problem, an algorithm problem or a really CPU intensive tasks that you will offload to a dedicated library written in C. I perfectly understand PHP does have a lot of flaws, but production performance is not one.
allan_s 6y ago
I feel you, I have currently the chance to start a greendfield project, * backend in php8 with symfony framework * postgres * frontend is only html+tailwind css and 2 lines of javascript here and there for a smooth transition effect (https://christopheraue.net/design/fading-pages-on-load-and-unload) and I just got my PWA accepted by google store , and my 18 lines react-native app embedding the website in a page view for apple store is in review. no javascript madness, and the app is so snappy that everybody ask me which kind of react optimization i'm using : "the one where you remove it completly"

by speg 6y ago

Waterluvian 6y ago

I'm writing applications for people to manage fleets of thousands of robots in real-time from the other side of the planet. There's no room for "bloody simple" =D They don't resemble traditional websites/CRUD apps a whole lot. Much closer to Sim City + Factorio. When it comes to making your standard issue website/webapp, I think some of them could stand to be simpler.

folkrav 6y ago

> If I get to greenfield another project, it's going to be so bloody simple. It's always simple when it starts up. It's after months/years of iterating without having a decent battle plan that it becomes complicated.

OJFord 6y ago
I agree things grow to be complicated, and that's somewhat unavoidable (accepting usual constraints), but they don't have to start out complex. I think that's the same point GP is making.
- folkrav 6y ago
  Fair enough.

whalesalad 6y ago

PHP has to bootstrap everything on every single request. It is definitely great for reloadability and local development but terrible for production performance. Most teams that do not need PHP or love it (Laravel is great I know) have moved to using languages and frameworks that provide a long running application server.

mjburgess 6y ago
The "run once and die" model of php applications however, it extremely clarifying and simplifying. It is a bit like the unix philosophy of "simple apps, in sequence" -- in the sense that it clarifies what development should be. PHP apps, at their best, were multiple "run once and die" endpoints -- the drive to "Front Controller" and "run long" apps throws away much of the value of this paradigm. Part of the community problem, id say, is that this paradigm was never well-articulated; and always associated with "a mess". People like rasmus tried: yes have your long-running apps (eg., in Java), but your front-end should be die-quickly.
toast0 6y ago
PHP isn't that bad for production performance, if you have the right mindset. Another way of saying PHP has to bootstrap everything on each request (which is a bit of an overreach; it doesn't reload C libraries, and you can do opcode caching and data caching, etc), is that PHP throws away everything you've done after each request. That means everything that you build that isn't output somewhere is garbage. If you spend a lot of time making a sculpture out of garbage, only to throw it away, you'll have poor performance. If you use the minimum of scaffolding to send out the bytes you want to send, you can get pages (or api responses, whatever) with a few ms of overhead in addition to your underlying data fetches. You could certainly go faster with something else, but PHP can be decently fast. On the other hand, your code won't look at all like what people think of as 'modern' PHP.
allan_s 6y ago
I'm really sorry to say this but you're spreading FUD 1. slack backend is written in php and other big companies. 2. php is actually faster than python/ruby 3. opcache in production (which is both simple to activate AND a well-known best practices among people doing php professionally) eliminate the performance hit you will get. 4. your backend language performance is often far from being the bottleneck in most endpoint where performance do matters , it's often either a database optimization problem, an algorithm problem or a really CPU intensive tasks that you will offload to a dedicated library written in C. I perfectly understand PHP does have a lot of flaws, but production performance is not one.

allan_s 6y ago

I feel you, I have currently the chance to start a greendfield project, * backend in php8 with symfony framework * postgres * frontend is only html+tailwind css and 2 lines of javascript here and there for a smooth transition effect (https://christopheraue.net/design/fading-pages-on-load-and-unload) and I just got my PWA accepted by google store , and my 18 lines react-native app embedding the website in a page view for apple store is in review. no javascript madness, and the app is so snappy that everybody ask me which kind of react optimization i'm using : "the one where you remove it completly"