191–200 of 225 posts
Earlier quoted context omitted.
TypeScript is very close to normal JavaScript. It's basically just JavaScript + type annotations which a compiler can check. Compilation phase removes the annotations, after that point it is pure JavaScript. How are Swift and Haskell relevant for client side web development? Edit: Removed Elm
Elm's only target is the browser/JS.
Earlier quoted context omitted.
I can't believe people still bash JavaScript. I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back. I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language. Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like…
I can't believe people still bash JavaScript. I can't believe people actually like it. It might be understandable if you're comparing it to enterprisey Java, but I'm baffled that anyone could prefer ES5 to Python or Ruby. (I will acknowledge that ES6 puts it somewhere in the area of Python 2.5). It's an incredibly powerful, expressive language. Not if you want super advanced features like a hashtable with non-string…
Also, there is something to the whole "modules are records/hashes" idea which is quite elegant, IMO. I'm not sure why we still put up with the idea that the module system needs to be a whole different language with different rules. But I'm not sure if there is a type system capable of modelling this very well.
Earlier quoted context omitted.
Then you're not writing JavaScript, which was OP's concern. TypeScript is fine (although Elm, Swift, and Haskell are more interesting, IMO).
TypeScript is very close to normal JavaScript. It's basically just JavaScript + type annotations which a compiler can check. Compilation phase removes the annotations, after that point it is pure JavaScript. How are Swift and Haskell relevant for client side web development? Edit: Removed Elm
And I think it is only a matter of time till someone writes a Swift-to-JS compiler (Apple might already have it on it's radar).
[1]: I know it is not a "build/dependency manager", but I don't know how to call better in for sake of this discussion.
Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. I always feel like the most obvious use for it is to start writing truly hateful and abusive code. I'm sure this is because I'm getting old.
Earlier quoted context omitted.
I'm sorry, this is going to be a rant. Feel free to ignore if you don't care about my opinions on the subject. The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. It's why we use JSON or XML instead of ASN.1 for our daily work. The open web is a web where no company is the gatekeeper. It's a web where we have mul…
> The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier. This is about as true as the idea that the only use of seeing source code is debugging (or building/deploying your own version of the app). Which, of course, every developer here knows is not true. Reading source code is useful for figuring out how to do something you didn't know how to do. It's useful for di…
I'm always so frustrated when I read this, because I've worked on a few dynamic language codebases as well as seen a few open source ones on github. Very often I see the pattern of the project contributors losing control over the dynamic language project. They slip up, the tests become insufficient and now they refuse / are afraid to touch critical parts of the code. Soon development slows down to a crawl. Or rather, there are no more changes - only additions / grafts to the existing codebase.
When I first started using TypeScript, I feared that I'm going to lose the benefits of a dynamic language and that I'll have to write a lot more boilerplate. I had no idea how little of that was true. TypeScript really goes out of its way to model as many JS idioms as possible, including some really dynamic ones:
* Structural types are formalized duck type checking. You don't
have to say your object implements an interface: if it has all
the right fields, and they're of the right type, it does. This is
similar to Go interfaces (but a bit more powerful in what it can express).
* Unions types plus type guards can model dynamic function arguments
* Intersection types can model record (object) merging
Given the above, theres been absolutely no doubt in my mind whether TypeScript gave us an edge or not. Its been incomparably better than just plain JS.
Earlier quoted context omitted.
What makes WebAssembly like Flash? Please elaborate. You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force…
> What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right…
There's a big difference to strongly typed dynamic languages that go out of their way to catch programming mistakes at runtime. With JS you get some "wtf" result when things go wrong and it propagates a long way before manifesting (if it's caught at all). Combine with JS's many weird semantics and special cases that are hard to keep in mind at once...
Recent favourite (minimized case after discovering unexpected piles of NaN's in some faraway place)
> parseInt("0")
0
> parseInt("1")
1
> parseInt("2")
2
> ["0", "1", "2"].map(parseInt)
[ 0, NaN, NaN ]Earlier quoted context omitted.
The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.
I can't believe people still bash JavaScript. I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back. I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language. Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like…
And, no, JavaScript is nowhere near any "powerfull, expressive language". It is embarrasingly low level for a supposedly scripting language and it does not provide any powerful productivity features whatsoever.
JS is also a nightmare for the implementers, it does not have a sane specification, therefore most of the tooling is not comprehensive.
Earlier quoted context omitted.
I agree with you on some points, and disagree with you on others. > The open web is a web where no company is the gatekeeper. Absolutely! > The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. I think "view source" was essential to the web we have today. It's not just a technical solution to a technical problem -…
I learnt to write HTML files in the early 90's (The Geocities era as you refer to it - forget tables back then everything was frames). I learnt exactly how you surmised by using view source on existing websites. As a 13 year old kid who was mildly curious I was able to build a web site for my high school by hand in 'pure' html code. It looked laughably simple compared to the web pages of today but it was easy. I can…
Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. I always feel like the most obvious use for it is to start writing truly hateful and abusive code. I'm sure this is because I'm getting old.
Only if you miss the obvious and blatant technical and license differences.
Earlier quoted context omitted.
Web assembly doesn't add new APIs or capabilities to the web platform. It only makes code run faster and makes porting C++ code easier. What about that is hateful or abusive?
Sorry, my intent was not to imply that web assembly was hateful or abusive but that the code I might write using it falls into two categories 1. Performance critical code 2. Sneaky stuff I really don't want the user to be able to read. Category two seems like the sort of thing that I would absolutely want to be able to write binary code that executes without user interaction. It seems like right now the focus is quit…