Finally , people will be able to get rid of javascript wholesale . No transpilation , asmjs whatsoever. It basically means that javascript will die in the long run and people will be able to use whatever language they want to use, actionscript , java , c# you name it. That's a game changer and it's a future standard , so no plugins.
> It basically means that javascript will die in the long run
Says who? I don't think it's going anywhere.
I for one will be happily programming in ES2015+ in the future, for many years to come. And I know I'm not the only one (have you ever been at a JS conference?).
Anyways WebAssembly is very much welcome. I can't wait to use python or haskell "natively" in the broweser.
> people will be able to get rid of javascript wholesale
Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases.
No other language is going to come with built-in tools for editing within browser/client dev tools. Modern JS is going to be one of the easy languages to get started on.
And of course, you totally underestimate the billions of lines of JS already written for the Web.
> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases.
ES6 isn't statically typed. It might be better for you , it is not for me.
> You'll have to compile instead.
Yes, and without caring about Javascript. That's the point. Javascript will become irrelevant when it comes to front-end development. One language cannot possibly satisfy everybody's needs.
If that was the case we would all be using nodejs on the server and that's hardly the case.
It's a pretty weak static type system, and it retains javascript's other warts (e.g. scoping). And if I'm going to have to do a separate compilation step anyway then I might as well use a nicer language.
> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness.
> ES6 isn't statically typed. It might be better for you , it is not for me.
So you are saying that because it isn't statically typed it's inherently worse in terms of expressiveness?
There's a valid argument that static typing has big advantages (navigation, refactoring) but it worries me when people write off dynamic code entirely.
Utter nonsense, he replied to a comment about expressiveness with [1], its only natural that I assumed he was saying that lack of static typing lead to lack of expressiveness.
[1]
ES6 isn't statically typed. It might be better for you , it is not for me.
It's more expressive in that it's more easily testable... To write testable code in C# you generally need to introduce complex classes, interfaces and IoC/DI into a project. JS allows you to work around this with generally less complexity of code. For the most part node/es6-style modules can be far more simple and easy to reason about than C# projects tend to be.
Don't get me wrong here, I like a LOT about C# but expressiveness compared to JS doesn't even come close, when you include the pending ES7 stuff via Babel.
Uhm, I'm not sure you correctly understand the point of Inversion of Control and Dependency Injection if you think that you don't need it in JS.
ES "let's you work around this" in that it let's you just do stupid shit until it blows up in your face. Statically typed languages force you to consider those scenarios that might lead to blow ups. You still have to consider those scenarios in ES, but the language doesn't force you to, so you have to have the diligence to do it yourself.
"Expressiveness" doesn't mean "write as little code as possible to get the base case running". Expressiveness means the ability to implement different patterns of solutions with native syntax. C++ is "more expressive" than C when it comes to object oriented programming, not because C cannot do OO, but because C++ has specific, checked syntax for it.
I'm not saying don't test... you can write modular code in JS... in fact you can export a single function as a JS module via node/browserify... take babel and you get es6/7 features. Use mocha/chai/sinon/proxyquire and you can inject dependencies into your modules for testing, without having to write weird interface abstractions in your code...
References are consistent and one-way, you no longer have to deal with searching for where a given dependency is coming from... Or where the implementation is... references are always direct this way.
C#:
using MyOrg.Base.Interfaces;
public class Foo {
public IBar Bar {get;set;}
public string Baz() {
//wth is IBar.Baz implementation come from?
//damn, now I need to search the project for IBar
return this.Bar.Baz(this);
}
}
JS
import bar from '../lib/bar';
export default function baz(context) {
return bar.baz(context);
}
In the JS case, you know where the implementation of bar comes from when looking into code, trying to resolve a bug. You can also use proxyquire in order to test the module, replacing bar with a shim for the purposes of testing... in the JS case the code is still clean, and you don't have a couple of layers of indirection abstracting you away from finding the next piece in the puzzle. And it doesn't limit your ability to test.
I don't know what you mean by "weird interface abstractions". Interfaces are how you test the edges between modules in statically typed languages. They are the contracts that get checked at compile time to make sure you're not sending IPAddress-es where DateTime-s are expected.
And I don't know what that last part is supposed to mean. I've never not know "where my dependencies are coming from" or "where the implementation is". It's not like they live in some hidden place that I can't access. I reference them directly and explicitly.
EDIT: you ninja-edited on me. No, you are not at a loss for where IBar is defined. It's extremely easy--a single key press--to find it. Just hit F12 on it. You'll go right to its definition.
Yeah, that takes me to the declaration of the IBar interface, but not to the implementation that's being used... The worst case is often when you have dependency injection along with something like EntLib's Data application blocks... it's a mess finding things on a project that you've been tossed in the middle of.
I'm not saying these patterns should never be used... only that there are generally simpler expressions that should usually be favored.
Having done a lot of reflection in both JS and C# (well, .NET really, it's a library and runtime feature, not a language feature), I think I can confidently say that .NET is light years ahead of JS when it comes to reflection. I don't think I've seen a system better than .NET's. Because of the way it is built, you can still write type safe code. That's impossible to do in JS.
I think people forget that, in JS, the types still exist. Just because it's not statically typed doesn't mean you don't have to think about types and what types are appropriate for given scenarios.
With JS, it's impossible to tell just from inspecting a reference to a function what it expects from you and what you can expect to give back. You have the length property to tell you the number of arguments and that's it. Of course, that's assuming it's not using a variadric arguments pattern, in which case the length value only tells you the minimum number of parameters expected, but not that more are possible.
Even if you can make reasonable assumption about the number of parameters, you won't be able to tell at all what types the function expects for those parameters. Want to list all the functions in a class that take two numbers and return a different number? Can't do it.
But still, if you could make reasonable assumptions about the type of things that go in and out of the function, you won't know how to even call the function. Does the function expect to be called as a method of a class? Does it expect to be called as a static function? The best you can hope for is to toString the function and check if the source includes the word "this". Here's hoping it's one written in JS itself and not one that is implemented internally in the browser.
Now before anyone says "why would you ever need anything like that?", it's an absolute necessity for building any sort of user-driven or data-driven reporting system. You need to be able to tell when your data set matches the functions you want to apply to them, at run-time, because the data isn't available at design-time. It's the classic reflection use case.
As far as I'm concerned, safety-guaranteed reflection is impossible in JS, unless you throw away JS functions almost completely and create your own Functor class with all the extra type information that you would need.
Or you could, you know follow either a naming convention or a parameter convention... For that matter, you can have each method simply test the data and return null if it doesn't apply and the resolved value if it does, or any number of other patterns...
For that matter, you can use an object stream, and pipe it all through to resolution. If your data comes from variant sources (spreadsheets, dirty xml, etc) then you are way better off with a scripted language.
Try importing a WSDL that defines various interfaces to use "Object" and VS/.Net chokes on it.
As far as users go, without the hard enforcements you can coerce values into either what you expect or cleanly drop out... unlike .Net where you have to go through the Try versions of convert, on who knows how many types in order to get something resembling predictable values... that doesn't even include regular expression syntax as a first class concept in JS.
I've handled dynamic input sources from both .Net (VB.Net and C#) and I'll tell you that most of the time JS/Node is simply easier... I've replaced complex importers written in .Net with straight forward, easy to reason with JS importers that run in Node, and edit/run/deploy without a compile step.
I will say that I do like that VB.Net has XML literals which can be very useful... but now that JSON is getting to be more common JS is less of a disconnect.
Naming conventions are a great way to end up with liar-code--code that isn't what it calls itself. Coercing user input into expected types is a good way to get exploits. Testing parameters explicitly is just asking for someone to forget a particular parameter, and just returning null instead of an error is how we end up with black-box functions that nobody can figure out why they get called in different places because they don't seem to have any particular use. WSDL is a different issue entirely; now you're talking about RPC (of which WSDL is just one format that .NET supports), which is not the same thing as reflection.
The things you're talking about doing, they are bad software design.
'Expressive' means that it's easy to write code that's easy to understand.
JS doesn't even come close to the expressiveness that you get in C# due to the fact that in JS, you don't even know the type of arguments being passed in any given function without looking elsewhere in the code - therefore, it's not easy to understand.
If you're going to go with the definition that says expressiveness means "the variety and quantity of ideas that can be expressed", Javascript also loses there since there are whole classes of behavior that cannot be practically expressed in Javascript. For instance - try writing a function that only accepts a standard single precision floating-point number as it's argument and see how much work you have to do compared to other languages.
Try expressing a Dictionary, Linked List, HashTable, SortedList, SortedDictionary, etc in JS - you'll be writing those structures yourself or cobbling together some random lib. Better languages let you actually express those things without having to write them yourself.
I tried JS multiple times. And every time, easy things are complicated when doing them in JS. It is much easier and faster for me to do those same things in C, even though I'm equally familiar with both. This is mostly because there are just so many gotchas.
Here are some examples from this week:
Checking whether a passed argument is an array or a dict:
var a = []
if (Object.prototype.toString.call(a) !== '[object Array]') ...
If you import a library, they could have modified the global scope. This is common in JS libraries. Then some things you wrote don't work.
undefined/null thing
differences between var declared function and regular named function.
Many things in the language are not obvious and you have to discover them through trial and error or study JS internals and find out how things are implemented.
As someone that wrote C/C++ for decades I hated JS. Now that I've gotten used to JS every time I'm forced to go back to C/C++ I hate Hate HATE IT.
Things that take 5 lines in JS take 200 in C++ all to make the type system happy. Yes I understand the trade offs. Wrote games most of my career. I used to find it cool that I could write a 400 line templated intrusive list class that generates just 1 instruction on use. Yippee. Now though I just resent the fact that have to write giant implementations like that for code who's performance doesn't matter.
In JS forgot a little piece of data? It's generally almost zero lines to hack it in. C++? It's often refactoring hundreds of lines of code.
Wanna to wrap some function to monitor it, test, sanitize, .. trivial in JS. Next to impossible without massive refactoring in C++
When I have to do C++ again I will but it won't be without kicking and screaming.
> Checking whether a passed argument is an array or a dict
Luckily solved in ES2015:
Array.isArray(thing)
The toString trick is pretty outdated, in ES5 you can also do:
thing instanceof Array
> (perhaps not js itself, but how it is used) Leaking DOM nodes are a thing
Definitely not JS itself, it's easy to create circular references between JS objects and DOM elements. It's just the way the DOM is (poorly) designed and the way it interacts with JS.
> for each (var myVar in myObject)
That's not even standard, just a Mozilla "dialect". I don't think that's supported by any engines other than SpiderMonkey and predecessors.
>The toString trick is pretty outdated, in ES5 you can also do:
> thing instanceof Array
instanceof is ES3.
> That's not even standard, just a Mozilla "dialect". I don't think that's supported by any engines other than SpiderMonkey and predecessors.
To quote MDC:
> The for each...in statement is deprecated as the part of ECMA-357 (E4X) standard. E4X support has been removed, but for each...in will not be disabled and removed because of backward compatibility considerations. Consider using for...of instead. (Please refer to bug 791343.)
for each (...) -> It's not supported anywhere, so forget it.
for (var x in a) -> x is the key, so it's kind of inconvenient. You have to watch out for inherited properties/methods so one should check for a.hasOwnProperty(x).
for (var x of a) -> It has mostly no gotchas. Only poor browser support.
.forEach only works with arrays and from ES5 on. You have the good old "this"/scope gotcha.
if (a instanceof Array) ...
// or polyfill
Array.isArray = Array.isArray || function(a) {
return a instanceof Array;
};
Object.keys can be cleanly shimmed without braking older browsers. You can always shim in the behavior you want, as long as you don't need IE7 support.
console.log("I lose and lose again, not even close.".replace(/\blose\b/g, "win"));
If you're using ES6 or node-style modules, you shouldn't generally mess with global state, unless you are polyfilling new features. Promises (bluebird), fetch, etc...
Understanding falsy values is a core part of learning JS, as is coercion... no it isn't perfect, but there are flaws in any language you can bring up.
As to a function assigned to a variable vs a function declaration, well again that's part of learning the language.... Being able to use functions as first class expressions is a very powerful feature, that frankly works pretty well.
Of the features missing from JS proper, an isolated invokable web-workers scenario with plain, side effect free functions/modules would be a great start (not the current way via secondary script).
That said, most of your complaints are things that are easier to work around, or simply things that you learn with the language. It's not that different from learning warts in Python (which is better than many), C#, Java or anything else.
See `Array.isArray` which you can polyfill however you like ... Beyond that, if you bring primitives from another frame, you kind of get what you deserve. Most likely you should check for not a string, but has `length` property that is a Number and use `Array.from` with your conditions, especially with arguments or dom collections.
Most likely when working across frames, you should use messaging, unless you're doing something truly hokey... In either case, working across frames like that is akin to poking into the memory of one process from another. It's bound to have issues...
I don't think this is something that WebAssembly would allow you to do in the first place...
The library is ramdajs.com and it can be grabbed from npm.
I do not agree that everything should be handled with standard libraries. It's better for these things to be modular and versioned, instead of them being pulled from a big bloated standard library.
The code clearly does what was being asked in a very simple and non-broken way.
Perhaps the issue here is that non-JavaScript engineers are used to kitchensink standard libraries and avoid mixing and matching to get the best experience the ecosystem offers.
You're building a straw-man there. A standard library can certainly be made to be modular and versioned. It doesn't have to be bloated for any reason whatsoever. This is Javascript - you can chop up your scripts however you want.
The problem with mixing and matching libs is that no two JS devs do it the same. Some will even re-build the same lib that has already been built by hundreds of JS devs because NIH.
> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness.
It's hard to compare. Java is horribly verbose, but C# (and F# even more) is pretty concise these days, definitely comparable to JS if you factor in the increased lines of code you need in a dynamic language to have any certainty when refactoring.
A lot of Java's verbosity has been addressed in Java 8. I would still call it terribly verbose if your codebase involved lots of OO-style structures (inheritance chains, factories, etc); but for more functional Java code it's got a feel to it that's very similar to C#.
> No other language is going to come with built-in tools for editing within browser/client dev tools.
I think you've confused the present with the future. No other language comes with that today. There's no reason other languages shouldn't in the future, however.
You totally underestimate the millions of JS coders who want something better than JS, who have been using JS because that's their only choice.
I think most coders would choose a language that has better tooling and robust standard library over Javascript which doesn't even have a standard library. This is certainly the death of JS.
Be able to use any language for the front end is great thing, but I have a concern for existing frameworks/libraries.
If someone build a great tool, lest's say the equivalent of D3.js, in Java; I don't see a way I can use it in python without having to write a python API for that library.
It's not necessarily bad. The first advantage being, that hopefully people are going to stop recreating new javascript frameworks every 2 months.
I don't see this replacing JavaScript. In fact, I believe it'll do the opposite - it'll make JavaScript more prevalent. If a company can deploy it's code to as browser-native blob it'd make a great deal of sense for developers and designers to be able to code things on top of it. JS is the obvious choice for doing that. And as a consequence, more developers from traditional desktop environments will need to get to grips with
how to use JS in a browser-WASM-as-a-sandbox situation.
Neat. I keep hoping for one of these to evolve into a more modern replacement for Silverlight or WPF. There's a lot to like about the .net ecosystem and having a plugin-less deployment story for it would be great.
I was really hoping that Silverlight would gain more traction than it did... for that matter, it's far closer to what I was hoping for when Adobe bought Macromedia. I had been hoping to see a new flash container format that was similar to what Silverlight became using SVG and MP3 with JS as it's main interfaces in an open structure (for the format and player), Adobe could have stayed king of tooling... Flash and Flex are still way better in terms of tooling for some relatively complicated presentations, simulations and the like for a browser than what you now need to hand code with current standards.
It really takes something like WebAssembly which multiple browser vendors back to get traction... Adobe was in the position to give us this almost a decade ago.
Does this bring in all of the MSIL for any .NET stdlib modules you happen to link in as well, or is there a dead-code elimination phase pruning them down to just what you use?
Yeah... I mean give me layers of interfaces, indirection and dependency injection that's hard to follow. Class structures that don't flow well for procedural workflows. Projects with dead end code paths because they are so big no one person understands even half of it. I mean, these are such great things.
I've totally missed them in modern JS development, and haven't been fighting against many of these practices for years now at all (/sarcasm).
Seriously though, my biggest issue with JS development today is people that don't understand patterns beyond what they use in C# and Java, and don't want to keep things simple and easy to reason about. Most C# and Java applications I've worked with have many layers of unnecessary complexity for the sake of, more because "that's how it's done in 'Enterprise' software" more than it is about what's truly needed.
I actually really like C#, and the thought of being able to use some of the features really appeals to me. That said, actually working with solutions common from .Net, I've been happier without it. I've spent the better part of my time the past 4-5 years migrating away from .Net solutions to Node based ones... once you get past people trying to implement overly complex patterns and embracing "the node way" of simple, composable, functional modules... it can and does go much more smoothly.
--- edit:
When I say complexity for the sake of... it's usually for the purpose of testability, often in scenarios that don't have tests, and beyond that aren't trying to target multiple implementations of an interface. Even then, with JS you don't need the added constraints. I know there are "contract" concerns, but what that gets you is WS-* and SOAP/WSDL hell that nobody really understands vs easy to reason REST/JSON services. In the end, having simple systems where you have to learn a bit of convention tends to be easier than complex systems with layers of indirection.
I've worked with both C# and JS for a number of years and to sum up why static typing is ultimately better than dynamic typing, is because of the type system which gives you compile time errors.
As programmers on the computer all day, the more work the computer does for us the better. With a type system the computer knows what the system is capable of, and so knows what you are doing - this means it can tell us precisely what members are available in 'foo' when you type 'foo.', and it can accurately tell us that 'bar' does not exist in foo when you type 'foo.bar'.
With systems of even minor complexity this is a godsend when you don't have to even read the documentation of a new API you want to use - you just use the autocomplete and contextual documentation to figure things out. It makes code fun again.
With dynamic typing, and especially with JS, the computer is mostly oblivious to what can/cannot be done and you end up having to ctrl+F on method names, mispell something and it just gets added as another variable to the type, you can't refactor variable names easily etc. It's pretty bad in comparison.
Static typing isn't all perfect though - sometimes types do get in the way where I wish more dynamic features would have been available. But at least now if C# etc can be used for webdev, then solving these problems will become something people will invest time in and we will finally see new innovation again - instead of yet-another-javascript library/hack.
I have also been doing C# and JS for years and completely agree. JS is nice for prototyping because of the light footprint but as soon as your code gets more complex it becomes a problem to manage/maintain, far from impossible, just harder. From this perspective TypeScript is a godsend.
If you look at the FAQ and test cases this is a direct mapping to things wasm currently has, thus: no GC objects, just primitive values and direct heap access.
WASM models memory as a big array which is your heap, all memory management within that is up to you. There is no GC, there is no new / delete or anything else. For the use case of porting C programs to your web browser this is fine, for higher level languages you're a bit stuffed.
I hope WASM gains some sort of GC eventually, because writing a GC in WASM will make me cry. :-(
Would anyone be kind enough to explain what exactly I'm looking at here? I'm very familiar with C# but only have a very simple understanding of the idea behind WebAssembly.
The WebAssembly design repo (https://github.com/WebAssembly/design) has a bunch of high and low level details. Essentially, wasm is a spec for an instruction set and runtime environment for native apps, and it's designed so that existing JavaScript runtimes can support it. This will eventually let it solve most of the problems currently solved by asm.js, NaCL, and (to a lesser degree) NPAPI.
While writing C# with strong types for the browser is a nice idea, this project won't give you strongly typed access to the web api e.g. window. JSIL, which this project is based on, gets around this by making window and other objects available by the dynamic keyword.
You can still strongly type everything within your project but creating a complete strongly typed wrapper to the web api would be a big job.
Yup, but reposts are fine when an item hasn't had significant attention yet (see https://news.ycombinator.com/newsfaq.html). That helps offset the random churn of /newest, which otherwise causes many good stories to fall through the cracks.
