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

The JavaScript Problem

haskell.org

Post reply on HN
Print view View original

81–90 of 183 posts

Re: The JavaScript Problem

#81

Post by insin »

hamburglar wrote: post #75
hippich wrote: post #48

Earlier quoted context omitted.

and this is perfectly fine. it allows you to do more if you know how to use it. and if you don't - it is really simply to understand. again - this is how js different from many (all?) languages out there, but why it is bad - i am not sure. extra line of code in some cases? I don't think this is really that bad.

I won't say it's good or it's bad, but I will say that it bites me on a pretty regular basis. You start with some code that says this.something() and you decide to move it into a callback and miss converting the 'this' references to 'self' because in the previous incarnation, it didn't matter, but now you're calling out to code that helpfully fixes up the 'this' reference when calling your callback. I literally fixed…

Are you using strict mode? It doesn't fall back to the global object as `this` (except for setTimeout/setInterval, which are specified that way) - since I've started using it, I find out pretty quickly if I was missing a `.bind(this)` when passing a callback function.

Re: The JavaScript Problem

#83

Post by chipotle_coyote »

cbhl wrote: post #54
kenjackson wrote: post #32

Earlier quoted context omitted.

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a…

The web was multi-lingual, it's why script tags have a "type" parameter. I personally think that the death of plugins came about as the result of the iPhone, because x86 binary plugins won't run on an ARM-based phone.

Uh, scripts aren't plugins, right? In theory there could be other scripting languages for use in web browsers, which is what the "type" attribute would have been used to indicate. It's just that nothing else ever really took off. Other than Microsoft's VBScript, the only browsers I can think of that supported other scripting languages were early proof-of-concept attempts like Grail.

I think you're a bit confused about browser plugins in general here. They're OS-specific and CPU-specific. I can run Linux, Windows and OS X on a MacBook, but I need OS-specific versions of both the browser of my choice for each one and the browser plugins of my choice for each one. If the iPhone has helped contribute to the decline of plugins, it's because iOS doesn't support them at all, full stop -- if it did, though, they'd have needed to be compiled in iOS-specific versions even if the iPhone used x86 chips.

Re: The JavaScript Problem

#84

Post by jkrems »

copergi wrote: post #60
djur wrote: post #53

Earlier quoted context omitted.

It's sad that we should expect Haskell users to be chauvinistic about static typing. I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw".

>It's sad that we should expect Haskell users to be chauvinistic about static typing. We don't expect that. We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way. >I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw". Try looking on the internet. Every "static vs dynamic" argument has 99% of the…

> We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way.

Obvious - because you just said "with better defined as has more static typing, static typing is better". That's an empty statement if I ever saw one.

Re: The JavaScript Problem

#86

Post by jkrems »

michaelsbradley wrote: post #74
camus2 wrote: post #66

Earlier quoted context omitted.

clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is implemented in javascript and can run on nodejs,then maybe i will consider it.

Would you articulate why it's a "no go" for you? Leiningen[1] takes away 99.9% of the pain of having to work directly with javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-driven approach to compiling and testing. It's perfectly possible to create setups where node (plus grunt, gulp, shell scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I contributed such a setup[3…

Because if other parts of your stack don't depend on Java, you have the overhead of having to install a complete java environment (on dev machines, CI, ...) just for compiling your front-end code. It also makes "language independent" tooling for javascript harder. Then again: I guess most people who use clojurescript are already using clojure so it wouldn't be a problem for them.

Re: The JavaScript Problem

#87

Post by auvrw »

camus2 wrote: post #66
fiatmoney wrote: post #55

Clojurescript is an excellent solution to most of the problems mentioned. In particular, functional data structures & approaches are a great fit for coordinating dependent updates to a UI based on events happening to a base state - for a concrete example, the Om wrapper around React is very slick, performant, and idiomatic.

clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is implemented in javascript and can run on nodejs,then maybe i will consider it.

wouldn't it make more sense to implement the clojurescript compiler in clojurescript so it can run on node?

i get disliking having to fire up the jvm versus a light runtime like python or node if that's where you're coming from, but i don't mind twiddling my thumbs for a moment when i first sit down to write clojure, because not just the language but also the libraries and tools are more fun/interesting to use than a pure node (or pure python, for that matter)두environment.

in short, and not to be snide, perhaps you've already written some clojurescript, but to anyone else reading over: try writing some clojure/clojurescript. you might not like it for whatever reason, but at least then it'll be a case of "no return" instead of "no go."

Re: The JavaScript Problem

#88

Post by jmspring »

AnthonyMouse wrote: post #62
jmspring wrote: post #41

Earlier quoted context omitted.

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

The issue is that the "compile to" thing shouldn't be another programming language at all. It should be something like Java bytecode. Except not actually Java bytecode, because Java bytecode was made specifically for Java. You want something designed to be an intermediary representation between code in any arbitrary language and native instructions for any arbitrary architecture. In theory you could use Javascript as…

I agree something w/ "byte code" would be that thing. Said "byte code" would deal with types and such.

Now-a-days that "thing" is "javascript" and it has implementation nuances that depend on browser/runtime environment.

Re: The JavaScript Problem

#89

Post by ehsanu1 »

camus2 wrote: post #71
girvo wrote: post #10

I've been trying to convince my workmates to try something other than pure JS (with Angular), but am not having much luck. TypeScript seems to have the most buy-in, but most of the guys in the office aren't convinced of the benefits of a proper type system, the just see it as more work for them for little upside. Any ideas?

Typescript is hard. It's module system is a mistake(it should be module system agnostic,not AMD or CommonJS),and very confusing. The biggest problem is javascript is so dynamic you cant create type definitions for every library outthere and expect the typesystem to work. Typescript is good if you are porting something from AS3/C#/Java to javascript,or if You want to model a complex domain,without touching the DOM api…

Umm, no experience with typescript here, but can't you use the type annotations from the DefinitelyTyped project [1] to avoid everything becoming `any`? There are open source type annotations for all major (and many minor) libraries, including jquery [2].

[1] https://github.com/borisyankov/DefinitelyTyped

[2] https://github.com/borisyankov/DefinitelyTyped/tree/master/j...

Re: The JavaScript Problem

#90

Post by tim333 »

jmspring wrote: post #41
kenjackson wrote: post #32

Earlier quoted context omitted.

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a…

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

I guess Google's Dart is trying to go that way. Not sure it's going to get there though.
Post reply on HN