3 ms·

Yes sorry for not doing this. In the source code folder, please open any random file and try to understand what the code does. I once tried to fix a bug that I

by ekseda 6y ago

Yes sorry for not doing this. In the source code folder, please open any random file and try to understand what the code does. I once tried to fix a bug that I found in GUN but I gave up after just trying to figure out what the code is supposed to do.

vorpalhex 6y ago
That's not an issue with the source code linked above which is just basic javascript.
iovrthoughtthis 6y ago
Wow. You are right. What the heck.
xsdklfsdfklj 6y ago
That is very readable javascript. old school javascript like this have an advantage: you can ship as is, without the need to obfuscate under the excuse of performance. if you load two hundred build dependencies and then write twenty word long variables, it might look nice for you at development, but a user trying to debug or validate code on the fly would be in a very bad position as you would have to 'minify' (i.e. obfuscate) to not have a 70mb production file. Code like this is very readable if you know some conventions, things like `cb` being a callback pointer. Its not even close to the cryptic knowledge needed to read assembly on weird platforms, for example. And a far cry from obfuscated.
- ricardobeat 6y ago
  > without the need to obfuscate under the excuse of performance > load two hundred build dependencies and then write twenty word long variables [...] a very bad position as you would have to 'minify' (i.e. obfuscate) to not have a 70mb production file You defeated your own argument here. You're saying it's nice that the code is obfuscated already (short variables) so you can get better performance, it's really the same thing - except doing it by hand has a lot of downsides. Minifiers and source maps have been around for a long time to get you the best of both worlds, understandable code in development, minified code in production (even though gzip alone gives you 80-90% of the gains). There is absolutely no reason to write obfucasted code like this [1] where you need to guess the meaning of thirty different one-letter variables. Grep'ing the code becomes impossible. This has nothing to do with 'old school' JS, but universal code standards. [1] https://github.com/amark/gun/blob/master/src/type.js https://github.com/amark/gun/blob/master/src/type.js
- ekseda 6y ago
  No this is not readable. You can write readable old school javascript, but just try to tell me what this line does: https://github.com/amark/gun/blob/master/src/type.js#L111 https://github.com/amark/gun/blob/master/src/type.js#L111
kodablah 6y ago
I wrote the beginnings of a Gun implementation in Go based on my reverse engineering of the Gun JS code: https://github.com/cretz/esgopeta https://github.com/cretz/esgopeta. I halted development as I am no longer needing it, but the code might give some insight (assuming it's even accurate, never made it to significant testing).
amelius 6y ago
Indeed, the source looks like the output of a transpiler.

by ekseda 6y ago

vorpalhex 6y ago

That's not an issue with the source code linked above which is just basic javascript.

iovrthoughtthis 6y ago

Wow. You are right. What the heck.

xsdklfsdfklj 6y ago

That is very readable javascript. old school javascript like this have an advantage: you can ship as is, without the need to obfuscate under the excuse of performance. if you load two hundred build dependencies and then write twenty word long variables, it might look nice for you at development, but a user trying to debug or validate code on the fly would be in a very bad position as you would have to 'minify' (i.e. obfuscate) to not have a 70mb production file. Code like this is very readable if you know some conventions, things like `cb` being a callback pointer. Its not even close to the cryptic knowledge needed to read assembly on weird platforms, for example. And a far cry from obfuscated.

ricardobeat 6y ago
> without the need to obfuscate under the excuse of performance > load two hundred build dependencies and then write twenty word long variables [...] a very bad position as you would have to 'minify' (i.e. obfuscate) to not have a 70mb production file You defeated your own argument here. You're saying it's nice that the code is obfuscated already (short variables) so you can get better performance, it's really the same thing - except doing it by hand has a lot of downsides. Minifiers and source maps have been around for a long time to get you the best of both worlds, understandable code in development, minified code in production (even though gzip alone gives you 80-90% of the gains). There is absolutely no reason to write obfucasted code like this [1] where you need to guess the meaning of thirty different one-letter variables. Grep'ing the code becomes impossible. This has nothing to do with 'old school' JS, but universal code standards. [1] https://github.com/amark/gun/blob/master/src/type.js https://github.com/amark/gun/blob/master/src/type.js
ekseda 6y ago
No this is not readable. You can write readable old school javascript, but just try to tell me what this line does: https://github.com/amark/gun/blob/master/src/type.js#L111 https://github.com/amark/gun/blob/master/src/type.js#L111

kodablah 6y ago

I wrote the beginnings of a Gun implementation in Go based on my reverse engineering of the Gun JS code: https://github.com/cretz/esgopeta https://github.com/cretz/esgopeta. I halted development as I am no longer needing it, but the code might give some insight (assuming it's even accurate, never made it to significant testing).

amelius 6y ago

Indeed, the source looks like the output of a transpiler.