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 »

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

Wheany posted:

The correct syntax is
JavaScript code:
class Butt {
    fart = ( )) =3 
}

lol

Also is your new av the muskman?

Depressing Box posted:

That looks like class instance fields, which last I heard are in Stage 1. Babel supports them via transform-class-properties.

Ah, thanks for putting a name to it

# ? Apr 28, 2016 16:12

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 13:27

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Munkeymon posted:

Also is your new av the muskman?

It's from this, the greatest music video of all time: https://www.youtube.com/watch?v=kwxIGe1oOJQ

# ? Apr 29, 2016 07:27

damnfan: Jun 1, 2012

Written on mobile so apologies if formatting is bad.

So I have a JSON file with about 400 elements in the format:

code:


[
  {
    "Icon":"Rusty Sidearm.png",
    "Name":"Rusty Sidearm",
    "Quote":"Still Works. Mostly.",
    "Quality":"N",
    "Type":"Semiautomatic",
    "Notes":"Starting gun of The Hunter. Does not reveal secret walls."
  },
...
]

Currently I iterate through each element in the JSON with a for loop creating an object for each entry. After that it creates a div, anchor and image tag. The image is appended to the anchor, which gets appended to the div. I use isotope.js to insert them to the container div. The JSON contents are added to that.

This results in the page being empty for about a second or so until everything is populated.

Should I be using a template engine for this or should I just create a big HTML file with all the contents on the page already? The page contents would be rarely updated.

# ? Apr 30, 2016 01:42

Depressing Box: Jun 27, 2010; Half-price sideshow.

damnfan posted:

Should I be using a template engine for this or should I just create a big HTML file with all the contents on the page already? The page contents would be rarely updated.

If all that information is static, using an an HTML file generated from the JSON is probably the right solution. Make some kind of script to handle the HTML generation so you can just update the JSON file and rerun the script as needed, like a really simple static site generator.

# ? Apr 30, 2016 02:08

damnfan: Jun 1, 2012

Depressing Box posted:

If all that information is static, using an an HTML file generated from the JSON is probably the right solution. Make some kind of script to handle the HTML generation so you can just update the JSON file and rerun the script as needed, like a really simple static site generator.

Thanks, I was thinking that would be the better solution.

# ? Apr 30, 2016 02:40

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

damnfan posted:

Written on mobile so apologies if formatting is bad.

So I have a JSON file with about 400 elements in the format:
code:
[
  {
    "Icon":"Rusty Sidearm.png",
    "Name":"Rusty Sidearm",
    "Quote":"Still Works. Mostly.",
    "Quality":"N",
    "Type":"Semiautomatic",
    "Notes":"Starting gun of The Hunter. Does not reveal secret walls."
  },
...
]
Currently I iterate through each element in the JSON with a for loop creating an object for each entry. After that it creates a div, anchor and image tag. The image is appended to the anchor, which gets appended to the div. I use isotope.js to insert them to the container div. The JSON contents are added to that.

This results in the page being empty for about a second or so until everything is populated.

Should I be using a template engine for this or should I just create a big HTML file with all the contents on the page already? The page contents would be rarely updated.

You shouldn't really need to iterate over the elements in the JSON file, you should just be able to parse the whole thing and get the array, and go straight to the div creation

# ? Apr 30, 2016 03:04

damnfan: Jun 1, 2012

Skandranon posted:

You shouldn't really need to iterate over the elements in the JSON file, you should just be able to parse the whole thing and get the array, and go straight to the div creation

I was using jquery's getJSON method to parse the JSON. I took depressing box's advice and made a static page which improved the load time from seconds to instant.

# ? Apr 30, 2016 20:22

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

So the normal way to do function stuff is like this:

code:

function(argument, anotherArgument) { ... }

but just a bit ago I found this in the Node.js documentation:

code:

(argument, anotherArgument) => { ... }

Are these two ways of doing things effectively the same? Is one appreciably better than the other? Because the second way seems really slick and I'd like to start doing it that way for my non-important, unnamed functions like Node.js callbacks but I worry that I might run into a problem later or piss off some sperglord or whatever.

Love Stole the Day fucked around with this message at 14:04 on May 2, 2016

# ? May 2, 2016 14:01

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Love Stole the Day posted:

So the normal way to do function stuff is like this:
code:
function(argument, anotherArgument) { ... }
but just a bit ago I found this in the Node.js documentation:
code:
(argument, anotherArgument) => { ... }
Are these two ways of doing things effectively the same? Is one appreciably better than the other? Because the second way seems really slick and I'd like to start doing it that way for my non-important, unnamed functions but I worry that I might run into a problem later or piss off some sperglord or whatever.

The latter is a new feature in ES6 called an arrow function. They are not exactly the same
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions

# ? May 2, 2016 14:05

