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 »

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

Yeah it ran for me on the Firefox Preview of Android but the results were both 0%. Never used that site so I'm not sure how well it works. Jsperf gives you more useful results than just a percentage in general.

# ? Jun 29, 2019 05:07

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 23:43

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

How many of you have implemented Hybrid Rendering + Hydration? If you don't know what that is, its where you serve your initial content statically and then allow future link-clicks on the page to be handled by an AJAX request and then you simply replace page sections based on the HTML string that comes back from the AJAX request. It can give you SPA-Like functionality while preserving maximum SEO strength and is actually the recommended way of doing poo poo from Google's indexing perspective. Anyway I've written a little engine to handle the whole thing complete with caching, history storage, and a render exception for links which're marked with the target property populated, as well as any link with the _no-re-render class, or any link inside a container marked with the _no-re-render class, and it also ignores buttons. Has anyone ever written anything like this or has some pro tips on how to do it really well?

# ? Jun 29, 2019 13:32

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

I've done it a bit with React. Not enough to feel confident in given you any advice other than to give you the keywords to search: SSR, server side rendering, universal apps, isomorphic apps. All of those terms refer to the same basic idea of rendering your React app on the server, sending the HTML to the browser, and then React hydrates on the frontend.

# ? Jun 29, 2019 18:06

tankadillo: Aug 15, 2006

That�s basically what Gatsby does, so you could check them out. I�ve never messed with it myself though.

# ? Jun 29, 2019 20:02

Volguus: Mar 3, 2009

Thermopyle posted:

then React hydrates on the frontend.

What does that mean? What's "hydrate" in the context of javascript?

# ? Jun 30, 2019 01:21

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.

Volguus posted:

What does that mean? What's "hydrate" in the context of javascript?

hydrating is filling an object with data. an object that has not been hydrated may represent an entity that has data, but hasn't loaded it yet. it's also possible depending on use case to "partially" hydrate objects - this may be used in orm context where only necessary fields may be hydrated instead of entire object.

# ? Jun 30, 2019 01:39

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

Volguus posted:

What does that mean? What's "hydrate" in the context of javascript?

In the context of SSR it's populating all the data and state so it can then take over control of the DOM in the same state it was rendered on the server.

# ? Jun 30, 2019 02:30

Volguus: Mar 3, 2009

Bruegels Fuckbooks posted:

hydrating is filling an object with data. an object that has not been hydrated may represent an entity that has data, but hasn't loaded it yet. it's also possible depending on use case to "partially" hydrate objects - this may be used in orm context where only necessary fields may be hydrated instead of entire object.

necrotic posted:

In the context of SSR it's populating all the data and state so it can then take over control of the DOM in the same state it was rendered on the server.

Thank you.

# ? Jun 30, 2019 03:07

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

I guess it probably is one of those things that should probably be done on a case by case basis.

# ? Jun 30, 2019 12:04

Happy Thread: Jul 10, 2005; by Fluffdaddy; Plaster Town Cop

Circling back again to the suggestion to use http://jsben.ch/

I have to warn people that the site does not seem to work as advertised at all, unfortunately.

Here I've got a simple test:

http://jsben.ch/MIMFF

I ran it, got a result, then as a sanity check I swapped the two experiments and ran it again. The result did not move with it! Worse still, I kept running it over and over and whether block 1 or block 2 was faster kept switching randomly between tests. Sometimes block 1 takes 80% as long, sometimes 90%, sometimes block 2 is the one that takes 80%. Not only is there seemingly no consistency, it doesn't even seem aware of which block is which.

I was already questioning this tool because there were already some red flags. As someone above said, the results are given as some unclear "percentage". As I pointed out above, if you re-run a test, the UI glitches out and initially shows a full progress bar instead of zero.

To me, the worst red flag is that jsbench was putting code block 1 and code block 2 into the same namespace, same scope, same actual code block with nothing enclosing them.

