Live data from Hacker News

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

wired.com

111–120 of 270 posts

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

#111
post #40

The salient points of the article: - People are stuffing websites into Electron and packaging it as a native application - HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience Although the article doesn't say it, this seems to imply that: - Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electr…

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 from their comfortable and familiar platform onto the new one.

I'd suppose anyone that has more than 5+ years experience and has moved between at least two types of platforms can point to examples in their mind.

Personally I dislike this habit of using tooling to solve platform movement and escape the time constraints inherent in learning to develop for a new platform; I can however see the attraction, because, it really does ease time and effort in learning something new even if to provide this easing it acts a buffer to any deep understanding of the target platform.

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

#112
post #95

Earlier quoted context omitted.

> 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.

And it is extremely successful because it's not a bad language. Sure, there's lots of "wat", but a non-professional programmer is going to say "wat" about every strange error they get from another programming language that js would have just passed silently with a weird result. Then they will replace whatever construct isn't working with one that does, and get on with their life, unlike people who seem to have a lot…

> And it is extremely successful because it's not a bad language.

Perhaps not a bad language, but I do think it falls into the same category as PHP - just good enough.

It's just good enough to do what we want it to do, and given the lack of choice, we're willing and ready to pile abstraction upon abstraction upon it to try and reduce the pain involved with getting work done.

And like masochists, we look at the results and go "Well, that didn't hurt too bad this time, so I'm willing to go do it again."

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

#113
post #11
post #2

I'm not an expert, but the memory required to render the seemingly simplest of interfaces in html/js/css in a browser today seems excessive. Some web sites bring a reasonably powered desktop to its knees. I'm not sure I want this problem on my desktop too. Though I guess this is just one step closer to having METAL. https://www.destroyallsoftware.com/talks/the-birth-and-death...

Poorly written websites can bring a desktop PC to its knees, but so can a poorly written native application. That isn't an argument against leveraging web technology so much as an argument in favour of well written applications. And at least with a chromeless-browser-pretending-to-be-application you have the protection of the browser process sandbox so an app that goes awry isn't going to take your computer down that…

>That isn't an argument against leveraging web technology so much as an argument in favour of well written applications

On point, as someone who has written both native and web apps. it really comes down to execution. Elitism aside, Web based apps can work for some scenarios

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

#114
post #40

The salient points of the article: - People are stuffing websites into Electron and packaging it as a native application - HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience Although the article doesn't say it, this seems to imply that: - Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electr…

What makes JS more "hackable"? Someone find that cartoon about the gaunt-looking guy and the laid-back kid when the girl asks them to hold her coffee and link it [edit: http://i.imgur.com/76Wtthy.jpg ]. ...Because it gets the hell out of they way and holds your coffee for you and doesn't slap it out of your hand and throw a tantrum because it was actually a medium coffee ...and it gives you the simplest no-BS object/…

Typescript is sufficiently close to JavaScript that it doesn't really feel like it's treating JS as some invisibly underlying assembly-like layer.

In practice, you can use as much or as little typing as you want, and the compiler will occasionally tell you "I think you're doing something dangerous here", but even then you're only one away from ignoring its generally good advice (or more sanely, you would annotate the ambiguous bits a bit better so typescript understands you really meant to do that.)

But otherwise, all the usual js hacks still very much apply.

Anyway, that's why typescript is my cup of tea|coffee.

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

#115
post #95

Earlier quoted context omitted.

> 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.

And it is extremely successful because it's not a bad language. Sure, there's lots of "wat", but a non-professional programmer is going to say "wat" about every strange error they get from another programming language that js would have just passed silently with a weird result. Then they will replace whatever construct isn't working with one that does, and get on with their life, unlike people who seem to have a lot…

I mean, the whole "{} + [] == 0" thing is cute and all, but isn't that just tip-of-the-iceberg hilarity? Isn't the real problem with javascript that it's slow and messy?

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

#116
post #109

Earlier quoted context omitted.

Sure, but there are better alternatives, and now that JS isn't just confined to the web, where it had no real competition, people are complaining because they see it being used instead of better tools that have been available for a long time.

ES6 is better. [edit] ES6 is definitely better than a swift kick in the groin. It is certainly better than the original version of javascript. And it is also better than a lobotomy.

Better than....? A swift kick to the groin? Original Javascript? Lobotomies?

"Better" doesn't necessarily imply "Good".

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

#117
post #98

Earlier quoted context omitted.

> Most high-level languages require compiler tricks for achieving performance from Scala to Haskell to Prolog. To make things perfectly clear: I'm not against optimizations being performed automatically by compilers or runtime systems. What I'm against is unclean designs : deliberately performing an unsound optimization and then rolling it back is an unclean design. > Use all the hackery in the world to get your lang…

is an unclean design. It's not unsound. Otherwise you'det g incorrect results. You could say the design is wasteful, because you optimise and then throw away the optimisation. But it's hard to do better for some kinds of languages. trust a hackish language implementation I agree. And indeed JIT compilers are hard to get right. But in practise even JIT compilers are much higher quality than applications: ask yourself,…

> It's not unsound. Otherwise you'd incorrect results. You could say it's wasteful, because you optimise and then throw away the optimisation.

The optimization is unsound. If it weren't, it wouldn't have to be rolled back occasionally.

If you're talking about the combination of the optimization and the rollback mechanism, it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you.

> how many of the bugs in your code turned out to be compiler bugs, vs how many were ultimately your mistakes?

Of course, most were my mistakes. But the very reason why those bugs made it into the final executable is the lack of powerful static analyses in the first place. Curiously enough, when I use languages that make static analyses possible, I write programs with less bugs and they perform better without relying on fancy runtime system tricks.

---

Sorry, can't reply to you guys, because “I'm submitting too fast”. So my replies go here:

@mafribe:

> That's an orthogonal issue.

It's not. Static analyses gather valuable information that can be used to emit efficient code.

> More powerful static analysis is also more time-consuming.

So perform it ahead of time!

> One of the design goals of Javascript JITs is to make web-pages as responsive as possible. That rules out complicated static analysis.

Of course, a browser can't spend much time statically analyzing JavaScript programs, but programs can be statically analyzed (gasp!) before they're deployed.

---

@smallnamespace:

> Why does that matter to anyone?

Because this implementation technique is unnecessarily complex, and a far simpler alternative exists: Know beforehand what your program has to do. Think before you write code.

> Java and C# are both statically, strongly typed languages where JITs are the dominant implementation.

Their type systems can be easily subverted, so they're not “strongly typed” in my book.

---

@smallnamespace: Oops, sorry, I accidentally swapped my two replies to you: this one and https://news.ycombinator.com/item?id=12481956 .

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

#118
post #46
post #13

JavaScript didn't "conquer" anything. It was just one of the first languages around when the web was still in its infancy, and simply never went away.

You're in denial. Javascript is everywhere nowadays. It has become the English of languages. It's not my favorite language but it has improved extensively. No one wants to maintain a web app, mobile app, and desktop app separately.

Sun was making the same sort of promises with Java about write once, run anywhere, because nobody wanted to have to write their application multiple times to target different platforms.

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

#119

When I choose softwares, I tend to choose native one over electron or JavaFX ones. It feels more native and more "sincere", like the developer really want to make it a good software. I know this logic doesn't make sense, but I don't mind paying more if it is native. It's like a handwritten letter, not a printed one.

> "...I don't mind paying more if it is native..." I'm curious on how you know this before you even purchase? For example, the Mac app store can have both native and electron apps? You wouldn't know it's native or not until after you purchase it?

1. File size is a big hint. 2. Most of the electron apps doesn't replicate native elements completely, so you can guess it from tiny details like shape and shadow of text field. 3. It is also very common for their windows counterpart to look exactly the same.

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

#120

When I choose softwares, I tend to choose native one over electron or JavaFX ones. It feels more native and more "sincere", like the developer really want to make it a good software. I know this logic doesn't make sense, but I don't mind paying more if it is native. It's like a handwritten letter, not a printed one.

> "...I don't mind paying more if it is native..." I'm curious on how you know this before you even purchase? For example, the Mac app store can have both native and electron apps? You wouldn't know it's native or not until after you purchase it?

[deleted]
Post reply on HN