qntm: Jun 17, 2009

Love Stole the Day posted:

So the normal way to do function stuff is like this:
code:
function(argument, anotherArgument) { ... }
but just a bit ago I found this in the Node.js documentation:
code:
(argument, anotherArgument) => { ... }
Are these two ways of doing things effectively the same? Is one appreciably better than the other? Because the second way seems really slick and I'd like to start doing it that way for my non-important, unnamed functions like Node.js callbacks but I worry that I might run into a problem later or piss off some sperglord or whatever.

Arrow functions capture this lexically, whereas regular functions have this as essentially a secret, invisible, extra named argument.

# ? May 2, 2016 14:10

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

Love Stole the Day posted:

So the normal way to do function stuff is like this:
code:
function(argument, anotherArgument) { ... }
but just a bit ago I found this in the Node.js documentation:
code:
(argument, anotherArgument) => { ... }
Are these two ways of doing things effectively the same? Is one appreciably better than the other? Because the second way seems really slick and I'd like to start doing it that way for my non-important, unnamed functions like Node.js callbacks but I worry that I might run into a problem later or piss off some sperglord or whatever.

In addition to what the other's said above, you can even do that for important, named functions!

JavaScript code:

const lol = (cow, bell) => `Needs more ${cow}${bell}`

# ? May 2, 2016 16:01

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

You will piss off people on old node versions. Node is like IE6 in that nobody ever upgrades it.

# ? May 2, 2016 16:42

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

Suspicious Dish posted:

You will piss off people on old node versions. Node is like IE6 in that nobody ever upgrades it.

Luckily there's a tool for that https://www.npmjs.com/package/nvm

Of course, it requires Node, because of course it does

# ? May 2, 2016 18:18

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

So I was looking at some code and came across a bunch of stuff like this:

JavaScript code:

function poop () {
   
    if (someCondition) {
        blah();
        anotherThing();
     } else
        ;

    if (otherCondition) {
        ;
    } else
        oneLiner();

}

I'm at a loss as to why one would do that. I'm curious if anyone else has seen that and the reasoning behind it.

# ? May 9, 2016 20:18

MrMoo: Sep 14, 2000

I've done the second one once because it was easier to read than !OtherCondition, the former I can only guess is from some crazy bug hunting session where every execution path "must be defined", i.e. dangling else statements and fruity indentation causing the programmer problems.

# ? May 9, 2016 20:34

Odette: Mar 19, 2011

Lumpy posted:

So I was looking at some code and came across a bunch of stuff like this:
JavaScript code:
function poop () {
   
    if (someCondition) {
        blah();
        anotherThing();
     } else
        ;

    if (otherCondition) {
        ;
    } else
        oneLiner();

}
I'm at a loss as to why one would do that. I'm curious if anyone else has seen that and the reasoning behind it.

That just seems like something that a switch statement would be perfect for, but I haven't seen the original code so ...

# ? May 9, 2016 22:06

geeves: Sep 16, 2004

Lumpy posted:

So I was looking at some code and came across a bunch of stuff like this:
JavaScript code:
function poop () {
   
    if (someCondition) {
        blah();
        anotherThing();
     } else
        ;

    if (otherCondition) {
        ;
    } else
        oneLiner();

}
I'm at a loss as to why one would do that. I'm curious if anyone else has seen that and the reasoning behind it.

Let me guess, this is an NPM project...

# ? May 10, 2016 00:23

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Lumpy posted:

So I was looking at some code and came across a bunch of stuff like this:
JavaScript code:
function poop () {
   
    if (someCondition) {
        blah();
        anotherThing();
     } else
        ;

    if (otherCondition) {
        ;
    } else
        oneLiner();

}
I'm at a loss as to why one would do that. I'm curious if anyone else has seen that and the reasoning behind it.

I once read that avionics coding ended up doing things like that, just to be hyper-explicit on how things work. I think most compiled languages would essentially get rid of them anyways, but is just taking up space in JS.

# ? May 10, 2016 01:43

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

geeves posted:

Let me guess, this is an NPM project...

No, but thanks for playing.

# ? May 10, 2016 14:30

Strong Sauce: Jul 2, 2003; You know I am not really your father.

geeves posted:

Let me guess, this is an NPM project...

what does this even mean.

# ? May 12, 2016 01:12

MrMoo: Sep 14, 2000

npm is the package manager for node.js thus some sort of " :lol:

JavaScript programmers" comment, a.k.a. leftpad.

# ? May 12, 2016 01:14

obstipator: Nov 8, 2009; by FactsAreUseless

Chrome disabled geolocation from non-https protocols. Is there a way around this such as a notification that asks your permission instead of just denying it outright?

# ? May 13, 2016 16:50

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

If the browser agent blocks it they block it. No getting around it except for maybe some developer settings override.

