"You can’t build a decent modern application without frameworks."
Bullshit, especially on the PHP / backend side. It's 2017, we should know how to avoid over engineering simple things.
“Hello, (real) world” in PHP in 2017
101–110 of 144 posts
Re: “Hello, (real) world” in PHP in 2017
#102While reading i was thinking "..but that all makes sense for any project that's larger than a few hundred lines.." and thought the author was just ignorant and needlessly cynical. But at the end of the article, he makes a good point: Disputes like “Why do I need PHP if there’s Java?” have become more frequent nowadays. I don’t know who’s in the right, Holly Wars are tricky. But each dispute has an argument in favor o…
I like to argue that you can start off using PHP as a scripting language with a single index.php file, then maybe learn to use some of the simple frameworks like Slim (though even that has become more complicated recently), then move from that to Symfony or the like. This is a point the original author misses. If you introduce beginners in PHP to Symfony and SPAs from the start obviously they're going to have a bad t…
I'm not convinced that this approach flattens the learning curve significantly. The concepts are different, and when you're at the end of that journey and look back, you'll find that you spent a large amount of time unlearning things. That is if you ever get there. It's easy getting stuck on local maxima when avoiding steep learning curves.
In other words, old school PHP and modern PHP are two vastly different beasts with few commonalities.
There is no way past learning the basics (OOP, patterns, proper architecture), by deferring that in favour of an easier start you're only lengthening the journey.
Re: “Hello, (real) world” in PHP in 2017
#103Earlier quoted context omitted.
And to just pile on with this comment, "run everywhere" means much more than it ever did. This isn't just the big 3 desktop OS's, but laptops, tablets, phones, TV's, game consoles, car navigation units, hell my goddamn watch can run websites now! X86, ARM, SPARC, PPC, it doesn't matter. And on most of those platforms, you have more than one choice of browser. It's a level of cross-platform that really only simple C p…
Except it is simple: Hello World Hello World It's responsive, works on every HTML-compatible platform and is even backwards compatible to a degree that none of the other aforementioned solutions even comes close. We make it more complicated for ourselves because we choose to make it more complicated. I'm not against modern frameworks but quite often I see people justifying them rather than using them when they become…
Don't forget my proprietary pet peeve for proper mobile rendition: . Don't get me started :)
Re: “Hello, (real) world” in PHP in 2017
#104Earlier quoted context omitted.
Users overwhelmingly prefer some amount of client-side interaction, so how do you do that without JavaScript?
css :hover with hrefs to fast-loading pages can give the illusion of interactivity without any javascript (or even server processing, if the whole site is statically-generated).
Most people don´t know how to build this because their X MB JS framework just slows everything down.
Re: “Hello, (real) world” in PHP in 2017
#105I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification for using these tools is presented as "it's 2017" and not as a solution to any particular problem. The issue isn't the 2017 ecosystem, the issue is the 2017 programmer's deference to vanity instead of engineering. All these individual tools exist for a reason,…
The combination definitely seems overwhelming, but each tool is a solution to a real problem. That's where the "(real)" in the title is coming from. Yes, if you're only writing a hello world app you certainly don't need all that bloat, but if you're writing a real world app, here's a list of legitimate requirements you have to fulfill: 1. You offered your client a static page with purple background, blinking title, a…
JSON-RPC? Not in my 2017. The last time I've had to use that was with an old version of Zabbix https://www.zabbix.com/documentation/2.2/manual/api
Nah, it's all about http://jsonapi.org these days. GraphQL seems neat. Cap'n Proto also seems neat but I'm unaware of anything actually using it. gRPC is also neat but AFAIK not supported in a browser, so you need some kind of gateway to have it work with browser clients anyway (think SPAs calling APIs which can normally service server to server over gRPC). CPNP has the same-ish problem in that it doesn't fully work in browsers (serialization works but not RPC).
Re: “Hello, (real) world” in PHP in 2017
#106I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification for using these tools is presented as "it's 2017" and not as a solution to any particular problem. The issue isn't the 2017 ecosystem, the issue is the 2017 programmer's deference to vanity instead of engineering. All these individual tools exist for a reason,…
I think all these tools give you structure, though.
Every project is setup in an identical or similar way, which makes it easy for other developers to jump in and understand what's going on.
Re: “Hello, (real) world” in PHP in 2017
#107I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification for using these tools is presented as "it's 2017" and not as a solution to any particular problem. The issue isn't the 2017 ecosystem, the issue is the 2017 programmer's deference to vanity instead of engineering. All these individual tools exist for a reason,…
On a similar note, I always find it ridiculous when I have to do things like apt-get install npm && npm install bower && bower install ... Why can't we just use apt-get and Makefiles for everything? Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
Welcome to dependency hell! Working for years in different "php environments" I learnt that most (web) developers I met in this field tend to use as much new fancy tools out there without thinking about business value and longterm impact. At the end of the day you might end up with more than four dependency systems...
To respond to your initial question if we really need so much dependency systems: No, we don't need to!
As the author already needs to use composer to set up PHP dependencies why not use composer for the other packages required? It's not a problem to get the common needed libraries via composer which dramatically reduces dependency complexity, deployment and build scripts because you don't need that much tools.
Re: “Hello, (real) world” in PHP in 2017
#10899% of real-world apps out there could be implemented with a BAAS and some simple JS MVC framework (good ol' BackboneJS in my flavor, if not jQuery fancy). I am not talking about building million-user-base facebooks and twitters, I am taking about a fuckzillion apps with a dozen at best concurrent users that will thrive in Firebase's free tier, a damnzillion worpress sites that never-fucking-ever get updated and woul…
FWIW the Wordpress situation and specifically my personal site getting hacked even though I was a sysadmin working in hosting at the time are why I love static site generators. Moveable Type was always amazing and scaled with traffic literally 100x as well as Wordpress out of the box (Varnish and W3 Total Cache can help if you ever need it, but again "out of the box"), so I'm happy to see that things like Jekyll and Hugo are trendy. The fundamental idea behind SSGs just makes so much sense to me; optimize it for viewing (in terms of computational power spent on serving traffic), which it'll be doing many more times than it will be created. Why generate a page on each visit when that page will be exactly the same until the post gets updated? I understand that many WP sites are much much much more than blogs (like shopping carts, ooh god why), but that's a different conversation entirely.
Wordpress (and any dynamic CMS) is like having a library full of whiteboards with the contents of the books written on them, with about the same potential for vandalism.
Re: “Hello, (real) world” in PHP in 2017
#109Maybe I am old fashioned and outdated. I don't know about anyone else, but it makes me pretty sad that the "modern" way as presented in this article is no longer simple and straightforward and has some severe dependency hell. Not that I'm saying the structure of modern web applications isn't needed and that we haven't advanced. Just that the overhead and knowledge required to set up a modern web application is crazy.…
To quote DevOps Borat: "Cloud is not ready for enterprise if is not integrate with single server running Active Directory."
And with service accounts, API tokens, client certs, partner management of users, etc with OAuth and micro services, I really wish we just used LDAP for everything.
Re: “Hello, (real) world” in PHP in 2017
#110Earlier quoted context omitted.
I know at least three reasons why makefiles are not working well for common use cases. Many people seem unaware of these cases, even though they seem to come up quite often. • make(1) has a hard time rebuilding target files when source files have changed. The problem is that users have to declare the dependencies of a target before the build, but due to file search paths, it can be that dependencies are only known af…
Those don't seem limitations of make itself, but rather the compiler and linker you use with it... The compiler may know paths, the linker may know paths, the shell might, make might, or you can supply them. I've seen and used nested Makefiles before. These things aren't really make things. If I use tcc, Haskell or Go in my Makefile, then they mightn't apply. If you can write it in Bash, you can integrate it into you…
I think that all of these are limitations of not only make(1), but all utilities that expect dependencies to be fully known before a target is built. What makes you think they are not?
How would you solve all three problems I listed using make(1)?