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

81–90 of 167 posts

Re: How it feels to learn JavaScript in 2017

#81

Post by alayek »

serpix wrote: post #47

Having used only re-frame and Clojurescript for two years now every time I look at where the Javascript guys are I roll my head. Is nobody even slightly wondering how OOP has infiltrated modern JS development? Old school Java web development has fully seeped into Javascript with JSX replacing JSP, OOP everywhere.. It looks exactly like the bells and whistles of early 2000 web development.

> Is nobody even slightly wondering how OOP has infiltrated modern JS development?

I would like you to give an example of this. We use the class-syntax, yes, but inheritance usually never goes beyond one level of parent-class-child-class relationship.

If anything, the JS community at large hates OOP the traditional way, and somewhat open to the prototypical pattern.

The ecosystem actually prefers functional constructs. At the very least, an attempt to write pure functions.

Re: How it feels to learn JavaScript in 2017

#82

Post by SquareWheel »

dolphone wrote: post #72
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…

I stick mostly to JS + jQuery, but I see nothing wrong with using additional tools when the situation calls for it.

If you're going to be writing a lot of CSS, then using SASS might save you some time and improve readability. If you're writing a webapp, then a SPA or React app might be the best course. And if it's image heavy, then a tool to automatically compress images would likely make sense.

If this is too complicated to manage, then other tools like task runners or Webpack can help automate the process. Node packaging can be used to sync settings across all project owners.

Taken on their own, it seems like a lot of complexity. But if you're only adding tools when you need them, it's really not that bad.

I wrote my last site in Jekyll + SASS. No Webpack, no gulp, no React. I just didn't need them, so I avoided the complication.

I'm glad they're there if I decide I want them, though.

Re: How it feels to learn JavaScript in 2017

#83

Post by Silhouette »

JimDabell wrote: post #74
aphextron wrote: post #55

Earlier quoted context omitted.

>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…

Edge superseded Internet Explorer

Microsoft might like to think so, but until all our business clients agree with them, the real IE is still a significant limiting factor in deploying with any JS feature you can't effectively polyfill.

Re: How it feels to learn JavaScript in 2017

#84

Post by mattacular »

alayek wrote: post #79
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.

Safari 10 and the current iOS version support tail recursion (and 99% of the ES6 spec)

Re: How it feels to learn JavaScript in 2017

#85

Post by alayek »

ko27 wrote: post #49
aphextron wrote: post #45

Earlier quoted context omitted.

>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. I'd say they've made JS development bearable , but great is really stretching it. We still don't have a type system, static analysis, multi-threading, first-class IDE support, or any of a myriad of other features that are standard in any modern programming language in 2017…

> 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.

> JS has service workers

Do you mean Web Workers? https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Re: How it feels to learn JavaScript in 2017

#86

Post by nol13 »

dolphone wrote: post #72
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…

But the core language really is that much nicer to program in when you can freely use object destructuring, spread operators, and some of the newer built-ins, etc.

Re: How it feels to learn JavaScript in 2017

#87

Post by vturner »

mercer wrote: post #59
user5994461 wrote: post #50

Earlier quoted context omitted.

Have you ever done desktop UI? It does your checklist for 2 decades.

I've done stuff with Delphi back in the day, but I'm not too experienced. Would you mind explaining point by point how desktop UI 'does' this? For example, I can't really think of a desktop app where most of the crucial app/UI logic is reliant on async communication with a server. Most data is stored locally and permanently. I'd actually really like to hear because I have been eying native development lately!

Young developer here too, but I started about a decade ago with robotics/desktop development. Thus, I can sympathize with the comment earlier that desktop UI has done all this:

clients that range from tiny phone screens to full desktop screens -- Desktop UI could support this if developers wanted to its just resizing a window. You just don't see it because devs assume the existence of a mouse which allows easing panning in a scroll bar window.

- incompatibility when it comes to what features clients support, and even how they support it - Desktop UI has or had solutions: Swing, JavaFX, QT, Adobe's Flex.

- serious limitations in payload file size for the entire UI codebase: There have been desktop XML UI for so long. The oldest I can recall would be Adobe's that went along with ActionScript to build Flex apps.

- much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'. -- The desktop analogy here is some long running process. Whether that is a slow disk, long computation, or some network access, desktop UI solved this a long long time ago with a rendering thread and worker threads.

- backend systems that are not optimized for these kinds of things - not sure what you mean here.

Re: How it feels to learn JavaScript in 2017

#88

Post by mattacular »

dolphone wrote: post #72
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…

I still just use ES5 JS, jQuery for around 2/3rd of the frontend code I write. The remaining third is a split between simpler, more mature but decidedly unsexy frameworks like Backbone, Underscore, Handlebars and newer trendy babelifed React and Vue. Both are fine. I enjoy both still.

Some people would consider it a bad thing that eg. Backbone hasnt had a major version in years but it is still perfectly capable for many use cases and it performs well. Of course you have to have more experience and knowledge with JS and frontend development in general to get these results I think.

Re: How it feels to learn JavaScript in 2017

#89

Post by pjmlp »

mercer wrote: post #59
user5994461 wrote: post #50

Earlier quoted context omitted.

Have you ever done desktop UI? It does your checklist for 2 decades.

I've done stuff with Delphi back in the day, but I'm not too experienced. Would you mind explaining point by point how desktop UI 'does' this? For example, I can't really think of a desktop app where most of the crucial app/UI logic is reliant on async communication with a server. Most data is stored locally and permanently. I'd actually really like to hear because I have been eying native development lately!

I can think of native desktop applications on banks with 3 tier architecture, using DCOM and CORBA in the 90's, just as one possible example.

Re: How it feels to learn JavaScript in 2017

#90

Post by Kiro »

aaron-lebo wrote: post #73
Kiro wrote: post #67

Earlier quoted context omitted.

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.

But how does Mithril know that status changes? How does it know you just changed the variable?
Post reply on HN