# ? May 13, 2016 17:01

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Let's Encrypt is free and every major browser has supported SNI for years. Simplest thing is just to enable HTTPS unless you're on some poo poo-awful web host.

# ? May 13, 2016 17:50

vardyparty: May 16, 2016

I need a definitive answer from the pros:

Semicolons or no semicolons?

Not using them looks cleaner and nicer like ruby or python code, but I feel dirty deep down.

How shall I proceed?

# ? May 17, 2016 16:54

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

vardyparty posted:

I need a definitive answer from the pros:

Semicolons or no semicolons?

Not using them looks cleaner and nicer like ruby or python code, but I feel dirty deep down.

How shall I proceed?

Every JS style guide I've ever seen calls for semicolons. Google's has good explanations of why you'd require them:

https://google.github.io/styleguide/javascriptguide.xml#Semicolons

# ? May 17, 2016 17:15

vardyparty: May 16, 2016

Vulture Culture posted:

Every JS style guide I've ever seen calls for semicolons. Google's has good explanations of why you'd require them:

https://google.github.io/styleguide/javascriptguide.xml#Semicolons

Thanks, that was my gut instinct, but I'm learning React right now and quite a few tutorials I see are leaving them out. Needed some conviction.

# ? May 17, 2016 17:24

sunaurus: Feb 13, 2012; Oh great, another bookah.

vardyparty posted:

I need a definitive answer from the pros:

Semicolons or no semicolons?

Not using them looks cleaner and nicer like ruby or python code, but I feel dirty deep down.

How shall I proceed?

code:

var a = [[0, 1],[2, 4]]
var b = a
[0].forEach(function (e) {console.log(e)})

Do you know what the value of b is in this snippet? Do you know what will get printed to the console? Will everybody else on your team know?
Semicolons are good!

# ? May 17, 2016 17:27

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

vardyparty posted:

I need a definitive answer from the pros:

Semicolons or no semicolons?

Not using them looks cleaner and nicer like ruby or python code, but I feel dirty deep down.

How shall I proceed?

JavaScript is meant to have semicolons at the end of lines, it is just not strict about it. You should use them.

# ? May 17, 2016 17:56

vardyparty: May 16, 2016

thanks guys

# ? May 17, 2016 17:58

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

Skandranon posted:

JavaScript is meant to have semicolons at the end of lines, it is just not strict about it. You should use them.

Speaking of, you should 'use strict'; as well.

# ? May 17, 2016 19:39

Strong Sauce: Jul 2, 2003; You know I am not really your father.

This semicolon talk is always the same. The answer should be choose whatever works best for you.

The argument that semicolons protect "newbies" against the ASI is often stated but it's incorrect. Adding semicolons won't help someone in this case. Learning how ASI is implemented will.

code:

function a() {
  return
  { 
    b: 3;
  };
}

Google's reasoning/examples don't seem that great. They literally even say that in their comments.

Handwaving away ASI by saying just add semicolons is bad. Especially to beginners trying to understand why they need semicolons. All the examples they use aren't great examples of good code, and misses the one example where semicolons will not help them. It is better to just teach them good practices (or force them to learn about the ASI).

# ? May 17, 2016 23:14

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I'm sort of ambivalent about semicolon free code, I prefer to write it myself but will happily write code with semicolons if I'm suppose to.

A linter that enforces code structure is far more important than semicolons vs no-semicolons. Most of the issues where people get bitten by ASI inserting/not inserting semicolons comes from code that was already poorly formatted and structured to begin with.

Looking at all the examples in the Google Styleguide, they are almost all entirely contrived to bring out ASI errors, the only one that is borderline is the first IIFE, and even then that makes little sense to exist where it does.

code:

-1 == resultOfOperation() || die();

Like code like this, anyone who writes it instead of an if statement is already making fundamental errors about formatting their code, embedding side effects in what look like expressions.

Cute poo poo like this is what makes code unreadable and hard to maintain, absolutely nothing to do with semi colons.

# ? May 17, 2016 23:28

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Maluco Marinero posted:

Looking at all the examples in the Google Styleguide, they are almost all entirely contrived to bring out ASI errors, the only one that is borderline is the first IIFE, and even then that makes little sense to exist where it does.

I agree with this in principle, but I also think code merge whoopsies cause these sorts of problems a lot more commonly than people readily admit. Reasonable automated testing should catch these problems well in advance of a production issue, of course.

# ? May 18, 2016 01:49

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Vulture Culture posted:

I agree with this in principle, but I also think code merge whoopsies cause these sorts of problems a lot more commonly than people readily admit. Reasonable automated testing should catch these problems well in advance of a production issue, of course.

Yeah, code merge whoopsies are a thing, but if you're not inspecting and running the code post the merge, again, something else is fundamentally wrong.

