Live data from Hacker News

JavaScript Conquered the Web, Now It’s Taking Over the Desktop

wired.com

251–260 of 270 posts

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#251
post #247

Earlier quoted context omitted.

I guess I believe it is common that if a platform becomes popular enough for developers - solutions will appear to allow them to reuse their knowledge in developing applications outside of their original target platform. Furthermore in the attempt to woo developers from one popular platform to another a myriad of solutions will appear to allow the developer to move their existing tools, methods, and general knowledge…

There are more advantages than just not having to learn something new. There are really compelling reasons you might want to use the same code in some combination of: a web browser, web server, Windows app, Mac app, iOS app, and Android app. For instance, when FB used React Native for building one of their ad manager apps, they had 87% code reuse between iOS and Android ( https://twitter.com/brindelle/status/61811439…

>There are really compelling reasons you might want to use the same code in some combination of: a web browser, web server, Windows app, Mac app, iOS app, and Android app.

I agree, but it is my experience that this always comes with a downside that you don't know some of the platforms you are running on and there are deficiencies. The Native is better argument

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#252
post #224
post #88

Earlier quoted context omitted.

Have you checked how much memory they use? I know we have 8-core laptops with 16 gigs of RAM, but, still, it's excessive.

Any idea why the memory usage is so high? Is it related to the Electron/Chromium platform, or bad application design?

Would need to check, but my bet is caching of partially rendered HTML as bitmaps, as well as a full JavaScript JIT environment.

It's just a high footprint enironment.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#253

Earlier quoted context omitted.

More likely they see a lot of programmers who only know JavaScript and they want to offer them something.

Is that a bad thing?

No, well programmers just knowing JavaScript is but catering to a wider audience is a good thing.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#254

> It turns out it’s useful to have a lingua franca for the web. No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. There is a BIG difference. > Creating desktop apps in JavaScript lets developers choose from a vast range of freely available code libraries and frameworks, which takes much of the grunt work out of coding Lots of…

I can't believe this is the top comment. Let's go point by point: 1) JavaScript has its warts and its gotchas like anything else (okay, maybe a few more). So what? Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Same goes for just about any other language. Focusing on the weird edge cases might make for a nice blog…

1) JS is a wart. "but it's not relevant to people actually building things day to day." - look at all those crappy electron apps... 4) Very young community not giving a * about optimisation and quality.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#255
post #222
post #175

Earlier quoted context omitted.

> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Spending 10,000 hours building things with JavaScript sounds like a pretty good definition of Hell. JavaScript is an actively, abusively bad language. It's not that it has a few warts: it's nothing but warts. Its fundamental design flaws are obscured only by its supe…

> It's a really bad, tasteless language. It's really not that bad. It's actually a good language, and getting better all the time. See? We can go back and forth, without any substance. But seriously, modern JS is not that bad.

"It's really not that bad." - yes, it's worse... " It's actually a good language, and getting better all the time. See? We can go back and forth, without any substance." - man, go and see a language with sane typesystem and language rules ASAP. "But seriously, modern JS is not that bad." - they won't be able to fix JS otherwise it'd be an entirely different language.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#256
post #16

Earlier quoted context omitted.

> That isn't an argument against leveraging web technology so much as an argument in favour of well written applications The difference is there is very little room for optimisation in most javascript runtimes. They don't support multi-threading and the memory is impossible to manage. "Lower" level languages always allow better performance tweaking when necessary. Javascript allows next to none. You can't tell javasc…

> They don't support multi-threading Yes, they do, via Web Workers. They just don't support multithreading at the level of concurrent access to the DOM, and they don't support shared memory. Very few native libraries support concurrent access to UI widgets, and not many native applications make heavy use of shared memory for compute either. (Most native applications don't have heavy compute needs in the first place…)…

Please :

> Yes, they do, via Web Workers.

Which are not part of the javascript spec, it is DOM related. And web workers were never meant to increase performance. In fact in practice they don't, they often make code slower. They just guarantee that the UI thread will not block.

> new Array(10)?

Which doesn't allow any specific runtime optimization as the array can be resized at anytime

> Uint8Array, Uint16Array, Uint32Array?

Which doesn't give me an integer of a specific size BUT any array of integer.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#257

> It turns out it’s useful to have a lingua franca for the web. No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. There is a BIG difference. > Creating desktop apps in JavaScript lets developers choose from a vast range of freely available code libraries and frameworks, which takes much of the grunt work out of coding Lots of…

> Let's just call this experiment a failure The problem with "just calling this experiment a failure"—why that won't work in practice—is that JavaScript is not a failure. It's extremely successful.

> The problem with "just calling this experiment a failure"—why that won't work in practice—is that JavaScript is not a failure. It's extremely successful.

I don't see the "success", only the tons of dysfunctional bloatwares. JS made the browser slower and worse just like all the JS-based desktops(gnome, cinnamon, deepin(golang...)). Also, it has stopped PLT advancements by stealing young people(future community) to create useless websites and apps. Neither "failure" nor "success" are good words - "curse" will fit better.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#258
post #198

Earlier quoted context omitted.

> hardly even a language. More like a collection of macros. You just described Forth, and a good portion of Lisp. Both of which are great, groundbreaking, and productive languages. > an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility Very eloquently said. However, compared to other dynamic languages like Lisp, Perl, Ruby, and Python, it doesn't strike me as part…

DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation. Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.

We apparently have a very different definition of DSLs. Both jQuery and Lodash are, to me, libraries with lots of functions. A DSL, to me, would be a change in the underlying language being interpreted.

i.e.

    describe file("foo") do
      it { should exist }
      it { should be_owned_by "root" }
    end
vs.

    _.map(["a"], function(s) {alert(s)})

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#259
post #198

Earlier quoted context omitted.

DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation. Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.

We apparently have a very different definition of DSLs. Both jQuery and Lodash are, to me, libraries with lots of functions. A DSL, to me, would be a change in the underlying language being interpreted. i.e. describe file("foo") do it { should exist } it { should be_owned_by "root" } end vs. _.map(["a"], function(s) {alert(s)})

  describe("something", () => {
    it(should(exist))
    it(should(be_owned_by, "root"))
  });
Also

  _.map(["a"], s => alert(s))
Or just

  _.map(["a"], alert)

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#260
post #215

Earlier quoted context omitted.

> There are plenty of times where you want == FWIW, I've never used ==

FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.

[deleted]
Post reply on HN