Comment by wwweston
5 days ago
Speaking as someone who has done this back in the early wild days of the web:
* if what you're vending is the software instead of the service (not what people usually do now, but there was a time), then this approach does provide for some obfuscation of IP and various secrets.
* for some demand/resource profiles, CPU & memory issues are a lot easier to run into. The one I experienced with this project was targeting a serious e-commerce product to the context of 20-30 year old shared hosting environments (again, not what people would do now), but there may be different situational niches today.
* familiarity. Sometimes you use what you know. And in the late 90s today's most popular web languages were still years away from being the convenient platform they'd become. The other popular options were Perl, maybe Java, possibly ColdFusion/VB/PHP.
That said, you're correct: memory management was a pain, and by 2005 or so it was pretty clear that programmer cycles were as or more valuable than CPU and respectable frameworks were starting to coalesce in languages much better suited for string manipulation, so the ROI was not great. And of course, today you have other systems languages available like Go and Rust...
> if what you're vending is the software instead of the service (not what people usually do now, but there was a time)
I'm very curious what this means. Can you give an example?
Giving the client the executable to run, not running it for them. This means you can't hide the artifact from the client; for an interpreted language, this means recovery of the source code would be much easier than with a compiled output.
That being said, it's still possible to reverse engineer the code; it just makes it harder.
You could also run a limited demo of your desktop application in a browser, where people have to pay to get access to the full thing.