The point is when you have to go back to some code 6 months later and you don't remember anything about how it all works - good unit tests will save you from a day of wrestling with it to understand it again.

Our Facebook login stopped working Tuesday. For some reason Facebook and Google integrated with AWS cognito had always returned nothing for email_verified (the field didn't exist). Whereas cognito would return true or false for users who signed directly. So I had a check for email_verified === false, which worked fine.

But then all of a sudden Google starts showing up as email_verified = true for all users and Facebook as email_verified = false for all users. Fun stuff. Because of my unit tests I was able to quickly find all the spots where I needed to change the logic, and be confident I could push a hotfix w/o worrying about breaking something else.

As a one man show on a lot of my stuff with no testing team to speak of, good unit tests (and integration and e2e tests) allow me to wrangle a large code base with an order of magnitude less effort than if I didn't have them - even taking into account the effort up front to write the tests.

Tests make a big difference as the framework changes and u have to go rewrite stuff. Maybe less relevant on the front end where stuff is usually more isolated by default.

Probably the type of management you are describing doesn't care about unit testing.

I've been there, and it is tough, but how you address that, it depends.

You just say your time, don't say it takes my five days, but without test, it takes me two.

First, you decide if you do test or not. Ideally, you should always do unit testing, but there are some factors that maybe you shouldn't do it.
Maybe it is a legacy product, and if you do unit tests, it will take you forever.

Unit testing is a trade-off between cost now and benefits later.

But the thing is you need to deliver a quality product, and if you feel your product is going to decline in quality if you don't do unit testing (probably bugs), then you need to do unit test no matter how long it is going to take.

If anyone in here has played Hearthstone, I have a question for you.

How would you describe the lag in the transition that occurs when you find a Worthy Opponent while searching for a game? - In terms of computation?

Matchmaking time, if that's what you're asking

I assumed that the matchmaking was happening while the spinner was spinning. Before you enter the match, the spinner seems to stall and hang for a couple seconds before it shows "Worthy Opponent". I'm wondering what would cause this type of lag before almost every game. It seems very un-Blizzard from a polish perspective.

Shitty app. It also sometimes forgets its screen orientation so you need to flip your phone over and back again to fix it.

When they’ve had these bugs for years and don’t fix them you can assume it’s just bad design, IMO

That's kind of why I brought it up. It seems unlike Blizzard to have that sort of an "eyesore" in their game for a long time, unless it's exceedingly hard to fix. I would love to hear one of their systems guys talk about the challenges of keeping the Unity experience smooth.

Something like, "Yeah that's an annoying hiccup, but in order to fix it we would have to totally redesign the whole process of playing a game, and we don't want to break more stuff by trying to smooth out that transition. The transition might be smoother but there's a possibility we would go back to the days of minions spontaneously moving around on the board, which is worse than the matchmaking lag."

I've noticed that too. When I first started playing I thought the app was freezing, now i don't even notice it really as its just part of the start game process.

Anyone here familiar with server side rendering? It's VueJS.

I'm familiar with Angular Universal and NextJS and I can confirm they're both a half-baked PITA.

I'm not surprised... I heard Angular and React are both significantly worse than VueJS. If that's the case, I feel for front-end devs.

VueJS has something called NuxtJS, which writes routes for you because that's a good thing, I guess? I tried out something called Quasar, which at least somewhat looks like normal VueJS, but it's totally confusing.

The big issue is this, copied from the official SSR docs:

Except mounted doesn't actually work for anything. Ask around, I'm told "you don't know anything about SSR, SSR isn't front-end, RTMFD!"

I just want item A to be rendered client-side and item B rendered server side.

Vue is supposed to combine the best of each and be much simpler. I have no real experience with it.

I'm not 100% sure but I'm going to guess NuxtJs and NextJs are cousins?

There are cases where you'd like to SSR say the top 4 boxes which show when a user hits the home page, but lazy-load (CSR) the rest if they scroll down. Or optional things that don't happen often but you need to load something when the user takes action - like say opening a drawer or something.

I'm guessing mounted() is for that.

But I can definitely say that the official docs for angular universal are shite and it was clearly half-baked and never really went anywhere. NextJs seems to have a lot more support. But we're using an offshoot of that which I have no faith in. But again, I don't know how that relates to NuxtJs.

I don't know anything about Nuxt, but I'd guess with a name so close, it must have taken some inspiration. I started up trying to go all vanilla SSR VueJS. Sure learned a lot, but went with Quasar instead.

In client-side only, mounted() is basically an init() for the component. It mutates the initialized data and updates the corresponding values so they display in the html before rendering.

The server-side init() is serverPrefetch(), which stages the data to be used in a `computed` property that initializes the data / function for the html.

For what you are describing, you would probably need a `watch` property, but not sure, really.

As I understand the point of mounted() in the context of SSR:

You have a "store" that contains all the data for the page (basically a massive JSON file). It makes no sense to call the data again if it is already in the store, so mounted() would fire instead of serverPrefetch().

For those who are doing JS-based web-development, how much do you actually write vanilla JS day-to-day compared to using frameworks (i.e. React, Express) to abstract away complexity and repeated code? Since I went to a pretty theory-heavy CS program and didn't take any software development electives I basically didn't learn JS at school, but been taking it up lately to become more well-rounded. The language itself is pretty easy since it's C-based, but the actual web-development process seems to get annoying really fast as project size increases. Manually dealing with DOM elements seems incredibly error-prone should there be changes in the structure of the page, writing REST APIs requires to do the same stuff over-and-over again, so on.
So what I'm basically asking is how much does vanilla JS actually get used in the industry and how would you rate the difficulty of your job as it is right now vs. if you had to do everything in just JS without frameworks. I'm asking this because I'm wondering if I should actually become expert in vanilla (should I ever want to try my hand in web-development) or it should be taken more as a base foundation that is nice to know, but the real meat lies in being well-versed in frameworks.

I think it's totally worth it to learn the basics of JS. You can always pick up frameworks any time once you have that.

No one manually manipulates the dom in 2020. Vanilla javascript is not the dom, if you want to learn JS learn the ins and outs of its core methods and properties (arrays, mostly, map filter reduce), not "document.getElementById('foo').classList += ' bar'" and crap like that, react etc will do all that for you.

I beg your pardon sir. I am having to hack this form-process framework-thing called alfresco, which has its own super complicated front-end framework (ADF) based on angular 2. To get it to do what we want, rather than including jquery and adding even more overhead, I'm dom-manipulating all up in that ****. I'm getting elements by class name, setting classes, listening to click events. It's all kinds of fun. The only thing I haven't to pull out yet is document.write().

But yeah - learn the JS language stuff and nuances - especially scope, closures, hoisting and the other advanced features of JS. Very valuable. It's very rare you have to do the stuff I'm doing.

JavaScript ended up being suitably enjoyable once es6 came around and I discovered it was more than the dom manipulation grue describes. Manual dom stuff is for the birds

I'm actually enjoying it in a retro kind of way.

But I do not plan to write my own jQuery.

Frameworks are great for layouts, DOM, and reactivity, which I appreciate, but out of that scope, you're in a world of hurt if you aren't willing to write vanilla JavaScript.

Thanks for the replies. All of the concepts mentioned here I'm already familiar with but it's mainly DOM/reactivity that gives me headaches when trying to work with this stuff on front-end. Will probably pick up a framework at some point to make my own life easier, but I still feel like got plenty of learning to do about the intricacies of the language first.

What are you actually trying to do? If its "make a great interactive web UI for an application" you should probably just use react, now.

or Vue

I don't think it hurts to learn a little about about the DOM. click button, update element, add 1, change green to red, or whatever is fine. Just no point going bonkers and making a huge project without a framework.

Vue is pretty alright as long as you aren't doing SSR.