Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

In what world did arrow functions make it worse. They make sure that the lambda captures this in the only way that makes sense (e.g. if we're in a class, this refers to the object)

# ? Nov 12, 2018 12:35

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 16:51

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Joda posted:

In what world did arrow functions make it worse. They make sure that the lambda captures this in the only way that makes sense (e.g. if we're in a class, this refers to the object)

By adding to the mental load of remembering how the this keywords works in every context. I agree that functionally the way this in arrows works is useful, I could have phrased that more clearly, sorry.

# ? Nov 12, 2018 13:42

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

That's true. It adds another dimension to a keyword that already has too many meanings. Tbh I never actually used it until ES6 and TS when it started having the same function as in any other OO language.

# ? Nov 12, 2018 14:07

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Joda posted:

That's true. It adds another dimension to a keyword that already has too many meanings. Tbh I never actually used it until ES6 and TS when it started having the same function as in any other OO language.

the arrow function changing the scope is a super-useful feature, but the issue is that arrow does so much, and it is relatively difficult to google. If Jimmy hasn't looked up what it does, it's entirely possible he will miss the scope implication of using the arrow function, and that'll take him down a rabbit hole for a few hours.

# ? Nov 12, 2018 14:34

akadajet: Sep 14, 2003

Bruegels Fuckbooks posted:

the arrow function changing the scope is a super-useful feature, but the issue is that arrow does so much, and it is relatively difficult to google. If Jimmy hasn't looked up what it does, it's entirely possible he will miss the scope implication of using the arrow function, and that'll take him down a rabbit hole for a few hours.

Any decent JavaScript introduction will take the time to explain this. So long as Jimmy isn't just throwing poo poo at the wall to see what sticks and doing some research about the language he is trying to use he should be fine.

# ? Nov 12, 2018 15:24

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

akadajet posted:

Any decent JavaScript introduction will take the time to explain this. So long as Jimmy isn't just throwing poo poo at the wall to see what sticks and doing some research about the language he is trying to use he should be fine.

Have you met 80% of software developers??

# ? Nov 12, 2018 16:15

akadajet: Sep 14, 2003

Lumpy posted:

Have you met 80% of software developers??

The guys I pass on when interviewing? Yes.

# ? Nov 12, 2018 18:20

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Joda posted:

That's true. It adds another dimension to a keyword that already has too many meanings. Tbh I never actually used it until ES6 and TS when it started having the same function as in any other OO language.

That never happened, though?

I mean, I know they added some syntactic sugar to make it look a lot like the class-based inheritance people are more used to - even with the class keyword, but it doesn't. It's a trick to get you to think that if you perform this ceremony with the class and constructor keywords, the language is suddenly doing class-based inheritance but it's not. It's still prototype-based and you still have to bind methods that care about having the class's this available.

The football is class-based inheritance in JS, you're Charlie Brown and the new syntax is Lucy.

# ? Nov 12, 2018 20:07

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Munkeymon posted:

It's still prototype-based and you still have to bind methods that care about having the class's this available.

For languages that are class-based you still have to bind a 'this' to a function you're referencing like a function pointer. In C++, for example, you have to call a member function pointer with an explicit this.
Any language that *doesn't* require you to do it is still just doing it for you in secret. The difference with Javascript is that it won't tell you you're doing it wrong, it'll just do the wrong thing.

# ? Nov 13, 2018 01:19

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

akadajet posted:

The guys I pass on when interviewing? Yes.

dude if you've never had a back-end developer who doesn't give a gently caress about front end / indian contractor / new kid out of school ever have to do a minor update to a UI... like, it's probably the least damaging thing that they could possibly be working on.

# ? Nov 13, 2018 03:52

smackfu: Jun 7, 2004

I know we have a lot of self taught JavaScript people who used to do Java and their understanding of JavaScript complexities is perhaps... lacking.

# ? Nov 13, 2018 04:38

Tea Bone: Feb 18, 2011; I'm going for gasps.

I'm pulling my hair out over this.

I have a selection box, depending on it's selection it should make the input in a following div disabled.

html:

code:

<select class="my-selection">
	<option value="1">One</option>
	<option value="2">Two</option>
</select>
<div class="input-container">
	<input type='text'>
</div>

Then the java script:

code:

$('body').on('change','.my-selection',function(e){
        if ($(this).val() === '2'){
            var content= $(this).nextAll('.input-container').first();
	    foo = content.find('input')
            content.find('input').prop('disabled', true);
        }
    });

For the life of me I can't get it to work. I can call .hide() on the input and it works and the really odd thing is, if I run foo.prop('disabled', true) from the console the input disables as expected. I'm guessing I've misunderstood how find/nextAll work.

edit: Never mind, I'm an idiot who had another function further down which enabled all inputs on form change.

VVV Thanks for checking anyway.

Tea Bone fucked around with this message at 16:29 on Nov 13, 2018

# ? Nov 13, 2018 14:49

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Tea Bone posted:

I'm pulling my hair out over this.

I have a selection box, depending on it's selection it should make the input in a following div disabled.

html:
code:
<select class="my-selection">
	<option value="1">One</option>
	<option value="2">Two</option>
</select>
<div class="input-container">
	<input type='text'>
</div>
Then the java script:
code:
$('body').on('change','.my-selection',function(e){
        if ($(this).val() === '2'){
            var content= $(this).nextAll('.input-container').first();
	    foo = content.find('input')
            content.find('input').prop('disabled', true);
        }
    });
For the life of me I can't get it to work. I can call .hide() on the input and it works and the really odd thing is, if I run foo.prop('disabled', true) from the console the input disables as expected. I'm guessing I've misunderstood how find/nextAll work.

Works for me https://jsfiddle.net/voa2jmeq/

# ? Nov 13, 2018 15:14

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

roomforthetuna posted:

For languages that are class-based you still have to bind a 'this' to a function you're referencing like a function pointer. In C++, for example, you have to call a member function pointer with an explicit this.
Any language that *doesn't* require you to do it is still just doing it for you in secret. The difference with Javascript is that it won't tell you you're doing it wrong, it'll just do the wrong thing.

Is it that common to call members functions/class methods as function pointers from other methods in the same class in C++?

And, yes, that's the rub: they made new syntax that looks like it does in other popular languages that automatically bind class methods to the object but you have to just know that that's still not happening and do it yourself manually. Really, they should have used prototype instead of class just to clarify that it's really an object with an optional initializer that makes prototype chaining less verbose.

# ? Nov 13, 2018 18:12

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Munkeymon posted:

Is it that common to call members functions/class methods as function pointers from other methods in the same class in C++?

Not any more, because now you'd generally just lambda it up, like you do if you're doing it right in JS.

But before lambdas, yeah, maybe not common, but not uncommon.
Edit: common enough that "member function pointer" is a thing at all. It's not like they have much other purpose.

# ? Nov 13, 2018 22:04

Rand Ecliptic: May 23, 2003; Jesus Saves! - And Takes Half Damage!!

Is there a general consensus on the best JS books? I spend a lot of time on the train without wi-fi, so I'd like some books to refine my knowledge.

I've heard good things about the You Don't Know JS series... anyone have experience with these?

# ? Nov 17, 2018 07:42

huhu: Feb 24, 2006

I've been developing in JavaScript for about 4 years now. I started learning it via jQuery and originally hated the language because I could never really understand jQuery. Moved from jQuery to React and along with learning all the new ES6 syntax, I really feel like I finally know JavaScript. I've been a full stack JS dev with Express/React for the past 6 months as well. With the background out of the way, I'm looking at building a toy project in Electron and I just worked my way through an intro tutorial. Here are my questions:

1. Is it worth it to learn "Vanilla JavaScript"? I feel like at this point I know a solid amount of stuff about JS. In the Electron tutorial I understand selectors and such but I'd much rather work with JSX and JS than deal with the actual intersection of HTML and JS.
2. Are React and Electron together a good idea? I'm looking through some tutorials now and I can't tell if React in Electron is a typical choice or if it's just something that people who know React do.

# ? Nov 22, 2018 23:08

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

huhu posted:

1. Is it worth it to learn "Vanilla JavaScript"? I feel like at this point I know a solid amount of stuff about JS. In the Electron tutorial I understand selectors and such but I'd much rather work with JSX and JS than deal with the actual intersection of HTML and JS.

I've not done React, but I went from jQuery to vanilla and find it less irritating because it doesn't have secret sauce behind everything you try to do, it just does what you ask it to. Though there are occasional irritations like checking whether something is 'visible' (ie. not hidden, not display:none, not size 0) is weirdly awkward with vanilla JS and there's a function for it in jQuery.
I know other people who mostly use React and find it a relief when they're allowed to just use vanilla JS.
A strong benefit of not using some framework is that vanilla JS seems much less likely to get changed out from under you and force you to rewrite a bunch of stuff. But maybe I've just been super unlucky with being burned that way literally every time I use any kind of framework for anything.

# ? Nov 23, 2018 06:30

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

One of the things I like about React is that most of your code is vanilla JS, so you�ve already picked up a lot. As for Electron and React, I don�t see why it would be a bad thing... React is a framework for front end views, so seems like a good fit. If you are using Redux or some other state manager, they are designed to manage app state, regardless of if it�s a web page or whatever.

# ? Nov 25, 2018 02:28

Roadie: Jun 30, 2013

If you use React in its simplest form, with stateless components for everything, it's fundamentally just a way for mapping a big set of nested functions to HTML output and getting high-performance automatic updating when you change the function inputs. The only weirdness to really watch out for is that the props are named after JS DOM properties, not the actual HTML attributes.

# ? Nov 25, 2018 02:47

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I don't know if I'm helping or not but my experience is that Vanilla is the best Javascript environment of all time. If it's in node I don't have to compile anything, as few dependencies as absolutely humanly possible, no nothing, it's more or less zen. As zen as Javascript can be.

For frontend you have to build for es5, I prefer really strongly the simplest tools possible. So buble for basic es5 sans IIFE, and then rollup to put that es5 with es6 imports into a single file. If I'm doing the build step then there's no reason not to basically use Vue (or React) really. If it makes sense and I'm not just using a whole bunch of tools when it's not necessary.

Wish I could use Vue with buble/rollup instead of webpack or similar colossal monstrosities that do way more than necessary.

# ? Nov 26, 2018 02:09

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

Why do you have to compile for ES5?

# ? Nov 27, 2018 15:24

necrotic: Aug 2, 2005; I owe my brother big time for this!

Browser compatibility?

# ? Nov 27, 2018 15:41

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

Are there any browsers except IE that haven't updated to at least ES6? Like sure, you might have to support that, but it's definitely not a general imperative as stated

# ? Nov 27, 2018 15:46

necrotic: Aug 2, 2005; I owe my brother big time for this!

Edge still has some warts, too. It would be great to target ES6 but it's still difficult when you need to support IE or Edge.

# ? Nov 27, 2018 15:48

necrotic: Aug 2, 2005; I owe my brother big time for this!

The need for roll-up or something similar is still pretty big, too. Which means at least replacing import statements with something else.

# ? Nov 27, 2018 15:49

MrMoo: Sep 14, 2000

Joda posted:

Are there any browsers except IE that haven't updated to at least ES6? Like sure, you might have to support that, but it's definitely not a general imperative as stated

Embedded hardware is still ES5 only, surprisingly all the digital signage from Samsung and LG are circa Safari 6.0 level browser tech.

# ? Nov 27, 2018 16:41

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I would say if you are compiling anyway you should compile for maximum compatibility, if there are no significant drawbacks to doing so.

# ? Nov 30, 2018 13:52

TIP: Mar 21, 2006; Your move, creep.

MrMoo posted:

Embedded hardware is still ES5 only, surprisingly all the digital signage from Samsung and LG are circa Safari 6.0 level browser tech.

Based on my recent testing, Safari 6 doesn't even support all of ES5. I was doing some testing on an iPad 2, which I think was Safari 9, and it required ES5 polyfills to get my code working.

I loving hate Safari.

# ? Dec 1, 2018 09:42

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

Nolgthorn posted:

I would say if you are compiling anyway you should compile for maximum compatibility, if there are no significant drawbacks to doing so.

Don't you lose significant performance potentially? Also I assume there is no way to make wasm compatible with an ES5 platform

# ? Dec 1, 2018 14:12

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Joda posted:

Don't you lose significant performance potentially? Also I assume there is no way to make wasm compatible with an ES5 platform

i haven't run into a case where compiling back to es5 hurt performance short of "oh, there are more characters so it'll increase the load time of the page."

emscripten can compile to either asm.js or webassembly, so you can provide both a web assembly version and an asm.js. asm.js can run in IE11 or Safari. the load times are a lot better for webassembly and IE11/Safari didn't run the asm.js stuff nearly as well as chrome did, but it might be possible to use it for simple use cases.

# ? Dec 1, 2018 17:12

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

I assume the entire point of using wasm proper (near native performance and threading) is lost if you compile to asm.js?

E: although I guess it still counts as technical compatibility

Joda fucked around with this message at 17:33 on Dec 1, 2018

# ? Dec 1, 2018 17:25

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Joda posted:

I assume the entire point of using wasm proper (near native performance and threading) is lost if you compile to asm.js?

E: although I guess it still counts as technical compatibility

it depends on your use case. even the asm.js demos can be pretty impressive from a performance perspective. the big issues with asm.js are:

a) There isn't a great way of telling how much memory you're using with asm.js
b) Initial load times