I know this because I had initially omitted the semicolon after block 1, and it complained about "invalid token const" in block 2 until I removed it. Next, for both blocks I had initially simply set "const b =....." but their parser complained that b had already been declared until I used a different name in each block.

Yikes!

# ? Jul 1, 2019 00:42

Happy Thread: Jul 10, 2005; by Fluffdaddy; Plaster Town Cop

I also looked as jsperf and it seems honestly antiquated. Most modern cloud tools are presented in fairly pretty websites and let you try them out relatively quickly upon visiting the page. The website is styled like something out of 2001 and lists out tons of unstyled form elements (including a whole lot of cluttersome optional fields) that you must fill in prior to running a single test. Even before that it requires access to your e-mail address and GitHub account.

It's a little nice because it publishes a graph collecting all that information that users entered into a particular test's URL, so you can see what browsers people were running. The results do not seem that informative, though. Take a look at this one:

https://jsperf.com/for-vs-foreach/75

Why is Chrome 52 shown as almost 3 times faster on all tests than almost all subsequent versions of Chrome? Perhaps the user with Chrome 52 just had a really fast computer. The real information that you're looking for, the comparison between different individual tests, is hidden one level deeper in tiny bars.

Isn't it flawed by running these tests client-side, on god knows who's machine with what specs and what else running simultaneously, rather than on some standard machine type server side on whichever top 10 common browsers & versions it has available?

Why isn't there some JS benchmark tool that offers to run your code on one or more standard (common) hardware setups they own, that runs your test server-side on as many browsers as they've got and returns back the comparison chart? Is this just an open power vacuum for some JS developer to fill?

# ? Jul 1, 2019 00:54

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

jsperf was having issues with spammers and added the requirement to sign in with GitHub to prevent it. I think their (lack of) design is fine: it's simple and does it's job, unlike the other one you've looked at.

As for running it on consistent hardware: this costs far more money and these websites are generally ran but one person with limited funds.

jsperf links to benchmark.js which is a library you can use to run however you want on consistent hardware.

# ? Jul 1, 2019 01:06

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

Dumb Lowtax posted:

Isn't it flawed by running these tests client-side, on god knows who's machine with what specs and what else running simultaneously, rather than on some standard machine type server side on whichever top 10 common browsers & versions it has available?

I always assumed the point of jsperf was so you could test whatever on your browser and between browser versions.

Testing on some standard machine type is kind of out-of-scope, and it would likely be a for-pay service anyway.

# ? Jul 1, 2019 03:28

Happy Thread: Jul 10, 2005; by Fluffdaddy; Plaster Town Cop

necrotic posted:

As for running it on consistent hardware: this costs far more money and these websites are generally ran but one person with limited funds.

...What do the really big web-dev companies do then? What happens when their devs want to know which alternative code block is faster? Surely not rely on free tools made by a hobbyist?

Wouldn't they have some automated solution that runs tests in multiple browsers for them? Preferably in a dedicated VM for it that isn't running other processes? Or if they're fancy, several VMs that can simulate different OS'es and hardware configs?

Web dev companies do performance testing, right?

Speaking of which, are tools like jsperf smart enough to handle the fact that I'm running lots of other processes and have tons of windows open? Can jsperf distinguish just the time spent inside the thread running JS from the other threads on my machine? Is it better than me just running a seconds stopwatch in real life to measure two versions of a really slow function?

# ? Jul 1, 2019 04:32

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

If a performance difference is too small to easily measure, it's so small that nobody gives a poo poo.

I hope this helps you in deciding which endeavours are a worthwhile use of your time.

# ? Jul 1, 2019 05:21

Happy Thread: Jul 10, 2005; by Fluffdaddy; Plaster Town Cop

Jabor posted:

If a performance difference is too small to easily measure, it's so small that nobody gives a poo poo.

I hope this helps you in deciding which endeavours are a worthwhile use of your time.

In many applications, especially graphical ones, the hot loop will be called like millions of times.

