What's the JS equivalent of "place an index.php file in a folder to deploy"?

What's the JS FOSS equivalent of ProcessWire as a CMF + CMS?

What's the JS equivalent to e.g. DreamHost and other drag + drop hosts?

(Legitimately curious, and I'm mainly inquiring after equivalents-for...better-thans would definitely be interesting)

People always seem to come up with the argument that you can drop an index.php in a folder and be done with it. Only nobody uses php that way since decades.

Modern php code uses Frameworks, Package mangers, opcode caching, and application servers. It’s just that other languages don’t carry all the cruft php has in its heritage…

The drop index.php into a folder is the only way I use PHP now.

Back when I was building applications in PHP it was all frameworks. package managers, op code caching, etc. But I no longer do PHP development but for my own personal websites I still use PHP but in that most minimal form.

Exactly, if one is not developing PHP for the enterprise (maybe some non-enterprise simple projects still use opcodes though? lol), it's silly not to leverage index.php for all it's worth :-)

So where is the hyper-simple JS equivalent for that class of non-enterprise projects, is what I wonder...the enterprise stuff has always been heavy and loads projects down with maintenance debt.

The equivalent for JS is just an HTML file.

There are projects between hobby users and Facebook, believe it or not :-)

I actually like using a reliable package manager, a wide ecosystem of good packages, and modern language features. There is nothing "heavy" about modern PHP, unless you want it to.

Exactly! Those languages are working on their own cruft!

> Modern php code uses Frameworks, Package mangers, opcode caching, and application servers.

How do these change the way you can deploy PHP files by simply uploading them?

For frameworks, all you do is run a single command to install.

If you mean JS package managers, that's agnostic to what language you use.

Opcode caching doesn't require anything special from deployment point of view and I don't see a need for app server for PHP.

It changes deployment because you need to flush the opcache after deploying new code, for example; you need to install composer packages, restart the app server (if you use one), etc. I mean obviously you still upload files, but there are more steps involved in a proper deployment.

Once you start getting into zero-downtime deployments, you'll quickly see the need for both application servers like Swoole or RoadRunner, as well as strategies that don't leave requests in the air with half the code from the old version and the other half with the new one.

Let HackerNews hobby programmers snark all they want, those are very real problems with very real solutions.

I mean... using a symlink to the deployment root gives a quick atomic swap. You update the link, then reload the server config, no downtime and no partial deployments during a request. This also solves for the opcache freshness as well if I recall correctly. (It's been a little bit since I've done any PHP work)

Of course, you can do that. It’s the strategy Etsy used, for example. Point still standing, that makes deployments definitely more complex than just „uploading a file“.

And then again, you’ll end up wondering why your servers should waste cycles upon cycles for executing the same bootstrap code over and over again, if they could instead only do that once, keep the app in memory, and only execute the request handling code… and just like that, you’ll end up with Octane, or Swoole, or what-have-you.

What I like about PHP is that it's not just batteries-included, it's "Entire Batteries Plus Store Included". The standard library is huge, documented, and also features 15 years of accumulated notes and discussion right on php.net.

The tendency to have a npm package for everything is overwhelming because you end up with choice paralysis and risk on picking "Oh, you picked CSV-to-array library #823, it's the buggy/insecure/unmaintained one."

File reading excluded, CSV to array is like two generator functions and a main, even with rudimentary schema support. No reason to add a dependency at all.

> Only nobody uses php that way since decades.

… in your echo chamber. I know first hand of multiple very large corps doing that (one of them being a bank and this is their payment api) and very many smaller shops. Sure, we recommend against it, but saying it’s decades ago like that is nonsense; many people do this because it’s convenient.

Well "place an index.php file in a folder to deploy" is a lot of server (maybe Apache / PHP) running to support that.

Node typically IS the server. So, you could install express and have a simple web server listening on a port and serving up html or json in about 5 lines of code. Unlike PHP Node is not, in itself, a templating language. So if you want to render HTML pages you'd also need to install something like EJS, but generally node servers are just serving up JSON API, and your frontend would be some frontend framework (React, angular, vue). Although all of that is trending back the other way with NextJS the old is new again and server-side rendering is the hotness again.

