Earlier quoted context omitted.
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 bec…
How it feels to learn JavaScript in 2017
161–167 of 167 posts
Re: How it feels to learn JavaScript in 2017
#162Earlier quoted context omitted.
> 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. > By the time all was said and done the PR for this thing had 27 files in it. Can you not just use a library for this and do it in a few lines...? I found Angular 2 verbose but I don't see how the above is common. I just did something similar in Vue today and i…
Or, perhaps instead of a library, use the built in browser confirmation dialog?
Re: How it feels to learn JavaScript in 2017
#163Earlier quoted context omitted.
> Well, OK, but by that argument almost anything is just an upgrade issue, so I'm not sure that really gets us anywhere. That makes no sense. My argument is very narrow, clearly applies here, and I don't see how it applies to "almost anything". > In particular, it doesn't solve the practical problem that even with all the recent developments in the JS ecosystem, as things stand today a lot of front-end web developers…
Maybe we're talking at cross-purposes, but you seem to be saying that (a) it doesn't matter that there was no support for a feature planned for IE, because it is planned for Edge and (b) IE and Edge are essentially the same browser, and one is just the upgrade for the other. I contend that this is what Microsoft's marketing department would like everyone to think, but the reality in larger organisations (and for thos…
For all practical purposes, Edge is the next version of Internet Explorer. New features aren't being added to Internet Explorer 11, only to Edge. Yes, Edge has higher system requirements than Internet Explorer 11, but that's not relevant to my point. The same was true of Internet Explorer 9, which didn't run on Windows XP, but that didn't mean Internet Explorer 9 wasn't the next version along from Internet Explorer 8 or that it was "a completely different browser" or "a completely different product". It just means it's got higher system requirements, that's all.
The only thing the higher system requirements mean in practice is that the timetable for upgrading is delayed for some organisations. Those that aren't on Windows 10 will upgrade later than those that are. This means that it's not a blocker for using service workers, just a pretty typical delay while we wait for organisations to upgrade. As I keep saying, it's just an upgrade issue.
Saying that Microsoft aren't adding support for service workers to Internet Explorer while leaving out the massive fact that this is because Internet Explorer is the legacy version and they are adding it to the next version along, Edge, gives a radically different impression to what is actually happening. It implies that we'll never be able to use service workers because a major browser vendor isn't supporting it, when the reality is the opposite – that Microsoft are adding it to the next version of their browser and that all web developers have to do is wait for people to upgrade.
This is then compounded by the claim that Apple are doing the same thing – which is also untrue. Apple are adding service worker support to Safari right now, you can even go and look at the code yourself.
Yes, I understand that in terms of IT operations, the upgrade from Internet Explorer 11 to Edge is not without its complications. But it doesn't matter to the point I'm making. This is an upgrade issue, not a "multiple browser vendors have killed service workers" issue.
> If you're going to contend that a missing feature in one product is only an upgrade issue because you can change the entire OS and then install a completely different product to do the same job and then get that feature then I don't know what wouldn't be "just" an upgrade issue.
Changing from a previous version of Windows to Windows 10 is an upgrade. Changing from a previous version of Internet Explorer to Edge is an upgrade. It's quite clear why I'm calling this an upgrade issue, and I don't see how you can think that logic applies to things other than upgrades.
An example of what wouldn't be an upgrade issue is what I am explicitly contrasting against here. Two major browser vendors refusing to implement service workers wouldn't be an upgrade issue. If Microsoft and Apple won't add support for service workers to their browsers, then developers can't just wait for people to upgrade because newer versions won't include support either.
That's why it's so relevant to say "hang on, that's not right, both Microsoft and Apple are adding support to the latest versions of their browsers". It's the difference between service workers eventually being usable with a great deal of cross-browser support, and service workers being dead outside of small niches.
Re: How it feels to learn JavaScript in 2017
#164That article is focused on React/JSX. Having coded Nuxt/Vue apps I seriously can't relate. With Nuxt you don't even have the build/setup pains. It just works. It just builds.
Re: How it feels to learn JavaScript in 2017
#165It 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.
I too, am learning JS in 2017, and I can't wait to go back (to cljs). Or away, to anything else. I had done some basic stuff before, but for the last days I have been writing some code for a larger SPA.
Just as an example, today I needed to do the simple task of iterating over a dictionary. I expected it to go roughly like this:
dictionary.forEach(this.someMethod);
Instead, this is apparently what passes for sane in JS world, in 2017: for (var key in dictionary) {
if (dictionary.hasOwnProperty(key) {
this.someMethod(key, dictionary[key]);
}
}Re: How it feels to learn JavaScript in 2017
#166We 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…
Re: How it feels to learn JavaScript in 2017
#167It 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 impossible to go back. I too, am learning JS in 2017, and I can't wait to go back (to cljs). Or away, to anything else. I had done some basic stuff before, but for the last days I have been writing some code for a larger SPA. Just as an example, today I needed to do the simple task of iterating over a dictionary. I expected it to go roughly like this: dictionary.forEach(this.someMethod); Instead, this is appar…
Object.entries(dict).forEach(fn)
Or _.entries(dict).forEach(fn)