Live data from Hacker News

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

wired.com

191–200 of 270 posts

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

#191

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.

I meant in general. Microsoft did force their flawed Windows on everybody anyway.

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

#192
post #181
post #131

Earlier quoted context omitted.

"But Electron is also awful, since a hello world app uses 100mb of RAM." Is it that awful, though? Most computers come with 4-16GB of RAM.

Yes, that is not just terrible it is embarrassing.

8-bit 4mhz CPU, 64k RAM:

https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)

https://www.youtube.com/watch?v=5OT3DoPty4Y

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

#193

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... I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.

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

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

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

These laundry lists of js warts get dragged out continually, so I really have to ask: How are you people actually developing in javascript and haven't yet discovered linters?

Linters have been around for over a decade and solve all of these issues (as they do in other languages as well). They're also easily integrated in every text editor and build system I've ever seen.

And why shouldn't the interpreter support these rules? Because a linter can do this almost as easily, and not break backward compatibility.

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

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

Javascript became far more significant than what it used to be. We can largely thank Microsoft (AJAX) and Google (V8) for that.

And Sun, for being assholes about Java.

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

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

That does look nice. Is that, LISP? To my eye, they look roughly equivalent, though - and a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.

> Is that, LISP?

Well, S-expressions, which can be used for Lisp code, but can also just be used for plain data.

> a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.

Yeah, it's definitely convenient to use, even more so than Python's objects. I prefer a stronger type system for my own software though.

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

#197

Earlier quoted context omitted.

Could you name a JIT compiler that doesn't do this kind of thing, yet offers performance comparable to AOT-compiled languages? (FWIW, I'm not saying it's impossible. It's perfectly possible, but you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for.) --- Sorry, can't reply to you directly, because “I'm submitting too fast”. So my reply goes…

> 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 hot loop and dynamically inline.

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.

> For any language, no matter the type system, runtime information will always be a superset of compile-time information.

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

> There will always exist optimizations in a JIT that aren't possible in an AOT compiler.

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

> Idiomatic Java code doesn't use these features heavily.

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

> Just because it's possible to wipe out type information doesn't mean that the vast majority of code that an AOT or JIT compiler sees won't be strongly typed.

Most code I write in Python could be given static types too. That doesn't make Python a statically typed language.

And “strongly typed” doesn't really mean anything.

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

#198
post #146

Earlier quoted context omitted.

I don't think you know what you're talking about. PHP, up to version 4 at least, was hardly even a language. More like a collection of macros. Javascript, despite a few ugly gotchas, is an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility.

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

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

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

    x += 2;
    call(param);
    data.key = cache[0];

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

#200
post #193

Earlier quoted context omitted.

>> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on... I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.

> 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 out of JS, and JS out of HTML

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

I could go on forever... JS isn't necessarily that bad, but the way people use it is often suboptimal.

Post reply on HN