In that case the decision to use an alternate set of JavaScript features that's worth 10% savings can add up to like 50% if you can find a few separate such gains and stack them together in what was formerly inefficient code. Now your image that takes a minute to render can take 30 seconds instead.

Happy Thread fucked around with this message at 08:43 on Jul 1, 2019

# ? Jul 1, 2019 06:05

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Dumb Lowtax posted:

In many applications, especially graphical ones, the hot loop will be called like millions of times.

In that case the decision to use an alternate set of JavaScript features that's worth 10% savings can add up to like 50% if you can find a few separate such gains and stack them together in what was formerly inefficient code. Now your image that takes a minute to render can take 30 seconds instead.

Sounds like your next project is a tool to measure performance exactly how you want!

Stop complaining about free tools. If you don't like how it works either contribute or make one yourself.

# ? Jul 1, 2019 12:24

Ola: Jul 19, 2004

If you want to DIY some simple benchmarking, you can use:

JavaScript code:

console.time();
//code goes here
console.timeEnd();

Without knowing much about the JS engines, my little student experience with Java performance benchmarking is that a lot of optimization stuff happens under the hood that might not be obvious when looking at the code. For instance, I tried this:

JavaScript code:

test1 = function(){
	const list = [];
	for (var i=0;i<1000000;i++){
		list.push(i*Math.random());
	}
	return list;
}
test2 = function(){
	const list = [];
	for (var i=0;i<1000000;i++){
		const a = i*Math.random();
		list.push(a);
	}
	return list;
}
console.time();
console.log(test1().length);
console.timeEnd();
console.time();
console.log(test2().length);
console.timeEnd();

A typical result was:
1000000 default: 15ms - timer ended 1000000 default: 10ms - timer ended

However, if I swap test1 and test2, I get the same result, i.e. the first one takes a bit longer no matter which function actually gets run first. That was in Firefox using the SpiderMonkey engine. In Chrome's V8 engine I get faster results and a bit more even distribution between the tests.
1000000 43.635009765625ms 1000000 41.016845703125ms

And if you don't use the values for anything, you can run a billion iterations and it will just skip them all and finish in <1 ms.The point with all of this is just that you may not know for sure how or even how much of your code really gets run on the CPU. Lots of optimization happens under the hood. Try putting the most realistic loop of production code variants between the console timers. Swap the sequence around a bit, make sure you use the results for some output if it seems suspiciously fast. If you can't notice a particular difference, you might as well keep writing it the way you like it.

# ? Jul 1, 2019 13:17

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

Dumb Lowtax posted:

...What do the really big web-dev companies do then? What happens when their devs want to know which alternative code block is faster? Surely not rely on free tools made by a hobbyist?

Why not? Their js apps are written largely with free stuff made by hobbyists. :shrug:

# ? Jul 1, 2019 13:24

prisoner of waffles: May 8, 2007; Ah! well a-day! what evil looks
Had I from old and young!
Instead of the cross, the fishmech
About my neck was hung.

Jabor posted:

If a performance difference is too small to easily measure, it's so small that nobody gives a poo poo.

I hope this helps you in deciding which endeavours are a worthwhile use of your time.

Yup. Finding the faster implementation through microbenchmarks is not always worth your time relative to every other part of a project

# ? Jul 1, 2019 13:45

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

Microbenchmarks are easily biased and do not reflect real-world performance.

My favorite example of this is how eval has a cache (for dubious reasons) , leading people to think that eval(json) is faster than JSON.parse because when you run it on the same string a bunch it totally is faster.

# ? Jul 1, 2019 15:50

Sab669: Sep 24, 2009

Probably a simple question but can anyone tell me why projectedScore2 and projectedScore5 have a million decimal places?

https://jsfiddle.net/od1Lzn9e/

Math is hard

# ? Jul 2, 2019 16:32

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

Sab669 posted:

Probably a simple question but can anyone tell me why projectedScore2 and projectedScore5 have a million decimal places?