If we want to compare web assembly vs. asm.js performance.
https://blogs.unity3d.com/2018/09/17/webassembly-load-times-and-performance/

Webassembly has much better load times. The asm.js computational performance was already pretty good. Webassembly is an improvement but asm.js was already pretty good in that regard.

# ? Dec 1, 2018 18:27

Chas McGill: Oct 29, 2010; loves Fat Philippe

Say I want to gather the first 6 results from a YouTube API query and render them as embedded videos on a page, then update those results automatically once a week, what would the simplest approach be?

I thought about just doing the request onload, but I expect someone could refresh the page a lot and fill up my API limits.

# ? Dec 1, 2018 21:57

huhu: Feb 24, 2006

Chas McGill posted:

Say I want to gather the first 6 results from a YouTube API query and render them as embedded videos on a page, then update those results automatically once a week, what would the simplest approach be?

I thought about just doing the request onload, but I expect someone could refresh the page a lot and fill up my API limits.

Write a cron job to run once a week to fetch new data and store that in your database then just serve whatever's in there with the request.

Whatever you do, don't store you're API key in the frontend code.

# ? Dec 2, 2018 00:24

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Joda posted:

Don't you lose significant performance potentially? Also I assume there is no way to make wasm compatible with an ES5 platform

If you are building a video game in Javascript perhaps you should take performance into account. It might have an effect on performance. But modern computers, even really cheap ones can perform billions of operations per second, most of your processing is going to be consumed with draw calls.

