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

How it feels to learn JavaScript in 2017

medium.com

Post reply on HN
Print view View original

71–80 of 167 posts

Re: How it feels to learn JavaScript in 2017

#71

Post by lauritzsh »

aphextron wrote: post #55
ko27 wrote: post #49

Earlier quoted context omitted.

> type system, static analysis, first-class IDE support Agree, but we have TypeScript, also static analysis is done for ES6 module dependency > multi-threading This is wrong. JS has service workers, and sharred array buffers.

>This is wrong. JS has service workers, and sharred array buffers. Service Workers are not really threads as the runtime environment is still single threaded no matter what, you just have the ability to spawn a new process. On top of that browser support is sketchy at best, with no planned support for Safari or IE.

It is currently in development for Safari https://webkit.org/status/#specification-service-workers

Re: How it feels to learn JavaScript in 2017

#72

Post by dolphone »

seanwilson wrote: post #29

It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.

No one is complaining because its trendy. Rather, good JavaScript developers already know the core language plus jQuery and a framework or two. We can build websites without the extra stuff. We are tired of spending our time and energy learning technologies that are horizontal to what we have already mastered. We enjoy writing JavaScript and find it suspect when anyone complains about the language.

When we hear about frameworks and build tools we think http://m.imgur.com/gallery/2dykF3D

Re: How it feels to learn JavaScript in 2017

#73

Post by aaron-lebo »

Kiro wrote: post #67
brlewis wrote: post #64

Earlier quoted context omitted.

Static? That's half true. let planets; let planetFilter = planet => true; The planets variable is static in this example, but planetFilter changes. The "Voila, it works" link near the bottom of the essay leads to a live demo: https://brlewis.github.io/2017/planets.html Was there a particular aspect of state management you want to hear more about? I'm thinking of a follow-on post. Not sure whether the next one should…

Oh, you're right. The state management was so subtle that it actually didn't click when I read it. I don't understand how it knows to rerender though? From what I can tell you're just setting the variable planetFilter and that's it, while with React you would have to do a setState to register it.

You write your templates to handle the state changes, like:

   m('div, {style: `display: ${status ? 'block' : 'none'}`)
Mithril's diffing engine does the rest. If status changes it knows to rerender that section.

Re: How it feels to learn JavaScript in 2017

#74

Post by JimDabell »

aphextron wrote: post #55
ko27 wrote: post #49

Earlier quoted context omitted.

> type system, static analysis, first-class IDE support Agree, but we have TypeScript, also static analysis is done for ES6 module dependency > multi-threading This is wrong. JS has service workers, and sharred array buffers.

>This is wrong. JS has service workers, and sharred array buffers. Service Workers are not really threads as the runtime environment is still single threaded no matter what, you just have the ability to spawn a new process. On top of that browser support is sketchy at best, with no planned support for Safari or IE.

> On top of that browser support is sketchy at best, with no planned support for Safari or IE.

Apple is currently working on implementing it in Safari:

https://webkit.org/status/#specification-service-workers

It's misleading to say that there's no planned support for Internet Explorer – Edge superseded Internet Explorer so all new development is going into Edge, not Internet Explorer. Service Worker support for Edge is under development:

https://developer.microsoft.com/en-us/microsoft-edge/platfor...

Re: How it feels to learn JavaScript in 2017

#75

Post by tonysdg »

raldu wrote: post #43

The whole story felt sarcastic and also a little nauseous. Not exactly sure whether there is intended sarcasm or not. The process looks quite complicated where you have to figure out lots of "buts," "whys," and "gotchas," while keep telling yourself, "What the hell?" all the time.

It's likely because it's a reaction piece to this article [1], which is almost entirely sarcasm.

[1]https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

Re: How it feels to learn JavaScript in 2017

#77

Post by gggdvnkhmbgjvbn »

oelmekki wrote: post #60
seanwilson wrote: post #29

It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.

And even there it's not the pain it has been, if you write react app, thanks to create_react_app. It basically brings all of that out of the box, without any configuration needed, just like `rails new my_app_name` creates a ready to use app. Actually, I've seen several times people reporting using it for non react projects, just because of that ease of setup. Of course, you may still want to tweak configuration, and…

I like create react app a lot but i wish there was an easy way to add a second page. I tried doing this recently and found it was actually easier to implement react router with code splitting to avoid loading my main page's huge js file.

Re: How it feels to learn JavaScript in 2017

#78

Post by alayek »

A refreshing read. Was expecting a satirical negative take on the complexity.

However, this only covers a small part of front-end development with VDOM based approach, and a few ES6 constructs (destructuring, arrow functions, let-const).

The author misses out on mobile development, Node JS and NPM modules, server side, and Electron-based desktop apps.

It's a good thing to take the positive approach, and get introduced to some interesting, low-barrier-to-entry items. At the same time, it would be prudent to keep in mind what lies ahead.

Re: How it feels to learn JavaScript in 2017

#79

Post by alayek »

seanwilson wrote: post #29

It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.

Even better. You don't even need to set up a build system for async/await, ES6 modules (coming in Chrome 61) these days. Most modern browsers support a great portion of ES6+ specifications by default.

Live / Hot reloading might take some setup though.

One thing I am yet to see implemented, is tail-recursion. It's in the spec, but I am yet to find an environment that implements it. Please correct me if I'm wrong.

Re: How it feels to learn JavaScript in 2017

#80

Post by oelmekki »

gggdvnkhmbgjvbn wrote: post #77
oelmekki wrote: post #60

Earlier quoted context omitted.

And even there it's not the pain it has been, if you write react app, thanks to create_react_app. It basically brings all of that out of the box, without any configuration needed, just like `rails new my_app_name` creates a ready to use app. Actually, I've seen several times people reporting using it for non react projects, just because of that ease of setup. Of course, you may still want to tweak configuration, and…

I like create react app a lot but i wish there was an easy way to add a second page. I tried doing this recently and found it was actually easier to implement react router with code splitting to avoid loading my main page's huge js file.

I always do that, actually. I see what is provided in the App.js file as just a placeholder, meant to be replaced. Since you have webpack, you can import files from all over the place, deciding how to organize your project. It works just fine without ejecting :)
Post reply on HN