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

91–100 of 167 posts

Re: How it feels to learn JavaScript in 2017

#91

Post by alayek »

aphextron wrote: post #45
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.

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

> We still don't have a type system, static analysis, multi-threading, first-class IDE support

Let me try to address these.

Regarding type system, lot of great languages don't have type systems either. But if there's lot of discussion on type systems, it would be because of Flow vs TypeScript.

As for static analysis, JS has seen evolution of JSHint, JSLint, JSCS, ESLint, and finally, Prettier. Flow is capable of performing type-checks with dynamic analysis.

I am not sure multi-threading is the hallmark of a modern language. Because Go, Elixir etc. are providing great concurrency without exposing threading API to the developer. JavaScript lets you do asynchronous tasks via callback, promises, generators, and latest - async/await. In the browser, you can use web-worker. But in most cases, you won't need it.

JS ecosystem has great code editors. I find VSCode to have good support out of the box, with breakpoint debugging. You can also use Atom, or Sublime Text, or Webstorm. If you're missing certain functionality, you can always add open-source plugins.

Re: How it feels to learn JavaScript in 2017

#92

Post by d0m »

revscat wrote: post #17

We have recently implemented Angular4 in our project, and have started to pick it up. Recently picked up a story that was adding a simple confirmation modal to a page: "Alert" text in the top, body with some warning text, and a yes/no button. This was my first experience with modern JavaScript frameworks and TypeScript. I wanted to do it right, so worked closely with team members who were more versed in this stuff, a…

Maybe a sign that things are too coupled through. Can make the same argument on any project, I.e. wanted to add small feature, ended up changing 27 files.

Re: How it feels to learn JavaScript in 2017

#93

Post by Silhouette »

oelmekki wrote: post #69
revscat wrote: post #17

We have recently implemented Angular4 in our project, and have started to pick it up. Recently picked up a story that was adding a simple confirmation modal to a page: "Alert" text in the top, body with some warning text, and a yes/no button. This was my first experience with modern JavaScript frameworks and TypeScript. I wanted to do it right, so worked closely with team members who were more versed in this stuff, a…

I've been doing heavy javascript interfacing since the end of the 2000' (it was still a rare skill back then, and made me good freelance money), and I totally understand how you feel. I experienced the same thing when learning angular, flux and redux. It all screamed "overengineering" to me. But then I realized why it was that way, and why it had to be : you now have teams of like 50 js developers working on the same…

The example you edited in makes your point very well. Essentially, you're describing a simple MVC design, with a couple of React-specific details for rendering your view.

In desktop world, we were using this sort of software architecture decades ago. It's only a combination of modular design, separating state from presentation, and an observer, and these are all well-established principles that have stood the test of time. Countless developers have written something like this at the start of countless new projects, and they probably did it in five minutes without a second thought.

The difference In modern JS world is that some people talk as if you need 197 dependencies, a whole build process and a team of 5 just to maintain it. You really don't, and the frameworks and build systems that push in that direction make my head hurt.

Re: How it feels to learn JavaScript in 2017

#94

Post by expertentipp »

vturner wrote: post #16

"I have to confess, the build setup is the most intimidating part of modern web development for me." Here here.

It cannot be simple - it's there to intimidate the new employees/team members. The setup is never wrong, but "the way we do it here" - a particular initiation ceremony. Those indocile will be reported to line manager as bad team members who undermine the team spirit. Usually a junior QA person and a scrum master are the gatekeepers of the setup, green build, and the history of git commit messages.

Re: How it feels to learn JavaScript in 2017

#95

Post by Silhouette »

pjmlp wrote: post #89
mercer wrote: post #59

Earlier quoted context omitted.

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.

Oh, you're an evil person for bringing those up. Now I'm going to have COM and CORBA nightmares for days! It still blows my mind that we managed to write half a screenful of code, essentially just to call a function.

On the bright side, I will never forget a manager of that era who was very good with buzzwords but not so good with the technologies behind them. We had some existing software built using COM, Microsoft had just announced the first version of .NET (though no-one quite knew what .NET actually meant yet) and the Internet was taking off as a mainstream technology for the general public. The manager in question would wander around the department asking us if we were using this new .COM framework to build our new software...

