On Wednesday, 29 July 2015 at 17:25:17 UTC, Etienne wrote:
> I can't share source but the idea is simple. You configure a DNS subdomain my.domain.com => 127.0.0.1, and test that address with javascript when a logins to the public website, if it doesn't work you show a message "plugin required". The user downloads the plugin and executes it, an elevation request is asked once for the exec to copy itself to program files and to register the service/daemon or open it (the only user interaction required!), and then the page is opened in a new browser window (borderless) or he can also refresh the page. The plugin's reverse proxy delivers the AngularJs app that uses Json models to populate the templates.

You can even get rid of the download popup by having a hosting daemon, which your JS instructs to download and run your web-app. It can do all the virtual-host routing, updating, what-not.

It does still requires an install, but only once.

A huge security risk if not properly sandboxed though.

On Thursday, 30 July 2015 at 05:50:56 UTC, Ola Fosheim Gr wrote:
> On Thursday, 30 July 2015 at 03:56:25 UTC, Brandon Ragland wrote:
>> Regarding JavaScript being slower, this benchmark[1] seems to indicate that on average, JavaScript on V8 is at-least 4X slower than a g++ compiled native package. It also appears to use anywhere from 2-4X as much memory.
>
> I think speed optimized javascript is at 50% of regular non-SIMD C. Javascript suffers when you use high level constructs and convenience frameworks, but so does C++ (which is why people don't use them). It will probably take a long time for javascript to get proper cross browser SIMD support though...
>
> When you get rid of IE9 the real bottleneck to combat is the C++ browser runtime, reflow and "random delays" etc.
>
> Memory usage/performance are issues you can limit by using typed arrays/free lists. But the browser impose limitations on memory usage...

This might be true, but then you're boiling down the whole reason JavaScript took off: Frameworks. JavaScript is a horrendous language to use, unless you throw some common framework at it that attempts to unify all the browser quirks into easy APIs, such as jQuery or Mootools.

JavaScript was never designed to be a language to run games or high-performance software with. The only reason we see that today is because of the trend towards "Web 2.0" and "google my software" where everyone wants everything to be easily accessible in the browser. We an overflow os knuckle-head JavaScript developers, and there bosses, we now have what we see today: Frameworks on-top of frameworks to complete the simplest things, because JS as a language cannot do it effectively.

Any language can be optimized more heavily if we throw the framework(s) out. However, your development time sky-rockets. In today's moving world, companies simply don't have time for that. Thus the end result: bloated web pages that stall and lag due to un-optimized framework heavy JavaScript.

In all the years I've been working, there was never one language I avoided more: JavaScript. My team and I have nick-named it "booty-script" because of it's lack of modern day anything, and it's terrible semantics.

Most people don't write JavaScript. They right jQuery, or Mootools, or some other framework API that abstracts away the JavaScript ridiculousness.

On Thursday, 30 July 2015 at 14:13:53 UTC, Brandon Ragland wrote:
> This might be true, but then you're boiling down the whole reason JavaScript took off: Frameworks. JavaScript is a horrendous language to use, unless you throw some common framework at it that attempts to unify all the browser quirks into easy APIs, such as jQuery or Mootools.

Javascript is never going to be great, but it is "ok" if you approach it like you would approach C and use the Closure compiler with type annotations. Closure does a reasonable job of constant folding and inlining. Of course, some tricks like coercing numbers to int by "x|0" are a bit annoying to type.

Typescript 1.5 is a lot more convenient than plain javascript. It emulates some ES6 syntax like proper foreach "for(var e of somearray)" and provides typed interfaces and more usual OO-inheritance. I am looking forward to Angular2 which is written in Typescript.

Browser quirk libraries no longer have merits IMO. For many projects IE8 is out, IE9 is becoming obsolete and IE10 is quickly replaced by IE11. MDN and caniuseit documents browser support fairly well.

> JavaScript was never designed to be a language to run games or high-performance software with.

Yes, also writing games on the web is difficult as the GPU capabilities varies a lot.

> Any language can be optimized more heavily if we throw the framework(s) out. However, your development time sky-rockets. In today's moving world, companies simply don't have time for that. Thus the end result: bloated web pages that stall and lag due to un-optimized framework heavy JavaScript.

I think one of the problems with webdev is that customers/superiors are lead to expect a lot less development time than for native. I sometimes think that the relative effortless creation of HTML webpage or setting up a WordPress site has a negative effect on expectations for web app development.