Another option is to use a framework like NestJS. With that you do

    # install the nest cli (only needed for starting a new project)
    npm i -g @nestjs/cli

    # scaffolds a new project
    nest new project-name

    cd project-name

    # node server is now running on port 3000
    npm start

For easy deploy. That was kinda Heroku's thing. You just "git push" a node project and it magically knows how to deploy it, but Heroku got bought by Sales Force and murdered from my understanding. There are a lot of alternatives though. AWS, Azure, Google, CloudFlare, Digital Ocean, etc, etc all have similar offerings where you just push a node project to git and it deploys automagically.

Alternatively you can use AWS Lambda / Azure functions (or a dozen other "serverless" solutions) and you can just drop js files (functions) and they run on demand.

For a ProcessWire alternative there are a ton of options. A few I've seen are: Ghost, ButterCMS, Strapi

Thanks for the info!

> AWS, Azure, Google, CloudFlare, Digital Ocean, etc

I'm always curious to know if there are more casual options in this space, for non-earthshaking projects. Maybe more like how DO was at the beginning?

Handful of great new hosts I’ve seen pop up:

Render.com, Fly.io, northflank. And I actually like AWS lambdas, so great option for me is SST.dev, which wraps AWS CDK, and provides an actual live development workflow with actual AWS resources.

I’ve been using fly.io for little things and it’s remarkably nice and easy to use. I can’t vouch for large scale projects, but for little things you want to experiment with it’s a joy.

Do you really think the inability to create anything but an index.php file is the bottleneck?

Those people just use drop-in tools now which are better than custom applications for a large portion of standard use cases.

Bottleneck? Just asking what's the JS equivalent in convenience for deploying a simple project.

It doesn't need to even look like index.php, just needs to be as convenient, ideally?

Drop-in tools? Examples? I was using PHP drop-in tools back in 2004 but I'm not sure if that's what you mean.

With node, install express, and run `node index.js` and you have a full blown server.

Express and it's spiritual successors are the node "hello world" answers you're after, I think.

For JS, you need to setup a listener like PM2 and point it at the folder, but once that is done, you can drag and drop and index.js file into place and it'll all work as expected.

Oh that's easy - just install 10 insecure npm packages that each install another 10 npm packages (some of which are even maintained!) then make sure you remember to bundle it up in a nice, heavy electron wrapper. Then you're all ready to distribute it via some random App Store - just don't forget to charge a monthly subscription while you're at it. /s

Don't do this to me, I maintained one of these projects years ago, and am still somehow billed $0.30 a month for the privilege of the original dev having used Amazon tools for it :D

The pain is real! Speaking of Amazon - AWS CDK is promoting lots of terrible practises mostly built on barely supportable TS/JS, it's so... so terrible.

I've been doing web development since before the <table> tag was introduced.

> just install 10 insecure npm packages that each install another 10 npm packages

I still don't understand why companies are fine with this.

At my last job, even principal and staff level developers needed every Windows or Mac application install vetted by IT. We had real time system monitoring on all employee workstations that ate up half the RAM and CPU resources and constantly kicked us off the VPN for even the slightest quirk (including the CPU redlining due to scanning).

But npm dependencies? Nothing. Install whatever you want and push it to production.

This is an S&P 500 company that deals with tons of PII.

Because the working part of an organisation such as the one you describe tries to continually optimize away these restrictions. NPM (et al) is a good way to obfuscate the fact you're pulling unknown code to get shit done and processes haven't caught up yet.

I'm not saying this is good, but the reality with these company-internal restrictions is, that the most productive people find ways around them and are rewarded for it.

An html file with a <script> tag

I see we both read the same JS Game Dev book...

Exactly this. It's the perfect approach for teaching people the basics of how to use my JS library - https://scrawl-v8.rikweb.org.uk/learn/first-lesson/

What is the PHP equivalent of writing your front end and back end in the same language so you can share libraries and data and not have to switch gears between two different languages each time you look up or down the stack?

There is a HUGE advantage to using the same language in the browser and on the server, and PHP isn't ever going to displace JavaScript in the browser. So JavaScript it is. That ship sailed a LONG time ago.

