Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript at 20

brendaneich.github.io

Post reply on HN
Print view View original

241–250 of 327 posts

Re: JavaScript at 20

#241

Post by bitL »

nostrademons wrote: post #193
ForHackernews wrote: post #183

Earlier quoted context omitted.

Semi-serious question: Other than backwards compatibility, do browsers need to have a DOM? It seems like many web app devs spend more time fighting against the DOM than working with it. Why not just make the browser expose a generic GUI model? Let web devs interact with Webkit or QT directly?

Generic GUI toolkits are very often worse than the DOM. I've worked with Swing, MFC, SWT, Android, and iOS, and all of them are significantly more complicated than the DOM is. They do function at a higher level of abstraction, and the two really nice things they give you are components and a sane layout system (solved by WebComponents and Flexbox, now if only all the major browser vendors would just adopt WebComponen…

I still remember how super easy and fast was to make a GUI in Delphi/C++ Builder - what took a month in MFC/Swing took about an hour in Delphi. Even Qt feels like a massive step back from this...

Re: JavaScript at 20

#242

Post by serve_yay »

UnoriginalGuy wrote: post #126
BurningFrog wrote: post #93

"Date hand-ported (h/t ksmith@netscape.com) from java.util.Date" I knew it!! The Date class is/was the worst thing about the Java library. It has confused a generation of programmers about dates and time zones. The main problem is that it's not a date, it's a time stamp.

And while there are libraries which wrap Date in JS, there is no replacement that I've seen anyone propose. Why is a replacement needed you ask? Because Date still has exclusive access to a lot of underlying browser/OS DateTime information which isn't accessible any other way. In Java you legitimately have alternatives, since the alternatives can make the same raw OS calls that the java.util.Date library does. Not so…

I don't think anyone would say JS's date situation is better than .NET's. .NET's is excellent, I agree. I wish we had something like that. You can't even reliably get the current locale in JS, it's insane.

Re: JavaScript at 20

#243

Post by nilliams »

SoftwareMaven wrote: post #239
nilliams wrote: post #235

Earlier quoted context omitted.

