re: Javascript needs competition on the front end. Thoughts? VIEW POST

FULL DISCUSSION
 

Javascript don't need competition on the frontend, it needs more stricter strict modes. Explained: when static types become a thing, having a higher strict mode should throw an exception when someone not order argument and return types for it's functions explicitely.

But this is highly an aesthetic choice (what newer features we want to code in) and I don't think this will ever come through any commitees. But it would be really nice, just like when you compile your C++ code with -std=c++1z flag, except this solution punish you if you want to use older standards.

 

Some people don't like PHP, so they go to Ruby or Go or Python, some people hate Javascript but they have nowhere to go essentially. Do you see the problem now?

 

I thinking realistically about this JS alternatives: it's never gonna happen, that W3C will pick up another language for a browser standard, never, ever. So, do you want a NPAPI solution like what Java did in the last decades? That was great, isn't it? Especially if you are a sysadmin, managing 20+ workstations in a company with different OS + different governmental webapps which requires different java versions to run, with different settings? Feel the pain that sysadmins feel, I also lived in this hell. Upps, luckily that's not possible anymore, because every major browsers, including Firefox, Chrome, Opera, Edge are blocked NPAPI execution and not just that, they removed it from their browsers, so in the last couple of months NOT possible to run Java on the browser anymore. Because, you know, many viruses downloaded into the computers by Java. It was the hacker heavon to have an user installed execution environment on lots of enterprise PCs (JS runs in the browser VM), where you can send any payload you want, after the user accepted the execution. Good bye Java, we will never mis you. But what the government did in this case? Nothing! We run all of these important apps for work in Internet Explorer 11. :) What will happen if Microsoft will release an update to Windows 10, for remove NPAPI support from IE11 as well? Well, probably in this case, every mayor office or government institution, including police, hospitals, army, etc. won't be allowed to update their windows, until not comes a webapp rewrite (which is possible within 2-3 years, in the hurry they work...). Nice, new world isn't it? Thanks to Java and it's never-becoming-a-real-standard execution model. :) Alternative solution is to use an old Firefox/Chrome version as well (I use Firefox 52 ESR in one case, with turned off updating), but luckily, some government java program won't run any other browser, only IE11...

I would be the happiest person if I can program client-side apps using Go (natively integrated into the browser), but as far as Google can implement in Chrome, this still not become a standard by W3C, so it's not worth bothering. Eventually we will have a Webassembly compiler for most of the languages, but at it's current state, without active projects / frameworks, no one using it for everyday tasks, like a client-side rendering library (and I think that's not even possible right now).

The main reason would be to use webassembly for me on the client-side is to protect the source code. If you not program in 3D and you only want to write a client-side 2D apps (like with React, Vue), execution performance is really not that important for companies, instead what is important is product to market ratio. The payload size also important, but I don't believe that an extensive framework (which we didn't saw yet), will be much smaller size in binary then a minified Preact project.

 

But now they can go and use Elm, Purescript, ReasonML... or maybe something else.

These languages compiled back to Javascript, just like Typescript. I don't see the point to use something else then ES2018 + Flow + Babel or Typescript + Babel. At the end of the day, all of those important type safety features or syntactic sugar will be stripped out from your code, leaving only a major browser compatible, old standard javascript with slightly optimized code.

Actually, there's somewhere a Flow library (sorry, I forget the name), which compiles to client side as well, to not strip out the type checking on the client side (I don't know unfortunately, Elm, Purescript or ReasonML have such feature).

Having another W3C standard language on the client side means that the browsers implement it's VM to execute, meaning don't have to transpile back to Javascript.

code of conduct - report abuse