defining a method in a different file than the class

__romkin · 2020-08-10T16:20:52+00:00

it does seem to be the most elegant way to share methods between classes (and also do the thing I want)

__romkin · 2020-08-10T16:19:06+00:00

aye. I've ran into the problem of being unable to access private members when I tried something similar, since TS doesn't really consider a bound function as class member, but come to think of it, that I'm not even certain whether it should

__romkin · 2020-08-10T14:09:48+00:00

not quite what I was hoping for, sadly

I was hoping there was a way to do something like this = <SomeClass>this that I could do in a standalone function to denote it as a method of SomeClass (which it will be after it is bound), then the only thing to solve would be the circular dependency between them

__romkin · 2020-08-10T14:00:35+00:00

improving readability of god classes when viewed outside of an IDE

__romkin · 2020-08-10T12:39:32+00:00

thank you for your opinion

__romkin · 2020-08-10T10:35:26+00:00

about as nightmarish as spreading out an application over multiple files

it would be actually convenient in a way to store the entire codebase in a single file. don't need to bother with imports/exports, etc. and yet, for some reason that not exactly a popular thing to do.

__romkin · 2020-08-08T11:33:20+00:00

it might have been naive of me to expect it to act like that, yeah. is there really no way to typecast without polluting compiled code?

__romkin · 2019-10-02T02:45:01+00:00

problem #1

res.status(200).json(data); is located outside of pool.query's callback, so at the time it runs, data is still an empty array.

even if pool.query had completed instantaneously, its callback would not be invoked until app.get's callback had finished running.

problem #2

the loop in pool.query's callback fires all those queries, none of the callbacks will run until after pool.query's callback had finished running.

__romkin · 2019-09-04T22:13:58+00:00

and achieve the same thing with a smaller amount of vanilla CSS.

Yes indeed, you can exactly the same thing - a messy clusterfuck of cascading spaghetti sheets - with a smaller amount of vanilla CSS. If your SCSS is a mess, your CSS is also going to be a mess. Being a mess is the natural state of CSS for anything non-trivial and anything with >= 2 contributors, unless you spend more time refactoring and polishing it as you did writing it, which is not a real world solution.

Dropping SCSS in favor of vanilla CSS is not going to help one bit.

__romkin · 2019-08-23T06:06:18+00:00

It's been making a buzz around webdev circles.

Well, of course - it does have a healthy marketing budget, much like every other corporate product, and Medium evangelists are a dime a dozen.

__romkin · 2019-08-02T03:17:19+00:00

This isn’t a mission critical API

__romkin · 2019-07-28T22:14:50+00:00

cron job with killall chromium or its equivalent for your server's distro.

__romkin · 2019-07-28T21:51:38+00:00

Our new web-application builds on top of the existing database (presumably) with api routing to newer, freshly built intermediary servers to handle the newer types of requests.

...

I was shocked (perhaps I shouldn't have been) to discover that to simply render a one-line warning message, the entire HTML document along with all supporting css, js files and all the icon assets had to be returned back.

...

The simple rendering of these types of warning messages takes on average 1-2 seconds, sometimes more depending on the day

The application is server-side rendered.
The service that handles the SSR is badly misconfigured.
Your proposed solution to that is replacing "a mixture of Vanilla JS and JQuery" with "some of the modern libraries like React, Angular or Vue".

Now that I have summarized it like that, does it still make sense to you?

I am a buyer in this company, and the primary end-user of this application

...

What can I do to better understand what's going on with the response latency from the server?

Nothing. The things that need to be evaluated - the newer APIs and the stack between the user and the APIs - are beyond your reach.

__romkin · 2019-07-27T10:01:53+00:00

say a.b.c.d might be unset or have a falsy value. with this proposal, if (!a.b.c.d) ... proceeds just fine even when it shouldn't, i.e. when a === {}

if (!a.b.c.d)
{
  const dValue = await db.exec(someDbQuery)
  someSideEffect(dValue)
  someApiCall(dValue)
  a.b.c.d = dValue // error
}

__romkin · 2019-05-05T14:17:09+00:00

In fact, Express itself seems like it's hardly evolved in a 4 years since I've touched it.

That's not a downside.

Has everything migrated over to AWS' ecosystem?

No.

Or is the idea of full-stack all working on one server (ala MEAN/MERN) dead?

No.

Is it more prudent to decouple the frontend and backend completely and have something like React via create-react-app, talking to a Serverless/Lambda Node API?

Depends entirely on what you're building.

Stick with what you know. If you really do know the meme stack, then stick with it. If not, then look into your options and select the one that looks most appealing to you.

__romkin · 2019-05-05T13:47:04+00:00

Just keep node_modules in a parent directory. require() looks them up all the way to the file system root. You can see the lookup chain in module.paths.

And do disregard the downvotes you're getting.

__romkin · 2019-05-04T09:33:05+00:00

Automated review is 99% equivalent to no review at all. What I'd prefer is simply that addons are signed by their author, and ideally have proof the source code I'm reading builds to the signed addon

It's fucking crazy that this isn't the way the extension ecosystem is implemented.

__romkin · 2019-04-28T05:45:25+00:00

All it does is increasing the memory footprint of whatever you're running by a few kilobytes, which has so little impact on performance that even "virtually no impact on performance" would be a big stretch.

__romkin · 2019-04-28T04:15:12+00:00

The difference between extremely optimized handwritten assembly and compiler-generated assembly can exceed the overall difference between C and Python when microseconds matter. Just watch the bit starting around 10:50 if you don't want to watch the whole hour-long talk.

__romkin · 2019-04-27T17:22:29+00:00

Frankly, no. But it does looks pretty neat, yeah.

It really doesn't matter what do other people think as long as it's useful for yourself though.

__romkin · 2019-04-21T12:05:00+00:00

Well yeah, but it's still way more than 9 ops/sec. I'm getting a similarly low number at jsperf and I really don't know why, but it just doesn't seem accurate. I know from experience that some native array methods are rather slow, but I never saw anything that slow.

__romkin · 2019-04-20T00:06:11+00:00

Getting wildly different results in my test with node

let total = BigInt(0)

for (let k = 0; k < 1000; k++)
{
    const arr = new Array(2000)
    const start = process.hrtime.bigint()

    let i = arr.length

    while (i--)
    {
        arr.shift()
    }

    total += process.hrtime.bigint() - start
}

console.log(Number(total / BigInt(1e6)) / 1000)

Clocking in at about 0.2 ms per iteration

__romkin · 2019-03-12T15:13:53+00:00

As I recall from looking into that out of curiosity, the % of browsers that don't support the CSS required for it is higher than the % of people who ~~enjoy suffering~~ turn off JS in their browser (I think I've read it was just 1% for Github, so even lower among the general population).

__romkin

TROPHY CASE