I think people will have their preference of course, but there are far more important things to bikeshed, this is just a consistency thing for choice. (as in a codebase should be one or the other based on internal standards)

# ? May 18, 2016 02:32

Huzanko: Aug 4, 2015; by FactsAreUseless

Can anyone tell me if I should bother using WebPack?

After some cursory research it seems like things like WebPack and Browserify fundamentally change your development since they leverage require() on the front-end. Honestly, if I even am understanding the situation correctly, I don't feel like marrying my development process to a specific build tool is very smart.

I, as I'm sure many are, am sick of all the build tools. Gulp is easy enough and I feel like it makes my development a little easier after some simple config. Bower seems useless these days in the face of NPM. Webpack and Browserify just seem like complicated bullshit that stalls actual development, and yes, I know, if you are proficient with them they no longer stall you, but time spent on learning a build tool is time NOT spent on bettering your programming skill or learning a new language or framework. Build tools shouldn't be stupidly complex in the first place; when poo poo is more complicated than Ant and Maven you're doing it wrong.

# ? May 19, 2016 14:27

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Noam Chomsky posted:

Can anyone tell me if I should bother using WebPack?

After some cursory research it seems like things like WebPack and Browserify fundamentally change your development since they leverage require() on the front-end. Honestly, if I even am understanding the situation correctly, I don't feel like marrying my development process to a specific build tool is very smart.

I, as I'm sure many are, am sick of all the build tools. Gulp is easy enough and I feel like it makes my development a little easier after some simple config. Bower seems useless these days in the face of NPM. Webpack and Browserify just seem like complicated bullshit that stalls actual development, and yes, I know, if you are proficient with them they no longer stall you, but time spent on learning a build tool is time NOT spent on bettering your programming skill or learning a new language or framework. Build tools shouldn't be stupidly complex in the first place; when poo poo is more complicated than Ant and Maven you're doing it wrong.

You use webpack and don't use require. You use ES6 modules and use npm to manage your packages.

In this way, you're not tied to webpack, its just basically a way of shimming ES6 module support into the browser. If browsers ever support modules in a good way then you just stop using webpack and your code works the same way basically. So, you're not tying yourself to a specific build tool, you're tying yourself to the future of Javascript.

(of course this is JS web tooling so nothing is ever really that easy)

Webpack isn't more complicated than Ant and Maven, you're just familiar with them so it seems like it.

Also, you should use webpack instead of browserify. I started out using browserify and regretted wasting the time learning it if only because it seems like all of the examples for stuff I'm interested in have examples in webpack rather than browserify.

# ? May 19, 2016 15:35

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

Noam Chomsky posted:

Can anyone tell me if I should bother using WebPack?

After some cursory research it seems like things like WebPack and Browserify fundamentally change your development since they leverage require() on the front-end. Honestly, if I even am understanding the situation correctly, I don't feel like marrying my development process to a specific build tool is very smart.

I, as I'm sure many are, am sick of all the build tools. Gulp is easy enough and I feel like it makes my development a little easier after some simple config. Bower seems useless these days in the face of NPM. Webpack and Browserify just seem like complicated bullshit that stalls actual development, and yes, I know, if you are proficient with them they no longer stall you, but time spent on learning a build tool is time NOT spent on bettering your programming skill or learning a new language or framework. Build tools shouldn't be stupidly complex in the first place; when poo poo is more complicated than Ant and Maven you're doing it wrong.

You should use Webpack. Webpack is the Least Awful� js build tool. I think it actually borders on good! If an idiot who went to art school like me can learn it and be efficient with it, you can too!

I came across this guide a few weeks ago, and I think it's really well done, so read it instead of listening to me: http://survivejs.com/webpack/introduction/

# ? May 19, 2016 15:47

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

What's the magic word/setting to get Webpack to use ES6 modules? It just threw errors when I tried so I went back to calling require.

# ? May 19, 2016 16:09

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 13:27

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Munkeymon posted:

What's the magic word/setting to get Webpack to use ES6 modules? It just threw errors when I tried so I went back to calling require.

Sorry, I wasn't very clear.

You have to use babel with webpack to use ES6 modules.

Randomly googled article: http://jamesknelson.com/using-es6-in-the-browser-with-babel-6-and-webpack/

Lumpy posted:

You should use Webpack. Webpack is the Least Awful� js build tool. I think it actually borders on good! If an idiot who went to art school like me can learn it and be efficient with it, you can too!

I came across this guide a few weeks ago, and I think it's really well done, so read it instead of listening to me: http://survivejs.com/webpack/introduction/

I wish I had read this when I was first figuring out webpack.

Thermopyle fucked around with this message at 16:22 on May 19, 2016

# ? May 19, 2016 16:20

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

«‹›277 »