I like switching gears, I truly don’t find it an advantage using the language for both. Have separate languages makes the distinction between backend world and front end world very clear. Also the backend code is mostly data manipulation and the front end code is mostly rendering so there is very little overlap in similar functions for both. The separation helps keep things tidy in my brain.

I much prefer not having to write JavaScript everywhere, not every problem is a nail and not every solution requires a hammer.

Don't you think it would be better to write everything in HTML? It wouldn't be too hard to make it Turing complete. This way your server is written in HTML, your browser is written in HTML, no more switching gears.

I believe you'll need to compile the PHP runtime itself with emscripten, since LLVM won't take PHP code, but PHP compiled to wasm will!

As long time Java, .NET and C++ developer, this is oversold, beyond some form validation there is hardly any value sharing code.

And in what concerns validation, it can be automated on most frameworks, which has to be done on server side anyway due to security concerns.

The value is really not in sharing code, but rather sharing developers. Instead of having to assemble and keep happy a diverse group of specialized professionals, you can just hire and fire a bunch of cheap JS folks, who are easily replaceable.

Offshoring already takes care of the cheap developers part.

When people get what is peanuts in local currency of the owner company, whatever they are using doesn't matter and most sweet shops are experts in everything.

I can also tell that at the level I work on, salaries are the same regardless of FE, BE, DevOps, ...., specially because no one has a single role.

toyg makes a good point about sharing developers, but also sharing code is important, especially for efficient server side rendering, with view code that runs on both the server and the browser.

The point is it takes fewer people (or even the same person) to write less code (instead of writing everything twice, then trying to keep them in sync forever).

There's a fascinating deep discussion about SveltKit and other frameworks here:

Reacting To Web Hot Takes from Rich Harris - SVELTE STUFF

https://www.youtube.com/watch?v=JGuUY7dZhWs

Java and .NET have been doing efficient server side rendering for several decades now.

LiveWire?

I have a hobby app that is index.html and I just manually add <script> tags to load libraries. No build step, I just use GitHub to cloudFlare pages to host.

It’s funny that it reads like some novel approach, but a script tag within an html page is what JavaScript is and was designed to be.

I would stick with Laravel or something like that if I were you. The rest is good for your resume, but if you don’t need that, I would forgo the misery that is js/ts dev.

Oh, processwire looks interesting, first time hearing about it

> What's the JS equivalent of "place an index.php file in a folder to deploy"?

My favorite way to do this is to add a custom script to package.json like:

"start": "pm2 start index.js --name myapp --watch"

Any file change will reload the application and if it crashes it will be restarted. So just scp/rsync files if that's your desired workflow.

In my experience, it's far easier and faster than setting up nginx, apache, fpm, etc, etc.

No, languages simply matter much less than they once did due to widespread adoption of best practices and good design.

The tooling around languages matters much more.

C++ isn't still popular because it's the best language.

Only real reason I'd always pick PHP over JS is not because I love PHP, but because Laravel is better than any node framework.

While you may pick, most developers do not. You are not the most developers, as you are special and probably much more talented.

They pick JS because they know the language best and are more productive in it than in Laravel. There is nothing Laravel can do about it - being best is not going to change the direction, because the limiting factor is the knowledge of programming languages of most of developers.

They picked JS for the server because they have a choice in what languages they can run on the server, but they don't have a choice about what languages they can run in the browser, so JavaScript it is.

There are HUGE advantages and efficiencies to using the same language in the browser and the server.

Most developers are (rightfully) lazy and simply don't want to learn and juggle two different languages in two different places, when they can use simply one language everywhere.

For example, when switching between PHP and JavaScript, you have to remember that the ?: ternary conditional operator in PHP has idiotic left-associativity, so you have to use extra parenthesis to disambiguate it, while the identical looking ?: ternary operator in JavaScript and all other languages has sane right-associativity.

"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests." -Rausmu Lerdorf

"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf

"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf

You don't have to remember that, any IDE will yell at you.

I don't find it inconvenient to write PHP or JS syntax, it's completely trivial for a professional.

Don't be such an apologist for terrible careless programming language design, expecting professional programmers to tolerate IDE's "yelling at them" about pointless language design flaws and using terribly designed languages that were mindlessly thrown together by anti-intellectual amateurs like Rasmus Lerdorf, a self proclaimed "not a real programmer", who doesn't even know the difference between left and right associativity, or even "care about this crap at all".