Met somebody once, I was conducting their interview, and they wrote all of their loops in reverse.

code:

for (let i = 10; i >= 0; i--)

So I asked him why he was doing that, he said it was more performant. I tested it, and it wasn't. But even if it was, so what?

I can definitely appreciate having more performant applications. But you do that these days by limiting the number of dependencies you import, eliminate the bulk introduced by "general purpose" tooling. Don't write the code itself in weird ways for an imperceivable <0.1 ms performance boost.

Compiling to ES5 feels that way to me. There's no reason to be worried about reduced performance because of that alone, if there's performance gains to be made probably a good start is not using bootstrap for example. Or replacing javascript animations with css animations. Not using lodash' functional methods. Removing jQuery. That sort of thing.

Nolgthorn fucked around with this message at 20:09 on Dec 2, 2018

# ? Dec 2, 2018 19:55

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

A lot of my hobby projects are games and games systems, so that's sort of the head space I'm in, but I haven't actually played around with web based game dev yet.

quote:

for (let i = 10; i >= 0; i--)

A lot of people are still stuck in the mindset that they have to do these sorts of micro-optimizations by hand, when the compiler or interpreter or whatever is way more clever than you and is easily able to identify this sort of thing. As long as you're not looping through a linked list that is not continuous in memory, chances are you're not breaking your cache or anything like that, especially in a language like JavaScript.

