apt-get install npm && npm install bower && bower install ...
Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
It's still squarely in early adopter territory and the documentation is woeful, but if you're willing to put up with that it really does feel like the "one true package manager" I've been searching for. I've been using it at work and while the setup was painful and some things are still awkward (ie statically linking Haskell executables), it's been incredible overall. The up-front work in learning the system and getting it running has paid off already, and it'll pay off even more as I continue using Nix for other things.
Because Makefiles are quite limiting.
> Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
Because that would be OS specific.
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.
Turtles all the way down!
1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion.
2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework.
3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that.
4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework.
5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass.
6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline.
7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP.
8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks.
9. Wow, you need so many javascript and PHP libraries! Let's use a package manager.
10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up.
We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot.
Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices).
Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.
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).
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.
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.
I am working on a larger .NET web application in my day job... and it requires things like.. Typescript + typings files, Webpack/Gulp/Grunt/etc. and therefore Node.js and NPM, NuGet, .NET Framework, onion architecture, front-end framework (Angular, or React, or..), Entity Framework, multiple databases, web services/web API, ASP.NET MVC.. I mean, it's just crazy if you step back and think about it.
Sometimes I long for the simpler "bad old days"? Oh well, back to my enterprise single page application framework-laden monster.
DISCLAIMER: I know we're better off today in many ways, and maybe I'm just getting older and the cognitive load is higher.
All long as all the tools and pipelines work flawlessly it's painless.
As soon as something goes wrong, if you are not a specialist or have a deep understanding of the inner-working of all these it actually hinders productivity.
What if Webpack doesn't work as expected because you mis-configured it? what if there is a bug in AngularJS and you're not capable of fixing it yourself? What if Entity framework doesn't support a specific use case/feature of your DB?
While in a professional environment implementing the domain is already a lot of work and people want the rest to be coded fast by using ready-made solutions, each new component, framework should be carefully vetted, adding a new framework or library shouldn't become a reflex.
If you work on web apps, you absolutely owe it to yourself to understand HTTP and CGI. The one page I'd recommend to quickly grok CGI is http://www.oreilly.com/openbook/cgi/ch01_04.html . Also learn how to use cURL and understand everything that is happening inside the Network tab of Chrome or Firefox dev tools (they're very similar these days). Set up MITMProxy between your proxy server and your apache2/nginx, put it into reverse proxy mode and point the proxy at it, then it at httpd, and understand what you're seeing.
I don't have a good link for HTTP but I promise it'll help a ton with debugging things and generally having a sense of what's going on at every level.
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.
Specifically, is there a simple example showing LDAP integration (or file upload/catcher). If not even that is documented and there is no example, the framework is likely not ready for usage. Seriously, why go thru all the hassle of starting a framework and not even cover basic use cases?
(in php/asp.net/python you should write something in backend for serve javascript responses as is it in rails with files .js.erb)
Is the cost really that high to warrant this?
But if the idea of a "hello world" is to learn the basic boilerplate that you'll need before you start implementing real features, unfortunately for us web developers, this quite accurately represents the minimum before we can even start implementing business logic. With the baseline expectation for a lot of modern SPA-type applications including caching scripts, client-side routing, server-side rendering, working offline, supporting IE9 to iOS to Firefox and all the quirks in between, etc it really is getting to this point.
I wish like nothing else that most of this could come out of the box so "hello world" really was a one-liner, but that just doesn't seem to be the reality that 2017 webapps live in.
From that perspective, you would expect the tooling and stack to be complex. We really are doing way way more than we were in the "old days." "Write once run everywhere" has arrived and we're doing it, it's just not as simple as it sounds.
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 programs can even begin to reach. And it's not exactly simple to setup that environment from scratch either.
Simply put: we forgot how to be engineers (the right solution for the problem). We are all Zuckergified into the fucking hype. Aren't we? We forgot that it is WE the experts that should tell clients how to solve their damn problems not just echo some buzz words so we get the damn contracts.
This post is NOT satire. It is the very state of current affairs.
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.
Truly look at the PHP code in this article, the JS dependency hell here and in the recent JS article.
Look at the code. At the environment. At the libraries.
Who isn’t reminded of what Java looked like years ago?
We’ve come full circle.
------------------------
To build software of a certain scale, certain technology, patterns, etc are required. These are what we see here again – ORMs, complex dependency systems, complicated frameworks, etc.
One might wonder why people even write PHP and JS nowadays, if Java is still faster, JS and PHP are now equally complicated, and Java ported all of the advantages of the others.
And, in fact, the Play Framework (which supports Java and Scala) is growing.
At the same time, Google’s go is copying the same mistakes Java did in the beginning, with almost all new methods in the standard library taking interface{} – the equivalent of void* or Object, and a simplistic typesystem.
------------------------
That influences the way the entire language goes.
I hope it's a joke...
"That’s it, we can run it now. “Hello, world!” is displayed on the screen. It looks almost like the result of <?php echo «hello, world» ?>"
$ echo 'Hello World!'
All (or at least most) of this seems overkill if you just want to print out 'hello world'. But it makes total sense if you want to do a little more complex stuff.
It kind of reminds me of the state of Linux in the mid-late 90s, where you'd have "install fests" with a roomful of 25 people and it took a whole day to get Linux installed on your machine (and your sound still didn't work, that took another afternoon).
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 of PHP — it’s easy for beginners. To my mind, this argument isn’t valid anymore, which is exactly what I was trying to say in this article.
The notion of PHP as a beginner-friendly language has in my opinion been a harmful one for a while now. There are still people writing old school PHP apps, and there is the (mildly displeasing) wordpress ecosystem. But for anything serious, Symfony is invaluable. And the gap between old school PHP to modern PHP is almost the same as the one between old school PHP and Java/Spring/Hibernate, which is kind of what Symfony/Doctrine is cloning anyway. Plus if you do Java, you don't get the stigma of being in the same category as a professional wordpress template tweaker.
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.
Links, text boxes, selects, radios, checkboxes, buttons, forms, and content.
If I'm creating a static page I would just create a html page (no php required)
Of course it's complex when you introduce complexity. So is anything by definition. If you don't want to do complex things, you're fine. But if you want to have a database, have a framework abstract away the truly dangerous and boring shit, use a modern, type-safe version of Javascript, write CSS in something approaching a maintainable fashion, and deliver a responsive, reactive site, you'll have to do something like this, regardless of language.
Also, the author neglected to set up database migrations, to say nothing of a Dockerfile.
--- 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 of PHP — it’s easy for beginners. To my mind, this argument isn’t valid anymore, which is exactly what I was trying to say in this article. A novice programmer will have to learn lots of new things, as well as write tons of configs: frameworks (very similar to java frameworks), databases, linux, shminux, JavaScript with all its baggage, http-protocol, various tooling and many more. Even if it’s not SPA.
Hello world!
People forget PHP is still a template language for the web.
It's still is easier AND cheaper to deploy a Hello World in PHP than a Hello World in any other language. You can get a cheap Apache/PHP hosting for $2/month, use SFTP a get a working app in minutes. The default PHP distribution comes with a lot of extensions.
The problem is that PHP doesn't help a beginner graduate from a basic webpage to a secure and robust application without having to download a complex framework and meddle with configuration files. IMHO by the time you are tempted to use Symfony you might switch to Java or ASP.net directly.
If PHP was really beginner oriented, it would actually do everything it could to use the most secure defaults for every feature, like templating, or sessions.
Microsoft attempted to do that with WebPages, which is kinda what PHP should have been if it was really intended for beginners. WebPages mostly use secure defaults. While it doesn't prevent spaghetti code it makes having to rely on a complex framework unnecessary.
The point is that if you're 13 years old, somewhat crafty, and just want to make a website that puts text on dank memes using ImageMagick to impress your friends, PHP and $3/month hosting with a friendly alligator that you can show to your mom to get her to put her CC in without thinking you'll get hauled off by a black helicopter...will get you to done quickly without having to read a foot of O'Reilly books, 20 DigitalOcean tutorials, 57 Wikipedia pages, and 118 StackOverflow answers.
Spaghetti PHP on shared hosting written by copy/pasting comments from the PHP docs and SO is a fantastic gateway drug for teens who end up being great developers. I love it.
Default in PHP is to output the bare text. Unless you wrap it in special markup '<?php'. That's an unique feature in the top languages.
Hello World
Of course this would be broken HTML but first it displays, and second you could configure the web server to send
Content-Type: text/plain
I run a search engine. It is big enough that it needs drives, caches, firewalls, VMs etc.
The front end is php. No classes, no phpadmin, etc. Just pure vanilla php.
Sometimes I tail /var access logs. People try all kinds of urls routinely fishing for weaknesses.
It's 2017. It is slow to code and keep the attack surface that minimal.
0 intrusions so far.
No one even writes javascript anymore, they compile it from Haskell or whatever. That's how serious it is.
That first simple output IMO is critical for retention and engaging the language knowing exactly what you're going to get by looking at dirt simple code like echo hello world; at least it was for me as PHP was one of my very first languages
The intent is well meaning in this "real world" hello world, but I feel like taking the espoused mentality in the opening paragraph, one is throwing construction tools at a toddler who asked for a box of legos for christmas.
Curious what others think
https://en.wikipedia.org/wiki/Rule_of_least_power
If you enjoy overengineered code, check:
- Fizzbuzz Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- Fizzbuzz in Tensorflow: https://github.com/joelgrus/fizz-buzz-tensorflow/blob/master...
Bullshit, especially on the PHP / backend side. It's 2017, we should know how to avoid over engineering simple things.
I love PHP and it's still my main language, but the reason so many projects never get completed is because of this. Really I should just accept that for an MVP, Laravel and a static front end with some old school jQuery where required is fine.
Maybe wasn't the best solution but it worked...and was fast too.
The good old days kind of weren't that good. The simplicity of bare PHP was great for cowboying up sites in a hurry, but it's not a system that handles complexity well.
Granted the person who wrote it obviously didn't care but that setup was awful for anything of any size.
If you use some include() in php, you can avoid long php/html pages...
What I really miss is that was very fast "GET SHIT DONE" with PHP.
Who is this Holly and why are we starting a war over her?
All this talk about "Enterprise over engineering", is all this needed, tool-overload-hell, etc... and I just can't stop thinking about Holly and how to stop the war over her...
Idk, maybe it's a boon for some, but I've tried it and don't really see the big appeal...except for Meteor, because if I'm writing both my UI and API in the same * language, why in the would I need to write my models in both places and maintain them separately. But meteor has problems too, I just always thought it was neat way of doing something that would only be possible ("easily") when using the same lang on both sides.