6 ms·
I think people are now ready for php. I bet it will be reinvented on top of nodejs.
by podgorniy 1y ago
I think people are now ready for php. I bet it will be reinvented on top of nodejs.
- edu 1y agoI think they go with a PHP implementation on WASM so it runs on the client
- mhd 1y agoI'm voting for Cold Fusion on top of Golang.
- deleted 1y ago[deleted]
- pjmlp 1y agoToo advanced typesystem for Go folks, better keep it on top of Java. /s
- inopinatus 1y agoIt’s about time. We already reinvented Lotus Notes.
- tonyedgecombe 1y agoLotus Notes was great until they added email.
- Etheryte 1y agoGiven you can run Doom on your fridge these days, it should be absolutely no surprise that you can already run PHP both in the browser and in Node [0]. [0] https://github.com/asmblah/uniter https://github.com/asmblah/uniter
- bob1029 1y agoAt some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much in the more meaningful domains of business since you can't cheat god (information theory). If the data is so frequently out of sync that every interaction results in JSON payloads being exchanged, then why not just render the whole thing on the server in one go? This is where I can easily throw the latency arguments back in the complexity merchant's face - you've simply swept the synchronization problem under a rug to be dealt with later.
- worldsayshi 1y agoWhat about a feature like query completion?
- lyu07282 1y agothere probably is a jQuery plugin for that /s
- 1oooqooq 1y agohtml native datalist?
- simongray 1y agoThe behaviour of an HTML datalist is basically completely different in every browser. It is a highly flawed element.
- gwd 1y agoThe query completion can also be SSR. The example below is HTMX for Active Search, but the principle is the same: https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/
- worldsayshi 1y agoI suppose that is a rather neat way to do it.
- endemic 1y agoSSR doesn't mean "no JavaScript." See "progressive enhancement."
- zarzavat 1y ago> modern internet connection Have you heard of these things called smartphones? I hear they're getting quite popular.
- 1y ago
- bblb 1y agoGlad I skipped the whole "JavaScript only" webdev phase. My mad PostNuke skills are relevant again.
- franky47 1y agoIndeed, the Platformatic folks announced just that last week: https://blog.platformatic.dev/laravel-nodejs-php-in-watt-runtime https://blog.platformatic.dev/laravel-nodejs-php-in-watt-run...
- donatj 1y agoAs a long time PHP developer, it never fails to amuse (amaze?) me the lengths people go to in order to get the things the browser will give you for free.
- jiggawatts 1y agoThe most "special" code that I regularly come across is when a developer takes a JPG in blob storage -- already a public HTTPS URL -- then serves that in a "Web API" that converts it to base-64 encoded bytes inside JSON, sends it to client JavaScript, decodes it, and feeds it to an image in code. Invariably, it's done with full buffering of the blob bytes in memory on both server and client, no streaming. Bonus points are awarded for the use of TypeScript, compression (of already compressed JPGs, of course), and extensive unit and integration tests to try and iron out the bugs.
- asa400 1y agoThis is truly beautiful. Art, even.
- cnnlive789 1y agophp is great but I’m surprised by how people are not discussing htmx. It’s a chance to start all over yet again! Come on- we’re all up for that, we do it every few months!
- recursivedoubts 1y agosmdh!
- chuckadams 1y agoThe browser gives you a full-blown programming language with a rich API, but it seems a lot of people avoid that in favor of smushing together a static view on the server side with little more than string interpolation.
- endemic 1y ago
- tonyedgecombe 1y agoI'd love to see a modern PHP without all the warts but with the ease of use.
- johnisgood 1y agoI think you are in for a treat, then, because PHP 8 is way different from PHP 5.
- tonyedgecombe 1y agoUnless they have abandoned backwards compatibility then I don't think that is what I meant.
- johnisgood 1y agoMajor differences that I can think of between the two are (with regarding to warts and ease of use): PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on. PHP 8 has strong support for static typing now, thank goodness. PHP 8 introduces union types (int|float|null). PHP 8.1 introduces intersection types (A&B). PHP 8.1 added the "never" return type. PHP 8 has less repetitive boilerplate. PHP 8 has consistent function signatures now. PHP 8 has consistent object/array syntax now (to be honest, some asymmetries remain). PHP 8 has named arguments for clarity and flexibility. PHP 8 has the nullsafe operator which simplifies deeply nested null checks. PHP 8 has arrow functions which makes closures concise and easier to use. PHP 8 has attributes, e.g. "#[Route("/users")]". PHP 8 has "match" expressions which is a more predictable, type-safe, and expression-oriented alternative to "switch". PHP 8 has many more tools for testing and debugging (incl. static analyzers). PHP 8 has many new functions (incl. utility functions). PHP 8.1 introduces native enums. PHP 8.1 has "readonly" properties for enforcing immutability. PHP 8.1 has cleaner syntax for referencing callables. PHP 8.1 has "fibers" which enables cooperative multitasking and is a foundational building block for upcoming async/await features. Global namespace pollution has been pretty much resolved (Composer autoloading[1]). There are other ecosystem-level improvements such as PSR standards[1], better async story, etc. This list is non-exhaustive. These are just the improvements that come to mind off the top of my head so I probably missed a lot of other major improvements. PHP 8+ is definitely much easier to use and they greatly reduced PHP's warts. There may be some inconsistencies left here and there, but they are not a deal-breaker IMO, if you even run into them. [1] https://www.phptutorial.net/php-oop/php-composer-autoload/ https://www.phptutorial.net/php-oop/php-composer-autoload/ (I do not use "dump-autoload"), https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-examples.md https://github.com/php-fig/fig-standards/blob/master/accepte..., https://www.php-fig.org/psr/psr-4/ https://www.php-fig.org/psr/psr-4/ (https://www.php-fig.org/psr/ https://www.php-fig.org/psr/) --- I strongly recommend taking a fresh look at PHP 8+. It is very different from the PHP you have once known. It is "modern" now. There are lots of deprecations and removal of old warts. I did not like PHP as much ages ago, but it was a pleasure to use PHP 8+. If you are looking to (re)learn PHP, the book “PHP & MySQL: Novice to Ninja” is a good starting point[1]. There are many other, high-quality books and resources as well. [1] Available on libgen. The source code examples from the book are available on GitHub: https://github.com/spbooks/phpmysql7 https://github.com/spbooks/phpmysql7. --- If you have any specific warts or whatnot, or if you want more resources, please do feel free to let me know. --- I wrote this comment on my phone, so it is not as detailed and it is not structured as well, but I hope that it will still provide some insight into the differences between legacy PHP and modern PHP. Happy to answer any questions!
- pjmlp 1y agoI feel revindicated for staying with ASP.NET and JavaEE/Spring all these years. Next.js is kind of bareable, as it uses the same approach, going back to the roots of web development, it is almost as doing JSPs all over again.
- jermaustin1 1y agoI actually started my own PHP based on C# called CHP for fun. It runs atop whatever the current dotnet hosting service is (Kestrel?). It takes everything inside the "<? ?>" code blocks and inlines it into one big Main method, exposing a handful of shared public convenience methods (mostly around database access and easy cookie-based authentication), as well as the request and response objects. Each request is JITed, then the assembly is cached in memory for future requests to the same path, and it will recompile sources that are newer than the cached assembly. There is no routing other than dropping the .chp extension if you pass "-ne" into the arguments launching the server. It's not very far along, and is completely pointless other than for the sake of building my own web language thingy for the first time since 2003.
- bob1029 1y agoHave you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings: var reportPartial = @$" <h1>{report.Name}</h1> <table> {string.Join('\n', report.Items.Select(reportItem => @$" <tr> <td>{reportItem.Col1}</td> <td>{reportItem.Col2}</td> </tr> "))} </table> "; In more complex views or reuse scenarios, I'd push the inner interpolation loop to a method. This is how I've been building my .NET web apps for the last ~3 years. @+$ = PHP in C# as far as I'm concerned.
- naasking 1y agoSome dangers with injection attacks if you don't santitize inputs correctly, but this is probably faster than most templating languages like razor.
- Xss3 1y agoIt's super easy to add sanitization middleware in .NET.
- bob1029 1y agoThere are a lot of ways to manage this problem. My preferred path is to wrap interpolated fields with HttpUtility.UrlEncode() when I know a user can touch it and there are plausible reasons for allowing 'illegal' characters at form submit time. In terms of performance, it is definitely faster. The amount of time it takes to render these partials is negligible. You'd have to switch up your tooling to measure things in microseconds instead of milliseconds if you wanted any meaningful signal.
- qudat 1y agoIt’s called nextjs
- colgandev 1y agoIt has been wild to realize I've now seen one full technology cycle of thin client to thick client to thin client again. Maybe PHP this time around will be able to be more robust with the lessons learned.
- labrador 1y agoprogram like it's 1999