Hacker News new | past | comments | ask | show | jobs | submit | notpushkin's comments login

> Reload page, see changes.

This should work in Python, too. With Django, I think you need to use https://pypi.org/project/django-browser-reload/, and rith most other frameworks / WSGI servers just try adding --reload flag.

Edit: Django should wor out of rhe box actually – that package is for refreshing the page in browser.

> Easy to deploy. Upload files, done.

I can see the appeal, but generally you’d want to avoid that (for anything other than quick prototypes, maybe). Set up a CI, push to deploy. This goes for modern PHP as well.

If you want something simple to deploy webapps and know a little Docker, I’ve built a deployment tool you can run on your own VPS: https://lunni.dev/. (Feel free to reach out if you need any help!)


There are of course ways to get "reload page, see results" to work even with Python. After all, computers are touring complete.

But in PHP you have it out of the box. Faster, with less complexity and less resource consumption. And you can use the same setup in development as you can use in production.


Maybe I'm missing something, but PHP is not more efficient in that regard.

When you load a Python page, it is served by an in-memory process. If code is updated, the process is restarted, parsing the code and initialising the application, but it is done only once.

When you load a PHP page, it parses the code and initializes the app for each request. It then tears everything down after the request. There are less wasteful ways (most recent are app servers, just like in Python or other langs), but I'm not sure if those are widely used in local development. Even then, it’s same as Python, Node or pretty much anything else.

And of course, I’m not trying to diss on PHP here – it’s gotten pretty good recently. But reload on change is built in pretty much every app framework nowadays. It works out of the box and is negligibly fast. It’s not a good point to compare.


> When you load a PHP page, it parses the code and initializes the app for each request. It then tears everything down after the request. There are less wasteful ways (most recent are app servers, just like in Python or other langs), but I'm not sure if those are widely used in local development.

There are things like opcode caches that make PHP more efficient transparently, while still feeling to the developer like a reload each time.

There are reliability and development advantages to starting each request from scratch. NO leaks, no state you need worry about.

PHP is very much like serverless.


This is true when you call PHP using CGI or CLI. Then opcode is build, running and thrown away.

But when u are using FCGI or PHP-FPM then you have running process where opcode is cached except on first request where opcode cache is build.


In my experience:

PHP is always blazing fast, with no additional setup to make "Reload page, see results" work.

Python needs additional setup. Either by monitoring the filesystem and pessimistically recompiling the application every time a file changes. Causing resource consumption every time you hit save in your editor. Or by having the web workers that serve the requests die after 1s of inactivity or so. Which makes the next pageview slow again, even if no code changed.

I think PHP's advantage is because of 3 things:

1: Recompiling changed files is built in.

2: With PHP you can set your project up in a way that only the code necessary to answer a single request is updated. With Python and Django, all the code for all requests is updated and even code paths that are actually never used.

3: PHP keeps each file compiled to bytecode in memory and only recompiles files that have been changed. Although you might accomplish something similar in Python if you let it pollute your filesystem with cached bytecode files.


Those are services that depend on Apple servers. If you also make a service, others can’t pirate it (they’ll have to set up their own server, which means it’s not really your service now).

Of course, this only works if you secure your server side properly. I remember using cracked versions of Wolfram Alpha for Android back in high school and those worked like a charm. I don’t think they lose a lot of revenue though.


I don't think it's right to assign blame here to any party other than the authoritarian regime that decides to block the whole CDN.

Yes. However, an experience that’s okay for the user but also super addictve will result in a lot of users.


I love how PonyORM does this for SQL: it’s just Puthon `x for x in ... if ...`.

Of course, if you use the same syntax for Python lists of dicts, you don’t need any library at all.


Neat! Wondering if it's possible to reuse this is OSM?

There is GeckoView on Android: https://mozilla.github.io/geckoview/

On desktop, it used to be available as an ActiveX component and a GTK widget, at least: https://www-archive.mozilla.org/projects/embedding/embedding...

Wine still uses WineGecko as a replacement for IE engine – might also be worth looking into.


> There is GeckoView on Android: https://mozilla.github.io/geckoview/

But sadly on Android the alternative is simply using a Chrome/Blink-powered webview, which is capable enough for most people and importantly comes at a zero APK size hit. So you need to have pretty special needs before including a complete custom browser engine inside your app becomes an attractive proposition.

(Whereas on Windows for example for a very long time the only OS-provided browser engine was IE, so if you needed more advanced web features, you couldn't avoid shipping your own browser engine in your application anyway.)


Hmm, you’re right, I think GeckoView is “marketed” specifically for making browsers:

> However, Android’s WebView is not really intended for building browsers, and hence, many advanced Web APIs are disabled. Furthermore, it is also a moving target: different phones might have different versions of WebView, all of which your app has to support.

It might still be an okay choice for an application shell sometimes (e.g. if you use a web API that is not supported by WebView and no polyfill is readily available for Cordova/Capacitor).


This could be a nice starting point for such a system though. Is there a logging-only mode?

Yeah. I mean, technically if you walk into Adobe’s office with $1M in cash, they might make an exception, but that isn’t exactly practical.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: