Live data from Hacker News

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

wired.com

201–210 of 270 posts

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

#201
post #175

Earlier quoted context omitted.

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…

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

I don't understand why people say javascript is such an awful language. The "Wat" video previously posted features of a few javascript idiosyncrasies, but I think most people would consider such obscure syntax combinations to be ill mannered, and most people understand to be very careful around type conversions.

At a higher level of organization, the language begins to matter less and less, and what matters more are that subcomponents within a larger system obey their contracts, and that there's some concurrency strategy if you have distributed state.

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

#202
post #180

Earlier quoted context omitted.

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/…

> it gives you the simplest no-BS object/array literals you can get I really don't think that: { "foo": "bar", "baz": ["quux", 1, true] } is simpler than: ((foo bar) (baz (quux 1 true))) Quite the opposite, really.

Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? Or rather, does one simply use expectations/context to compare this object to, say

  [["foo", "bar"], ["baz", ["quuz", 1, true]]]
making it a non-issue?

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

#203
post #129

Earlier quoted context omitted.

JS is safe C with types and pointers stripped from the syntax. I don't get why people don't understand its popularity. HTML lets you put boxes on the screen and CSS lets you paint-by-number(id/name/selector). If you aren't doing any of those things, I am very curious to know what exactly you are doing.

JS is most definitely not safe C. It has a brace based syntax with if statements and for loops but other than those superficial similarities it's semantics are vastly different.

Just like PHP :-)

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

#204
post #180

Earlier quoted context omitted.

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/…

> it gives you the simplest no-BS object/array literals you can get I really don't think that: { "foo": "bar", "baz": ["quux", 1, true] } is simpler than: ((foo bar) (baz (quux 1 true))) Quite the opposite, really.

The bottom is definitely ambiguous.

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

#205
post #165

Earlier quoted context omitted.

You are forgetting that even Eich didn't want to do JS; he wanted to embed Scheme but was overruled by suits at Netscape who wanted to ride the Java hype. That's why the semicolons and curly braces. It really is indefensible on technical grounds.

I think they also told him to make it forgiving, like html, so that beginners could use it. Thus the implicit conversion rules, optional semicolons, being able to leave new off a function constructor, not having to use var, and so forth.

It's too bad nobody pumped the brakes after it was a little successful, and said "Okay guys, let's stop dicking around and do this right now, before we have to deal with it for the next 30 years". Alas...

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

#206

Earlier quoted context omitted.

> that _doesn't_ do this kind of thing Why does that matter to anyone? > you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for Java and C# are both statically, strongly typed languages where JITs are the dominant implementation. Almost by definition, it's impossible to write a JIT compiler that outperforms AOT compilation without looking at…

> For example, it's not possible to statically determine whether a function should be inlined or not. MLton has absolutely no problems inlining functions, even higher-order functions, at compile time. This is only difficult in languages with virtual methods, because they can be overridden anywhere. If anything, that's an indictment of virtual methods, not AOT compilers. > However, a JIT can see that it's used in a ho…

> MLton has absolutely no problems inlining functions, even higher-order functions, at compile time

Of course, but how does it know which functions to inline? If you inline everything, then you will blow through your cache.

> What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop.

That's not true--a JIT could optimistically replace with a concrete realization.

> Runtime information is always anecdotal, specific to one particular run of a program, so...

That's a benefit. No matter what AOT compiled code you have, it is possible to speed up execution if you know what code paths you will take.

> ... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound.

Yes, but so what? As long as it improves performance in the average case, and the worst case is bounded, then that is a net win. You can equally well write deliberately obfuscated code that an AOT compiler has trouble with.

> Language implementations must work correctly whether you write idiomatic or unidiomatic code.

Implementation is correct. Only reflection is slow. If you don't want that, don't write reflection.

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

#207
post #193

Earlier quoted context omitted.

> Tracking down things in JS is a timesuck of epic proportions. I think you mean your codebase rather than JS. There are plenty of industrial JS codebases where this is not a problem.

I'll be the first to confess I'm not a JS wizard. That being said, it'd be nice for the following to be easier: * figuring out which events are listening to a given DOM element at any given time * sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company * no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}") * keeping CSS ou…

Not to be too pedantic, but most of those things have nothing to do with JS.

> figuring out which events are listening to a given DOM element at any given time

This is part of the DOM Specification, not JS. You may be using JS to manipulate and listen to the DOM, but the reason that browsers don't support doing thing X natively is because the DOM Specification does not specify it.

> * sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company

Again, this is about a Facebook client library, not Javascript.

> * no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")

If you mean the use of eval to change the runtime environment, pretty much every dynamic language supports some form of eval. It would also be impossible to write certain types of code without eval.

> * keeping CSS out of JS, and JS out of HTML

Not sure how this is a criticism of JS.

> * dealing with features tightly coupled to an ancient jQuery plug-in

Again, this is a common software engineering problem, and has nothing to do with Javascript.

I think you've illustrated some of the reasons that Javascript is so apparently unpopular -- often (but not always) people reference some aspect of the DOM, or jQuery, or whatever vendor-hacked snippets from the late 90s that they remember, without considering that the "bad" parts of the language are by now well known, and there exist extremely efficient and standards-compliant, double-JIT'ed runtimes for JS.

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

#208
post #180

Earlier quoted context omitted.

> it gives you the simplest no-BS object/array literals you can get I really don't think that: { "foo": "bar", "baz": ["quux", 1, true] } is simpler than: ((foo bar) (baz (quux 1 true))) Quite the opposite, really.

Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? Or rather, does one simply use expectations/context to compare this object to, say [["foo", "bar"], ["baz", ["quuz", 1, true]]] making it a non-issue?

> Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality?

With the right predicates, anything is possible grin

I think that context unavoidable: one can't just read a JSON value into a generic data structure, or even into a typed structure: one has to apply the types of one's business logic (e.g. 'user-id' must not only be a string, but a string beginning with either 'E' or 'C'). In that context (pun intended), then it makes sense for equality comparisons to be at the business-object layer, not at the freshly-deserialised JSON object layer.

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

#209

Earlier quoted context omitted.

If only web developers would unite and put an end to JS once and for all. This is really sad, a whole industry that was once inspired by Unix philosophy and was supposed to be beautiful and fun, is now conquered by languages like JS, php, and Java: so ugly and so not fun. I always thought programming should be something you do cause you like it, not because you're forced to do it. If you use JS cause "everybody else…

> (Oracle, Microsoft, ...) who force Java and JS on everybody. Why call out Microsoft? They aren't forcing Java or JS. They came up with C# and Typescript instead. I can't speak to Typescript, but C# is way more fun to write than Java. It's not particularly interesting or glamorous, but it is nicer to write.

We've converted all our JS to TS, huge timesaver.

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

#210
post #136
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…

There is no "View source" button for native applications, and you can not modify them and see the results immediately.

Probably 90% of .NET/JVM apps, you can hitch a decompiler up to and "View Source".

Patching the byte code and having it run is a little tougher...

Post reply on HN