https://jsfiddle.net/od1Lzn9e/

Math is hard

One of the intermediate values in the calculation couldn't be represented by a 64-bit IEEE 754 Number. See https://floating-point-gui.de/ for more on that.

# ? Jul 2, 2019 16:37

Sab669: Sep 24, 2009

Thanks

# ? Jul 2, 2019 16:51

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

Suspicious Dish posted:

Microbenchmarks are easily biased and do not reflect real-world performance.

My favorite example of this is how eval has a cache (for dubious reasons) , leading people to think that eval(json) is faster than JSON.parse because when you run it on the same string a bunch it totally is faster.

I'd say in addition that depending on the structure of your application all kinds of god knows what is optimised by the underlying engine. JavaScript engines have been heavily modified to be basically as fast as possible when doing normal stuff as a result of browser competition.

Everyone should be writing code that is easy to read. If you are doing processing that takes multiple seconds consider hosting it and likely also consider using an alternate language.

# ? Jul 8, 2019 01:52

Master_Odin: Apr 15, 2010; My spear never misses its mark...

ladies

Is there a good existing tool for creating "cleaner" publishes for typescript projects that are in the usual directory structure. What I mean by that is I've got a project that is named butt and has the following structure:
- src/<some .ts files>
- package.json
- README.md
- LICENSE.md
- tsconfig.json
- etc.

and that run tsc builds to the dist/ directory. The "normal" route is to then point package.json:main at "dist/index.js" and the types at "dist/index.d.ts" and then to use I can just do:

code:

import { fart } from 'butt';

and that I can specify the files I want in package.json:files. However, I cannot then easily import anything that isn't specified in index.js, like:

code:

import { fart } from 'butt/v2'; // I'd have to 'butt/dist/v2'

(A good example of projects that have this paradigm is rxjs and ibm-watson.

The solution (I think) is to make a copy of the package.json into the directory, rewriting the main/typing field, and some other manipulations. Before I really play around with this, I wanted to double check if someone else had already done this before I wrote my own. It also feels like things like webpack and rollup are very heavy-handed (and complex) ways to potentially accomplish this?

Master_Odin fucked around with this message at 02:48 on Jul 11, 2019

# ? Jul 10, 2019 22:26

reversefungi: Nov 27, 2003; Master of the high hat!

The way I solved this recently is to copy package json into the dist folder, then run 'npm pack dist' and publish the resulting tarball. I condensed it all into an npm script, and it also deletes any existing tarballs before creating a new one. Seems to work well enough!

# ? Jul 11, 2019 14:13

Tanners: Dec 13, 2011; woof

The Dark Wind posted:

The way I solved this recently is to copy package json into the dist folder, then run 'npm pack dist' and publish the resulting tarball. I condensed it all into an npm script, and it also deletes any existing tarballs before creating a new one. Seems to work well enough!

Did this as well at $prevJob, feels janky but hey thats javascript i guess

# ? Jul 12, 2019 04:50

Geno: Apr 26, 2004; STUPID
DICK

Let's say (in ES5) I have a list of strings ['a', 'b', 'c'] that I need to check if a specific string exists.

I prefer storing those strings in an array and doing the "['a', 'b', 'c'].indexOf('b') != -1" to see if it exists.

My coworker prefers putting it in an object like this:

code:

var x = {a:1, b:1, c:1}
if (x[b]) return true;

He prefers the x[b] syntax since it's more concise and readable but I don't think the object is needed when an array is just fine. Any thoughts?

# ? Jul 12, 2019 07:23

Doom Mathematic: Sep 2, 2008

Geno posted:

Let's say (in ES5) I have a list of strings ['a', 'b', 'c'] that I need to check if a specific string exists.

I prefer storing those strings in an array and doing the "['a', 'b', 'c'].indexOf('b') != -1" to see if it exists.

My coworker prefers putting it in an object like this:
code:
var x = {a:1, b:1, c:1}
if (x[b]) return true;
He prefers the x[b] syntax since it's more concise and readable but I don't think the object is needed when an array is just fine. Any thoughts?

When you say you have a "list of strings", do you mean you have a finite collection of variables x, y and z which you need to check against? If so, I wouldn't bother with building a separate array or object, just do x === 'b' || y === 'b' || z === 'b'. If it's an array of possibilities, strings, then again building the object is an unnecessary extra step which takes unnecessary time, do strings.includes('b').

I can conceive of scenarios where for performance reasons it's better to go the third way, but without knowing more it's hard to say.

# ? Jul 12, 2019 09:07

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

I'd use `['a', 'b', 'c'].includes('b')` because that's... exactly what it's for. If the array contained objects and I needed to find one I'd use `arr.find(item => item.val === 'b')` or `arr.some(item => item.val === 'b')`. The solution proposed by your coworker is clearly more expensive, isn't easier to read whatsoever, and creates noise in the code.

Ah, es5.

Use indexOf.

Nolgthorn fucked around with this message at 11:57 on Jul 12, 2019

# ? Jul 12, 2019 11:55

Geno: Apr 26, 2004; STUPID
DICK

I feel like if we were on ES6 and .includes(), my coworker would totally be fine with using arrays :blastu:

# ? Jul 12, 2019 18:44

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

Just use ~arr.indexOf('a')

# ? Jul 12, 2019 19:41

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'd use `['a', 'b', 'c'].includes('b')` because that's... exactly what it's for. If the array contained objects and I needed to find one I'd use `arr.find(item => item.val === 'b')` or `arr.some(item => item.val === 'b')`. The solution proposed by your coworker is clearly more expensive, isn't easier to read whatsoever, and creates noise in the code.

Ah, es5.

Use indexOf.

Array.some/find are supported in all browsers (including IE11,) so there's close to no reason to not just use those, except maybe the performance hit of using a lambda test (but even then, if you have an object instead of a primitive, you'd have to anyway.) Also, if the alternative is literally making an object and indexing by property name, performance isn't a thing you care about.