"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf

"There are people who actually like programming. I don't understand why they like programming." -Rasmus Lerdorf

"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests." -Rasmus Lerdorf

"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf

"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." - Jamie Zawinski

On the other hand, Anders Hejlsberg is a highly skilled and experienced professional programming language designer who actually knows what he's doing, and LIKES programming. And as a professional programmer who's been writing lots of code since the early 1980's, I much prefer and enjoy using his well designed IDEs and programming languages like Turbo Pascal, Delphi, C#, and TypeScript, to mindlessly hacked together pieces of shit like PHP.

And you're totally missing the point about the advantages of using one programming language on both the client an server side, sharing libraries, data, APIs, mental energy, and effort.

If you were really a professional programmer, you wouldn't be stuck in a rut using and apologizing for PHP, because you would be capable of learning so many other vastly superior and more powerful programming languages than PHP, and you wouldn't have to waste your time and mental effort rationalizing and making excuses, remembering to avoid so many unforced foot guns and idiotic bad design fractals, and carefully and defensively working around all of its flaws, while getting "yelled at by your IDE" all the time, instead of actually spending your finite time and energy solving problems.

PHP: a fractal of bad design:

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

You're probably a joy to work with, huh?

You've got be more flexible than this, come on.

Why thank you for the complement! Speaking of the Joy of Programming:

Bill Joy’s Law: 2^(Year-1984) Million Instructions per Second

https://donhopkins.medium.com/bill-joys-law-2-year-1984-mill...

"The peak computer speed doubles each year and thus is given by a simple function of time. Specifically, S = 2^(Year-1984), in which S is the peak computer speed attained during each year, expressed in MIPS." -Wikipedia, Joy’s law (computing)

"C++++-= is the new language that is a little more than C++ and a lot less." -Bill Joy

"You can't prove anything about a program written in C or FORTRAN. C is PEEK and POKE with syntactic sugar." -Bill Joy

"You can drive a car by looking in the rear view mirror as long as nothing is ahead of you. Not enough software professionals are engaged in forward thinking." -Bill Joy

“Java is C++ without the guns, knives, and clubs.” -James Gosling

A Conversation with Language Creators: Guido, James, Anders and Larry [video]

https://news.ycombinator.com/item?id=19568378

https://www.youtube.com/watch?v=csL8DLXGNlU

"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg

"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg

Andrew Hejlsberg:

>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.

>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.

>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.

>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.

>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".

>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.

>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.

>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.

"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up with the right keyword, because all the interesting keywords are already very popular method names for other forms of pattern matching." -Guido van Rossum

James Gosling wants to punch the "Real Men Use VI" people. "I think IDEs make language developers lazy." -Larry Wall

"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling

https://news.ycombinator.com/item?id=19568860

>DonHopkins on April 4, 2019 | root | parent | next [–]

>Anders Hejlsberg also made the point that types are documentation.

>Programming language design is user interface design because programmers are programming language users.

>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.

>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)

We have an embarrassment of floss riches today. No need to support a poor design.

That's exactly Jeff Atwood's point, which I quoted above (and will repeat here):

"From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious." -Jeff Atwood

https://blog.codinghorror.com/the-php-singularity/

Leaning hard into the IDE (or ChatGPT these days) because your language design is flawed is a hella/totally stereotypical "West Coast" thing to do, as described in "Evolution of Lisp", "Worse is Better", and "History of T", and exemplified by Interlisp and Warren Teitelman's "pervasive philosophy of user interface design" and implementation of "DWIM".

https://en.wikipedia.org/wiki/DWIM

https://www.techfak.uni-bielefeld.de/~joern/jargon/DWIM.HTML

https://escholarship.org/uc/item/6492j904

If your language isn't terribly designed, then your IDE doesn't have to be such a complex non-deterministic Rube Goldberg machine, papering over the languages flaws, haphazardly guessing about your intent, "yelling at you" all the time about potential foot-guns and misunderstandings.