Re: How it feels to learn JavaScript in 2017

#96

Post by gggdvnkhmbgjvbn »

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.

Yeah to me it read like porn dialogue. The first person narrator gives gentle instructions and every line from the naïve second party is unrealistically enthusiastic.

Re: How it feels to learn JavaScript in 2017

#97

Post by JimDabell »

Silhouette wrote: post #83
JimDabell wrote: post #74

Earlier quoted context omitted.

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

Okay, but that's an upgrade issue, not a dead-end issue like a lot of people would assume from being told that there's no plans to add it to Internet Explorer.

Features get added to new versions, not old versions. Organisations using old versions will need to upgrade to new versions to get the new features. That's true of anything. It just happens in this case that Microsoft decided to go from Internet Explorer 11 to Edge instead of going to Internet Explorer 12. Saying that there's no plans to add support to Internet Explorer is like saying there's no plans to add support to Firefox 50 – true in a technical sense, but in practice, of course they add new features to new versions rather than old versions, and of course organisations have to upgrade.

Re: How it feels to learn JavaScript in 2017

#98

Post by pygy_ »

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

Earlier quoted context omitted.

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?

By default, Mithril redraws the app after DOM events fire (in this case `onchange={filterHandler(func)}`), and when ajax requests are complete (using the `m.request()` XHR wrapper).

You can also manually trigger a redraw by using `m.redraw()`, but it is rarely needed.

Re: How it feels to learn JavaScript in 2017

#99

Post by Silhouette »

onion2k wrote: post #66
aaron-lebo wrote: post #23

Earlier quoted context omitted.

OK, so it's a dozen. https://stackoverflow.com/questions/25920941/how-do-i-overla... Didn't say not to use a framework. Use it and some CSS and that's a basic task, not to mention there are other libraries which do it for you already.

Does that work in several versions of different rendering engines that date back a decade, at resolutions from 800x600 to an iMac 5K screen? How about on tablet and mobile devices? What happens when the user's scroll position is half way down the page? Does it listen for events to update or close itself? A good modal library is going to weigh in at a few thousand lines of code across JS, CSS and HTML for a reason. If…

A good modal library is going to weigh in at a few thousand lines of code across JS, CSS and HTML for a reason.

No. Sorry, but that's just nonsense.

A modal is probably going to be rendered as an HTML div element, styled so it appears with a fixed centre-viewport position.

You probably also want a second div as an overlay to de-emphasize the rest of the page while the modal dialog div is visible.

You might want a standard X button to close the dialog, which hides the above when it's clicked.

You can write all of that in less than a screenful of code, and you can do it using nothing but basic web standards that are supported as far back as IE8 and iOS5 -- in other words, well before the browser generations that even Microsoft and Apple themselves still support today.

Re: How it feels to learn JavaScript in 2017

#100

Post by lewisl9029 »

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 love create-react-app too, but for a slightly different reason:

They have an excellent, super-comprehensive README that covers practically everything you'd ever need to know about state-of-the-art Frontend JS tooling: https://github.com/facebookincubator/create-react-app/blob/m...

create-react-app itself is great for quick prototyping, but for non-trivial apps, chances are, eventually some esoteric production concern will force you to "eject". At that point, the sheer volume of configuration you'll be left with will be rather overwhelming if you've never dealt with the underlying technologies before, and modifying/extending it can become rather intimidating.

My recommendation is to start your first few projects with create-react-app, to get a feel for what a modern JS dev experience feels like, and then once you find the need to eject, instead of actually ejecting, copy your code over to a new project starting with just a bare minimum Webpack + Babel config, like the one in react-hot-loader-minimal-boilerplate (https://github.com/wkwiatek/react-hot-loader-minimal-boilerp...) and refer to the ejected configs of the create-react-app version of your app and the create-react-app README to port over pieces of tooling that you feel are sorely missing from your create-react-app days, one by one. This way, you'll be left with a much simpler and leaner tooling pipeline that you fully understand and one that you'll be able to extend and maintain much more easily.

I usually refer to the react-hot-loader-minimal-boilerplate config as a baseline simply because I consider es-next transpilation and hot-reloading essential parts of the modern Frontend dev experience. If you don't, you can totally start with something even more barebones.

Post reply on HN