necrotic posted:

Just use ~arr.indexOf('a')

This isn't the coding horrors thread, but I do hope you're not being serious.

Joda fucked around with this message at 19:53 on Jul 12, 2019

# ? Jul 12, 2019 19:49

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

Joda posted:

This isn't the coding horrors thread, but I do hope you're not being serious.

Yeah, not being serious there.

# ? Jul 12, 2019 20:03

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

necrotic posted:

Just use ~arr.indexOf('a')

Brilliant. I'm going to use this everywhere

# ? Jul 12, 2019 21:11

reversefungi: Nov 27, 2003; Master of the high hat!

necrotic posted:

Just use ~arr.indexOf('a')

This was littered all over the place at my last job's E2E testing framework that had been built overseas. It was also incredibly buggy and maddening to use. First time I had ever seen this, and while clever, it made me inordinately mad.

# ? Jul 12, 2019 23:38

Happy Thread: Jul 10, 2005; by Fluffdaddy; Plaster Town Cop

Isn't it wrong? (joke ruiner here)

# ? Jul 14, 2019 20:18

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

Dumb Lowtax posted:

Isn't it wrong? (joke ruiner here)

~ is the bitwise NOT operator, which inverts the bits. ~-1 becomes 0 (false), all other possible values from indexOf become negative (true).

# ? Jul 14, 2019 20:27

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 23:43

Happy Thread: Jul 10, 2005; by Fluffdaddy; Plaster Town Cop

OH forgot it was bitwise and not boolean for a second, whoops

Cool, but I guess a horror due to readability

Is everything like that considered too unreadable? Is it a horror to do

() => some_bool ^= 1

every time I want a callback to toggle a boolean value? I have lots of event handlers that do just that and it's nice for them to be so compact and seems logical enough to me

Happy Thread fucked around with this message at 20:31 on Jul 14, 2019

# ? Jul 14, 2019 20:29

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

«‹›277 »