Live data from Hacker News

How it feels to learn JavaScript in 2017

medium.com

51–60 of 167 posts

Re: How it feels to learn JavaScript in 2017

#51

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…

For type systems you have Flow and TypeScript, coming with their IDEs. The Chrome devtools and various plugins helps having a good IDE too. Multi threading is possible but rarely used because the concurrency model of JavaScript is event based.

Overall, I think JavaScript has a very rich ecosystem because, if you do Web programming, you do not really have alternatives to JavaScript. So the community made the language support various programming styles, tools and libraries.

I do not believe WASM will help bringing more language to the Web than today because it is already possible to compile to JavaScript with good enough performances for most use cases.

Re: How it feels to learn JavaScript in 2017

#52

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.

A language without a proper stdlib and with programmers who have no idea what the O notation is about has no place in any serious programmer's "to learn" list.

Re: How it feels to learn JavaScript in 2017

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

Not ludicrous, but ridiculous.

Re: How it feels to learn JavaScript in 2017

#54
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 suspect your frustration is due to your team. However Angular isn't helping either: http://jasonwatmore.com/post/2017/01/24/angular-2-custom-mod...

A good set of components for your library of choice should make a modal dialog that works and has flexibility e.g. https://bootstrap-vue.js.org/docs/components/modal/

That said, a modal dialog can be very hard to implement, depending upon needs (centering in viewport, mobile devices, stacking multiple modals, form modals with popup controls above them, preventing tab key allowing focus to go to form behind, plus many other hard issues!)

Re: How it feels to learn JavaScript in 2017

#55
post #49

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.

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

Re: How it feels to learn JavaScript in 2017

#56
post #48

Earlier quoted context omitted.

UI is hard dude. It's been a solved (and re-solved) problem for decades.

But has it been solved if you take into account the various constraints/issues: - clients that range from tiny phone screens to full desktop screens - incompatibility when it comes to what features clients support, and even how they support it - a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers) - serious limitations in payload file size for the entire UI codeb…

https://en.wikipedia.org/wiki/NeWS

Re: How it feels to learn JavaScript in 2017

#57
post #52

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.

A language without a proper stdlib and with programmers who have no idea what the O notation is about has no place in any serious programmer's "to learn" list.

[deleted]

Re: How it feels to learn JavaScript in 2017

#58
post #2

I submitted this after 'brlewis linked it (it's his piece) in a comment because it really hit home. Like, I've never used Mithril, but I dove into React (both web and React Native) this year and it reminds me of when doing web stuff was fun . Which, for me, was before anyone was actually using JavaScript . There are a lot of skeptics about modern JS frameworks, and I get it (my inclination in every programming enviro…

You know a lot of people are terrified of change and new stuff because it might mean their skillset is obsolete. That's a lot of what this backlash against JS is. Some of the criticism is warranted, but a lot of it isn't, it comes from people who have never done anything other than sneer at the language, and for every issue JS has, you can find a matching issue in another language that either a) isn't a problem becau…

> You know a lot of people are terrified of change and new stuff because it might mean their skillset is obsolete. That's a lot of what this backlash against JS is. Some of the criticism is warranted, but a lot of it isn't, it comes from people who have never done anything other than sneer at the language, and for every issue JS has, you can find a matching issue in another language that either a) isn't a problem because there are idiomatic solutions or b) everyone in the choir knows it's dumb but they don't say it to outsiders, because why advertise your weaknesses?

I think a lot of the "sneering" is less about fear of "new" things and more about frustration that old ideas that they previously considered are now being presented as "new" by a generation of people who either did not see themselves or did not ask an oldster about the old ways.

The tell for me, is in what things get the most sneered at. Node and npm tend to get a lot of sneering, because they're essentially attempts at solving problems people had already solved before. People don't sneer as much at other things like React (except for its license and large number of dependencies, and the latter is really npm/language sneering).

Re: How it feels to learn JavaScript in 2017

#59
post #48

Earlier quoted context omitted.

But has it been solved if you take into account the various constraints/issues: - clients that range from tiny phone screens to full desktop screens - incompatibility when it comes to what features clients support, and even how they support it - a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers) - serious limitations in payload file size for the entire UI codeb…

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!

Re: How it feels to learn JavaScript in 2017

#60

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 then you have to "eject", which means that all configuration files are dumped in your directory for you to edit, and you basically don't use create_react_app anymore. You now have to get webpack and babel configuration right to make your changes, but you have a solid basis.

Nowadays, I try to never eject, and see create_react_app as a lib providing everything I need. It sometimes prevents me to try new staged js features, but on the other hand I often have new features on update that I didn't bother enough about to eject in previous version.

Such wrappers around build system are probably the way to go. I would love to see something like create_react_app but allowing to provide buildpacks, so we can find in the wild the perfect configuration for our taste.

Post reply on HN