> like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python. I'm a Python fan but I can't disagree more on that point. Python has terrible lambdas, and poor idioms when working with collections (list iteration over cha…

Doing good Python would help. You don't need the backslash on the first, making it a little cleaner: map(lambda x: x * 2, filter(lambda x: x % 2 == 0, [1, 2, 3])) But the list comprehension version is just completely wrong: [x*2 for x in [1, 2, 3] if x % 2 == 0] Which, in our subjective world, is cleaner than the ES5 version and almost as clean as the ES6 version.

> You don't need the backslash on the first, making it a little cleaner

I was not trying to illustrate that the backslash made it ugly (I've removed it - I was pasting from a repl). It's ugly because of Python's lambda syntax and the fact it does not compose 'sensibly', as compared to fluid interfaces. The logic is back-to-front for one.

> But the list comprehension version is just completely wrong:

No, it's not at all wrong. Your one-liner is not better and (I hope) would probably upset most teams for being less clear.

I was providing a like-for-like example. The multi-lining is not the criticism of the Python version. It's the composition that's at fault, the fact it does not feel like 'two coherent operations over a list' with two distinct conditionals.

The ES5/ES6 examples demonstrate this much more clearly IMO.

Re: JavaScript at 20

#244

Post by brandonmenc »

knightofmars wrote: post #40

"Haters gonna hate." Anyone claiming that JS is the "worst thing to happen to the web" and/or that some other language would miraculously solve all of the problems present in JS should do the following, "Go create it." Don't whine about the barriers and how a new language would never be adopted because "JS is already everywhere." There are plenty of people already trying to solve this problem by actively doing someth…

> Don't whine about the barriers and how a new language would never be adopted because "JS is already everywhere."

That's a legitimate complaint.

There's so much inertia that without the backing of the major browser manufacturers, any effort to introduce a change is doomed to obscurity.

People are allowed to complain, even while not being able or willing to work on a solution. We used to do that with DOS all the time.

Re: JavaScript at 20

#245

Post by bitL »

gohrt wrote: post #87
bitL wrote: post #18

I wish JavaScript "committed a teenager suicide" and we finally got a more sane language for the web. It's startling how much energy is spent to work around its bad design every day and it's not getting any better, people are just getting used to it (which is akin to voluntarily agree with having most of one's brain blown off). Even seeing Brendan showing off that he hacked the language in 10 days makes me sick to th…

This post, like JavaScript, is an utterly horrible way to express an idea.

At least we agree on the main point.

And I obviously referred to JS just passing its teenage years, which I would prefer it didn't manage to. I am one of those crazies that are implementing a desktop-like functionality app for creatives in a browser, created a car racing game in pure JS without a single 3rd party library, did computer vision in a browser via webcam etc. and every time I have to use JS/DOM/CSS it just makes me feel I need to go to Queenstown and jump off the Kawarau bridge...

Not to mention that as a Mozilla fanboy I even use bleeding edge Firefox OS on my primary business phone.

Re: JavaScript at 20

#246

Post by robocat »

jessaustin wrote: post #104
M8 wrote: post #8

I just wish the best language would win, not the accidentally ubiquitous one. And giving a real choice of language would been even better.

Well, at least Java didn't win. Those not old enough to remember "applets" may not know how lucky they are. Eich deserves credit for all sorts of things, but not least for saving us from that. And who knows what scripting languages the browsers of tomorrow might support?

Even worse: imagine a world with VBScript instead of ECMAScript...

Re: JavaScript at 20

#247

Post by Sanddancer »

TazeTSchnitzel wrote: post #146
TazeTSchnitzel wrote: post #120

Earlier quoted context omitted.

...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)

14paninta's comment is dead again - shadowban? Anyway, I'll repost and respond: > asm.js doesn't support threading. asm.js supports threading, actually, through Web Workers and SharedArrayBuffer. > it can't run native code. This is true, but asm.js is relatively close to the metal. It's not very far from assembly language. > it doesn't support meaningful debugging. This is a tooling issue. While the situation is bad…

Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc.

With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.

These problems all come back to the fundamental issue. There's no escape from javascript. Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. Thus, we stagnate, and everyone suffers for it.

Re: JavaScript at 20

#248

Post by TazeTSchnitzel »

tracker1 wrote: post #211
TazeTSchnitzel wrote: post #138

Earlier quoted context omitted.

> In Java you legitimately have alternatives, since the alternatives can make the same raw OS calls that the java.util.Date library does. Not so in JS. So instead we HAVE to work with Date and work around its many warts. Uh, what? Yes, JavaScript's Date is the only way to get at that browser/OS stuff. So an alternative will use Date underneath to obtain that information. That doesn't mean the end-user has to work wit…

I'll add that timezone information shifts politically over time... It'll never be consistent... your best bet is to ship all dates in UTC as much as possible (which `.toJSON` does) and display in local (which `new Date(jsonstr)` does). Dates are evil, even in C# with offsets it's not easy... and that's probably the best implementation of dates, with consistent updates I've seen.

> your best bet is to ship all dates in UTC as much as possible (which `.toJSON` does) and display in local (which `new Date(jsonstr)` does).

Goodness yes, I really wish more sites did this. If you're asking a user what their timezone is, you're usually doing it wrong. Send UTC to the client, gracefully upgrade with JS to local time.

This also solves those pesky DD/MM/YY vs MM/DD/YY issues!

Re: JavaScript at 20

#249

Post by TazeTSchnitzel »

frik wrote: post #139
TazeTSchnitzel wrote: post #133

Earlier quoted context omitted.

> Polyfills can be used for pre-JS5 browsers. But can you polyfill "let" and "class" syntax keyword? No, but you can compile ES6 code using it to ES5 code.

Is the only solution to transpile ES6 to ES5 until 2025 or whenever IE11, Safari 7 and all current Smart TVs and Cars and what not have their end-of-life and simply vanish? Let's remember the problems with Internet Explorer 6 and its long actual lifetime. At the moment IE8 (WinXP), IE11 (Win8) as well as various other browsers will never receive an update on their platforms.

> Is the only solution to transpile ES6 to ES5 until 2025 or whenever IE11, Safari 7 and all current Smart TVs and Cars and what not have their end-of-life and simply vanish?

Well, it depends who your target audience is. If users with old browsers don't matter, you don't need to transpile.

Re: JavaScript at 20

#250

Post by TazeTSchnitzel »

Sanddancer wrote: post #247
TazeTSchnitzel wrote: post #146

Earlier quoted context omitted.

14paninta's comment is dead again - shadowban? Anyway, I'll repost and respond: > asm.js doesn't support threading. asm.js supports threading, actually, through Web Workers and SharedArrayBuffer. > it can't run native code. This is true, but asm.js is relatively close to the metal. It's not very far from assembly language. > it doesn't support meaningful debugging. This is a tooling issue. While the situation is bad…

Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have acce…

> I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc.

It has all of these things. It has SIMD now, 64-bit support is improving, IEEE-754 is supported (though some of the checks aren't available yet, I'll give you that). Give it time.

> With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.

Yes, but this stuff isn't applicable to asm.js. It shares a heap between threads, it's just like your old native code, and everything is triggering race conditions^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B hunky dory.

> These problems all come back to the fundamental issue. There's no escape from javascript.

What's wrong with that? If you don't like JS, you can compile to it. It's an excellent compile target.

> Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility".

It's not just a compatibility hack, though managing to work on everything with no updates is a killer and awesome feature. It also avoids unnecessarily reinventing the wheel. It reuses as much of JS as possible. That's good.

> Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web.

...well, yes, they're fracturing it. And usually needlessly. There'd be no benefit to a new language on the web. There's nothing a new language can offer which JS doesn't have.

> Thus, we stagnate, and everyone suffers for it.

What stagnation? Everything is moving rapidly. Things are improving all the time.

Post reply on HN