That aside I don't see what's the problem is with cross compiling to an other language. Other than if your writing a compiler why not compile to machine code. Honestly, I think code generators are better than macros.
Use typescript if you want, but I don't really see the issue. There are funny things related to implicit type conversion and some rules produce funny and unintuitive outcomes. These conversion can be very handy on the other sides.
"Math.min() > Math.max()" and they are damn right that this is true!
> Just use PHP 7! There are funny things related to implicit type conversion and some rules produce funny and unintuitive outcomes. These conversion can be very handy on the other sides.
> "PHP_INT_MIN < PHP_INT_MAX" and they are damn right that this is true!
Feeling the perception difference?
It gets a lot of shit because some of the oldest parts have some weird function names or parameter order, but outside of that it's a fantastic language, especially if you stick with php ~5.5 and newer. It's fast, it has a nice package system, and the pepole behind the language are making it better, faster, and more feature complete every day, with standards bodies which includes the biggest players in the space.
IMO languages like Go could learn a thing or 2 from PHP about how to stop worrying about the "best possible choice" and just start giving the language the tools that developers can use to solve real problems.
PHP is backwards compatible almost to a fault, but that doesn't mean you can't use new libraries or frameworks that hide those warts away from you, and that's a MUCH better choice in my opinion than making a significant percentage of the internet incompatible with the latest PHP so that your function arguments for a handful of old function calls can all look the same...
It's not the end of the world, and it is getting better every day, but having to spend the better part of a decade dealing with multiple "main" versions of a language is not something that I want any other languages I use repeating.
And if that means needing to lookup if the function is urlencode or url_encode, well i'm happy to pay the price.
* the shared nothing architecture is extremely easy to reason about (the world begins with a request, and ends once it's out)
* shared-nothing also means it scales stupidly simple. Need to handle more requests? spin up more servers, on an almost linear scale, until your DB can't keep up.
* it's pretty damn fast all things consitered
* the barrier to entry is a fraction as difficult as setting up a backend with java or go or python (although setting up a LAMP-ish stack on windows for development still kind of sucked when i last did it)
* It's probably only second to javascript when it comes to just sheer number and breath of 3rd party packages
* backwards-compatibility is a huge bonus. I can be fairly sure that code I write now is going to keep working with minimal changes for the next decade (for varying definitions of "minimal")
* developers that are comfortable with it are cheap and readily available (although this is changing for the worse lately)
* it's simple. For the most part you don't need to worry about concurrency, about async requests, parallelism, callbacks, etc... Scripts run from the top to the bottom, and they do that every request. Sure, this is a massive drawback as well if you need those features, but PHP's "make it work any way possible" kind of ethos means that there are ways around most of those limitations that work really well... once you stop vomiting over how hacky some of them are in theory.
It's not the most pretty, it's not the fastest, it's not the safest, and it's not the most "pure", but it is a glorious mutt that just keeps on trucking along, and I'm not ashamed to say that I really enjoy the language and I would gladly start a new project in it today if the opportunity arose.
This is my favourite part of PHP. It really is fast. There's no server running all the time like a node or python website, on each web request it has to start up again and rebuild its entire state.
The world starts with a request and ends with the last byte being sent. No worrying about shared state, no worrying about multiple application servers, no worrying about crashes or blocking operations reducing performance for everyone, etc...
It's just so simple that it let's you just focus on building something without worrying about all of the "software engineering" work that is all too often self-inflicted complexity.
[citation needed]
Let the browser be a document viewer.
Failing that, finalize Web Assembly's design to the point that the browser is just yet another general purpose VM.
WebIDL then defines the APIs accessible to any language that gets compiled into Web Assembly.
That would require deploying on at least five wildly incompatible native platforms, and break when they change architecture.
The web is not so much an integration layer as the no-mans-land of the platform lockin wars; it's a space that doesn't "belong" to any one platform owner, which is both its great benefit and great disadvantage.
My C++, JavaScript, Python, Java, .NET code doesn't care which OS it runs on, and the parts that do are very small modules.
If it was easy, we'd be seeing a lot more apps available with Windows/Android/Linux/iOS native ports.
It is easy, just not for those brought up coding for the browser.
Or do you want to imply Electron is more native than even Gtk+?!
With unblockable banners, uninspectable unmodifiable code and other garbage.
The current state of affairs is just perfect balance, webassembly can seriously hurt the user if it ever gets good-enough direct access to DOM.
It is only a matter of having the right tools at hand.
https://www.hex-rays.com/products/ida/
Code might not be 1:1 mappable to original source code, but it is in any case reversible to an higher level description, specially nowadays that re-writable code is no longer allowed due to security exploits.
My issue with those is, they are less sandboxed than JS is. Why would I want to put one-off things all over my disk and system? While I'm willing to install native applications from the package manager for big things I really need, I do not want to do so for simple one-off interactive things, so I really like that I can just do such things in the browser without installing them. Things like simple games, mathematical demonstrations, ...
I think the value of sandboxed self contained interactive apps that can do graphics, input, sound, that run from a link, is tremendous to humanity.
Of course on the opposite side, one problem is the usage of so much JS for simple articles of text and photos. Those would be more pleasant to read if they were just text and photos and nothing more.
QubeOS: heard of it. It's multiple isolated linuxes together essentially. Do you really think one wants to install software on QubeOS to view a mathematical demonstration or a simple game from the web? The issue is simply the effort of installing vs just opening link and viewing it.
I don't know UWP, snap or Flatpak. Do they allow you to open a link and run something interactive immediately without installation? If so, great.
We need something that allows you to open a link and have something interesting running immediately.
Again, it's sad that this same interactivity is also invading simple textual articles that should be just simple plain text, but that is a problem of those articles, not of the existance of JS.
Flatpak is a (promising) work in progress that is copying a lot from web permissions. I look forward to the point when it becomes ubiquitous and secure enough that I would feel comfortable downloading and installing a random, unverified piece of code off the internet from a sketchy looking site. Flatpak is native finally starting to catch up to the web in terms of user-accessible sandboxing. But it's not finished yet, and once it is finished it won't be cross-platform.
QubeOS is great, but nobody uses it because it's hard to use and cumbersome. Same with VMs. You can sandbox an app in a VM and be very happy about it, but your performance will be worse than it would be on the web. Nobody does it because it's not accessible.
Like it or not, the web is the best tradeoff we have right now between flexibility and security. For the most part, users don't need to be suspicious of random links. If someone shares a link on Facebook, you don't need to go look up reviews before you click on the site. It's not like native, you don't spend your entire browsing experience worried about malware.
To be sure there are problems we're still solving (user tracking, phishing, processor control), but native hasn't even gotten to the point of trying to solve those problems yet. Any app you download to your Android phone is going to be able to track you better than a website can - it's just that you'll be so worried about malware that you won't notice. Website operators are arguing about how to prevent phishing for full-screen apps. Linux, Windows, and Mac aren't thinking about stuff like a zone of death yet - a full-screen app in Linux can easily spoof your desktop. Heck, it doesn't even need to be full-screen, just copy the interface and icon of another app including its title-bar if you want to phish someone's email or banking client.
The simple test is this: suppose I paste a completely randomized link to an Android APK, and a completely randomized link to a website. You might have some reservations about clicking/installing them -- but, be honest, which one are you more frightened to interact with?
How many people here would feel comfortable installing a random program that was linked on "Show HN" if they couldn't get access to the source code or verification about what it did beyond 2 or 3 sentences? How many of those same people are fine clicking on a "Show HN" website? The difference is that for the most part web sandboxing actually works.
As someone that develops both native and Web, I feel the pain of catching up with native.
Web Components are finally around the corner, pity it took 20 years to offer what is a mostly a commodity in native UI development since Visual Basic and VBX were designed.
https://amexio.tech/amexio-canvas
Regarding clicking links, those that install anything outside of the store don't have anyone to blame but themselves, and zero day exploits of browsers is a thing.
If you have to worry about a moderator, it isn't sandboxed well enough. Platform moderators are a security failing - you bring them out when you haven't solved the underlying problem. A version of Android with acceptable sandboxing wouldn't need a Play Store. There'd be no downside to just running an APK.
I agree that both native and web applications have a point. But that is the point - both of them are filling in different gaps. In some cases, they're targeting mutually exclusive gaps -- people develop for native to get around browser restrictions. But getting rid of those restrictions makes it easier for native applications to phish and abuse users. And while efforts are being made to introduce sandboxes to native platforms, they are miles behind where they should be -- as evidenced by user's hesitance to venture outside of official sources for software, a problem that most users don't have on the web.
Because of those differing strengths and goals, it's very naive to say that Javascript on the web doesn't play an important, vital role in modern application development. No, it isn't a perfect sandbox. It's just way, way, better than everybody else's.
Maybe that will change in the future. But in the meantime, if you're a user, and you're paranoid about untrusted or proprietary code, you should be encouraging devs to develop web applications instead of native ones. If you're not worried about security, and instead your biggest thing is that you don't like the toolchain, or you don't think the app looks pretty because it doesn't use your GTK theme, then fine. Those are very different concerns. I don't think whether or not someone is fond of web components has anything to do with application security.
This is essentially the idea with WebAssembly. But, for web applications you need security and platform independence, so it's not actual machine code.