Where I'm coming from it was more a concern with how the transpiler might use an alternative to an >=ES6 thing that wasn't optimised, or how the JS engine might be able to make some assumptions about your data based on the core lib functions you're using, and using those assumptions to optimize the run-time.

Joda fucked around with this message at 20:14 on Dec 2, 2018

# ? Dec 2, 2018 20:12

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

I'm not joking when I say that in several of my projects, I replaced for(let foo of bar) with for(let i = 0; i < bar.length; i++) let foo = bar[i]; to a significant performance boost. This was after I profiled and saw it was an issue, and then fixed it.

This stuff matters, it really does. The compiler can often do a really crap job with some of this stuff.

# ? Dec 2, 2018 20:18

Chas McGill: Oct 29, 2010; loves Fat Philippe

huhu posted:

Write a cron job to run once a week to fetch new data and store that in your database then just serve whatever's in there with the request.

Whatever you do, don't store you're API key in the frontend code.

Hmm I think I need a new host. Cheers for the advice.

# ? Dec 2, 2018 20:23

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 16:51

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

Suspicious Dish posted:

I'm not joking when I say that in several of my projects, I replaced for(let foo of bar) with for(let i = 0; i < bar.length; i++) let foo = bar[i]; to a significant performance boost. This was after I profiled and saw it was an issue, and then fixed it.

This stuff matters, it really does. The compiler can often do a really crap job with some of this stuff.

Wait, really? You'd think the array iterable if anything would be optimised in the engine

# ? Dec 2, 2018 20:32

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »