_uhtu

Can you elaborate a bit on what you mean?

After working with React/Inferno and some of the other virtual dom frameworks, I simply can never go back to templating languages baked into HTML. While this seems like a nice idea, I don't think I could use it for that reason. It's incredibly limiting to try to write your code into HTML with a small programming language built in. You spend more time fighting the embedded language then making content.

So recalculating the virtual DOM is fast, but it does have a cost. The easy way to combat this cost is to realize that if you're doing things right and using pure functions, you'll get the exact same UI if you're state hasn't changed. So if you know the state that feeds into a certain component hasn't changed, you can get much better performance.

This library basically encourages you to use React's "PureComponent", which automatically does that calculation to see if the props have changed for you, thus giving you a huge speedup since only the components that need to update will.

I could see the plugin system working, but we're years away from that. So saying JS/TS will be deprecated soon is still pretty incorrect.

To run python on WebAssembly you would have to compile the entire CPython executable, and every single dependency it has, into WebAssembly, then ship that giant executable with every page so you could then run Python code with it. You would then also most likely need a special library, which at some point someone will have to write or you'll have to write it yourself, to give Python a clean interface to the DOM. All of this together would be at absolute minimum 4.5 megabytes, which is absolutely unacceptably large for a frontend bundle.

WebAssembly is very cool techonology, but it's not going to deprecate Javascript because Javascript will be, at least for a very long time, the only scripting language that runs efficiently on the web, and also will always be the most well supported.

With WebAssembly you could write in any AoT compilation language that can compile on LLVM, but I, and many many other developers, have no interest in very low level languages like C, C++, or Rust in the browser, even though we acknowledge the flaws in JS. Maybe one day higher level languages besides Javascript will be practical, but that's a ways away.

Yeah, one person flying to your wedding would do much more than all the paper invites combined.

This article mentions that had the US not entered World War I the likelihood of World War II happening was much lower.

I'd like to propose the idea that World War II, in all it's horrificness, saved us from much worse.

In a rather bizarre and twisted sense, we may be very very lucky that WWII happened and that it happened at the exact time that it did: happening late enough that we saw how awful modern total war is, but not so late that we would have the weapons to truly eradicate ourselves.

Well of course, I was more just asking what his ideal process is to funnel out candidates up til that point. Whiteboard interviews? Take home interviews? What's your strategy?

So in the case of trial jobs how do you narrow down the candidate pool to the point that you have few enough candidates that you can bring them in office and let them work for a day without the office just becoming an unmanageable Fiesta?

Is there a reason why they decided to store time as seconds from 1970? In a 32-bit integer nonetheless. It seems like basic logic would have lead the original designers to make it at least 64 bits so that you'd never overflow it (with a 64 bit time we'd be good til the year 292277026596).

64 bits would also allow you to also cover the entirety of history, all the way back to 13.7 billion years ago when the Universe came into existence, but instead the UNIX time format is shackled to be within ~68 years of 1970.

Well you can't even compile Ruby, Python, Node, or Perl to WASM, since you can't compile dynamic scripting languages to LLVM. You could, for example, interpret Python by compiling the CPython interpreter to WASM (though that would mean an absurd bundle size), but this doesn't solve your problem since the python garbage collector is in the CPython source and you can't just remove it nor can you use a different langauges garbage collection because every language represents objects differently.

Different langauges demand different features in the implementation of a garbage collector. A garbage collector that every language implementation could use would basically be a set of functions that languages could use to implement their garbage collectors, but at that point the library would be tiny and the per-langauge implementation of garbage control would be huge.

Ruby still has significant use in web development due to the huge popularity of Rails. Startups and established companies continue to start and maintain projects in Rails.

Beyond that Ruby isn't used much. But a language that's extensively used for one very common purpose is very very far from dead.

HTTP/2 is pretty much everywhere now, including virtually all mobile devices. So targeting HTTP2 is pretty sensible IMO.

Could you tell me a bit more about why you want to write C++ in the browser? What things are you doing that are so CPU intensive that C++ is higher productivity then just JS?

I'm a bit lost on the appeal of webassembly. I can see why it's kinda cool to be able to ship a different language to browser and retain performance and bundle sizes, but the problem is I, and everyone else I know, has little to no interest writing C/C++/Rust in the browser.

Most of the people I know want to write Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser: high level scripting/VM based langauges which require no memory management and have high level features and data structures. As far as I can tell, these can't target WebAssembly since they don't target LLVM (and you certainly will never be able to compile a language like Ruby to LLVM)

I'd love to hear some of you guys talk about what uses you have for Webassembly and what exciting things it will let you do.

An article completely about the portraits of Shakespeare which only shows one of them is a pretty big design misstep I think...

The last 2 ECMA releases (2017 and 2016) have felt pretty dull honestly. I wonder if their approval process for features is too slow. In 2016 we got almost nothing, power operator and array.includes(). 2017 We finally got async functions, which have been in consideration for years now, a few helper functions, and shared memory. Object Rest/Spread would have probably made up for it, but now we'll have to wait at least another year even though it's been stage 3 for quite some time.

With the language moving this slow compared to faster releasing languages like Python, Elixir, and Go, I wonder if Node.js will start to see a decline in hype since the language hasn't improved much in the last 2 years. What do you guys think?

The United States can't be a functioning democracy not because of it's size but because our actual political rules are awful. The electoral college, built in gerrymandering, weak restrictions on lobbying, the rules of our democracy are immensely undeomocratic when compared to other first world nations.

Journalist these days feel that every single title needs to be as shocking as possible because they are desperate for you to click.

I've learned to hate the words "baffled", "shocked", etc. because journalists basically spam them for clickbait.

Really? It gave me a great grasp of the language and syntax and I was able to write some basic things immediately after, and anything I didn't know how to do (like communicate over a socket, etc.) I could google search.

The book "Learn you a Haskell for great good!", Which is in my opinion an essential read for someone wanting to get into functional programming, describes it as "imperitive is when you tell the computer a sequence of operations to get a result. FP Is when you tell the computer what thingsare.

I think it should basically be required reading for any programmer, it's a very easy to follow look into the functional paradigm. It's also free to read online! http://learnyouahaskell.com

The number of methods in the standard library really doesn't impact performance in a compiled language since you can tree shake the stuff that isn't used. And even if you don't tree shake having lots of methods isn't really a noticable performance loss in compile to binary languages since you don't need to spin up a VM

These are better points that actually have something to do with the article. I may have seen harsh in reply to the parent comment, but that's because that comment didn't address the article whatsoever, nor did it add anything to the discussion like you did.

I don't have a perfect answer for you, but this article is a great place to start. Focus on the fundamentals of the language first, then the tools he provides here will let you build apps. The reason things are this complicated is because JS basically comes with basically no standard library and the need for javascript escalated extremely quickly before tooling could catch up. Now there's been a tooling explosion so it can be hard to find out what's best and how to learn it.

Get started with simple scripts, learn the Javascript basics he talks about, the built-in functions and classes, ES6, etc. Then move on to basic DOM manipulation, then the frameworks like React to let you build more complicated features without worrying about the DOM nodes themselves.

"how do you have enough time to observe it and test it properly in production or wherever?"

I certainly don't have time to use them in production, but with most I just look at the documentation and see what I think of the philosophies they use. Once you know the fundamentals of the language, simply reading their examples usually gives a pretty good idea. Then if I want to try it I'll download example code, mess around with it, and see what does what.

"I don't see a new framework every month as a good thing, the frameworks don't mature in your environment and neither does my deep understanding of the framework"

I'll give an example of why I think this is a good thing. React has been around for about 3 years ago and at this point it's probably the thing most people are going to go for when they are starting a new app. It's mature, robust, well tested, and well proven. It's a rock in the JS world that brings new features occasionally but doesn't break past features and remains strong and consistent. There has also been an explosion of frameworks that use the same philosophy as React, declartive UI that is expressed as a function of state, and resolved using a virtual DOM. These can't really compete with React yet, but they have helped improve React. For example, Inferno, which has almost the exact same API as React, has some great tricks for extremely fast rendering, and the people who work on React have expressed interest in using those ideas.

In the end, yes there's a new framework every month, but the tools that people are really using in production aren't really changing too quickly. Focus on the things that are mature, and there isn't much fatigue to wrry about.

"People in the JS world, at least to me seem like, hmm, this does not sound cool anymore let's change it up with this."

Guilty as charged. Part of the reason for this is that it's so easy since every computer has a browser and trying something can be as simple as adding a script tag. I love trying new things, though in the end in production I've been writing in React with Webpack, Babel, and some of my own self-built libraries for a while now without much changing since not much about that needs to change. I remember trying out Redux when it got big and loved the ideas so much that I wrote a similar state management tool that fits my needs better, and I've added that to my app but haven't changed much in the grand scheme of things to do it. I basically just learned some principals and applied them.

I meant the coding style, not the threading model. Like the author talks about, one of the nice things about the threaded languages is that you basically just write normal, synchronous looking code and get asynchronous results. async/await lets you do basically the same thing.

That's simply not true. I'm kind of tired of hearing about this kind of stuff said about JS. This comment adds absolutely nothing to the discussion about this article.

Did you even read the article before making this comment? It would appear you didn't since this is just a classic, low effort javascript bashing comment that mentions no evidence from the article.

Every single thing he marks as important to learn is either

1. a mature library that has been around for years and is used in production at hundreds of companies (React is 3 years old and Angular is 6 years old, Lodash is 4 years old, Node is almost a decade old)

or

2. is a fully specced and largely implemented feature of the Javascript language.

How is Ajax gong to be obselete before you finish reading? How is Node, a nearly decade old, battle hardened runtime going to go out of style in 2017? By literally any definition JS builtins, functions, closures, callbacks, Chrome Dev Tools, React, Angular, Tern, ESLint, npm, git, Redux and Promises are all "mature robust solutions". They've all been around for years and are thoroughly tested and used. Many of them are used maturely in other languages as well, for example Futures in C# are basically the same thing as Promises.

The author does mention some newer things like async/await, generators, and ES6, but all these are now official parts of javascript. They simply can't "go obselete", and all of these share ideas with other languages which are also, by any definition, mature and robust.

The author does mention some libraries which are new and less proven, like RXJS, Angular2, MobX, Vue, Yarn, Typescript, and Flow, but did you notice how every single one of these has an asterisk? Which he specifically states means "strictly optional": Cool things to try out that may be useful tools, but not essential. Even most of these are several years old and perfectly mature anyway.

Yes the javascript community moves quickly. Yes JS programmers enjoy trying out flavor of the month frameworks, but it seems I'm one of the only people who sees this as a great thing. People try out lots of new things and learn lots of new strategies, and in the end the ideas of these get incorporated into existing mature frameworks, making them better and more robust.

I dealt with this. It's absurd. So many smart coding conventions are completely broken by this absurd convention.

Don't use Dynamo unless you for some reason have to. It's half assed and not getting many updates.

Comments don't change it from being valid javascript whatsoever.

With async/await (currently available and pretty stable in node, you just need the --harmony flag. You can also compile to it pretty effortlessly) you basically get the exact same code style you get in Erlang/Haskell/Other threaded models but with delicious event loop goodness.

It's there, it's just bound to alt-click instead of ctrl-click. And currently you can't rebind any keybinding with a mouse click on it, so you have to use alt-click.