As you might guess, I'm firmly in the "East Coast" MacLisp / Emacs camp, because that's what I learned to program in the 80's. I can't stand most IDEs (except for the original Lisp Machines, and Emacs of course), especially when they keep popping up hyperactive completion menus that steal the keyboard input focus and spew paragraphs of unexpected boilerplate diarrhea into my buffer whenever I dare to type ahead quickly and hit return.

But my point is that you can have and should demand the best of both coasts, unless you start off with a Shitty West Coast Programming Language or a Shitty East Coast IDE.

(Of course those philosophies are no longer bound to the geographical coasts they're named after, that's just how those papers describe their origin.)

Jeff Atwood's point an my point is that we should demand both well designed programming languages AND well designed IDEs, not make excuses for and paper over the flaws of shitty ones.

There are historic existence proofs, like Lisp Machines and Smalltalk, and we should be able to do much better now, instead of getting stuck in the past with Lisp or PHP.

I mentioned the East/West Coast dichotomy in the discussion about the conversation between Guido, James, Anders and Larry:

https://news.ycombinator.com/item?id=19568860

>DonHopkins on April 4, 2019 | parent | context | favorite | on: A Conversation with Language Creators: Guido, Jame...

>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.

>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.

>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)

More discussion of West Coast -vs- East Coast language design:

Evolution of Lisp:

https://redirect.cs.umbc.edu/courses/331/papers/Evolution-of...

Worse is Better:

https://dreamsongs.com/WorseIsBetter.html

History of T:

http://www.paulgraham.com/thist.html?viewfullsite=1

The Interlisp Programming Environment

http://www.ics.uci.edu/~andre/ics228s2006/teitelmanmasinter....

https://news.ycombinator.com/item?id=5966328

https://news.ycombinator.com/item?id=5966399

>gruseom on June 30, 2013 | parent | context | favorite | on: The Interlisp Programming Environment (1981) [pdf]

>Interlisp was the so-called "west coast" Lisp that emphasized an interactive programming environment and in retrospect looks more like a hybrid between Smalltalk and Lisp than modern Lisp implementations. It was developed at PARC for a while. I don't know if there was cross-pollination between Interlisp and Smalltalk or if the similarity was a zeitgeist thing.

>This article talks about the design values of the system and communicates the flavour of what a Smalltalkish Lisp would have been like.

>As someone who's only read about this, I'd be interested in hearing from people who actually used it.

Evidently Lerdorf wants to be perceived as aloof and 2school4skool. The quotes sound rather performative.

Professional programmers simply get paid to write code. Any further illusions one may have about them are personal and subjective.

Also, server side JS is an absolute hard no for many, many server side devs who became server side devs after suffering with JS as full stack devs.

With GPT, I don't really find that I am more "productive" in one scripting language or another given that it has the ability to perfectly translate between them on the fly.

Perfectly? Oh really? Have you tried actually reading the code you're copying and pasting from ChatGPT into production? Are you actually letting it do all your architectural design and security auditing for you, too?

If ChatGPT is already perfectly solving all of your programming problems, then you should learn a lot more about programing, design, architecture, and security, so you can take on more challenging projects, and actually design decent APIs and architectures, instead of just paint-by-number monkey coding, and produce better more thoughtful designs and code than an LLM, because your job is already obsolete.

If you think the current crop of AI does the translation “perfectly”, you’re going to have a bad time. Or maybe not you, but your customers, client, or the poor chap that replaces you is going to have something blow up in their faces.

"From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious." -Jeff Atwood

https://blog.codinghorror.com/the-php-singularity/

It's also possible PHP isn't a 'problem' any more. Perhaps even some alternatives that once were better are now worse.

That's why I keep using PHP in my projects personally. Laravel is just so damn pleasant to work with.

I am curious what are the radical changes you are thinking about that PHP needs.

javascript has the advantage that front and backend can share code, but as a language it's much worse. php at least has been able to break backwards compat to fix its worst design mistakes, and natively has typing

There are few factors why PHP popularity is decreasing, not because it is really bad. But very often other languages build its popularity on promoting how "bad" is PHP. It is also no longer fashionable as it was in the beginning, but other language promoted as such. And more.. So, I think, rebranding and good marketing could help here.

Php got complicated. So it’s value is decreasing.

What are the better tools? Are you suggesting JavaScript is better? Exactly how?