micahbule

Location: Manila, Philippines Remote: Yes Willing to relocate: Yes Technologies: Fullstack Javascript; NodeJS, React/Native Resume/CV: Available upon request; LinkedIn can be provided as well Email: [email protected]

One particular use case that I might try this for is for (very) restrictive environments. One such case was with my previous work where we had to develop services for the client but we can only do it in a remote desktop with certain network and application restrictions. Instead of having conditions for the environment to load certain config, we can simply retrieve the secrets stored in AWS (ex. RDS credentials) via the agent.

It really should not happen, especially for fully remote teams and/or companies.

Current company has built a comprehensive career management that encompasses even remote workers. It's a very objective and simple approach. The challenge comes with crafting KPIs with each employee as basis for promotions, but so far it has been paying off.

jQuery changed the game for frontend web development. Instead of static pages on the browser, interactivity for the client-side proliferated because DX on top of jQuery was way better. Then they started cursing jQuery for its limitations.

Then came React -- which again changed the game for frontend web development. Instead of wonky scripts and targetting CSS classes, you get a modular and reactive approach in building the web. Then they started cursing React because of performance issues and implementation complexities.

Svelte was designed to behave like React but perform better and reduce the implementation complexities. I had the chance to work with Svelte 1 back then and as a React developer, it would really make you think "Why did React do that?".

This is probably on top of HN because people loved Svelte too -- but some followers are now questioning the direction as this change is gravitating towards solutions that React already implemented. As it happens, React did solve a lot of problems for the frontend, and they really nailed it.

This best describes why it's actually both a gift and a curse.

I disagree employers don't have a win on the remote work setup. For one, they can reduce a lot of overhead for the upkeep of physical offices. There's also giving the idea of giving the employee more time for themselves, when in truth they really actually extended his work hours; just at the comfort of their homes and at their own pace. While it's not perfect for everyone, remote work has its perks for both employees AND employers.

>Make yourself valuable to negotiate better terms, or look for something better

I could not agree more. You would always have leverage with salary negotiations during interviews if you can justify the value you bring on the table. For technical positions, unless the hiring process does not involve any technical assessment, it's quite easy to spot who knows what they're doing from those who are just good on paper.

Specialized technical people often look down on supposed fullstack engineers because specialized technical people value mastery over familiarity -- something a lot of FS engineers really try to be exaggeratingly proud of. While familiarity with your stack is great for cross-cutting concerns, mastery is what truly builds great software, not to mention in a timely manner.

Managers are excited about FS engineers simply because if they scoop up good ones, those who really know what they're doing -- masters of several areas of their stack -- they can rotate them effectively at a fraction of a cost, if not for free.

A very quick question: Where can I find a list of energy companies with data already available in your API?

Thanks.

That is through using a custom server -- which is a whole other topic. I'm comparing apples-to-apples between NextJS's built-in router and Remix's usage of React Router as far as client-side routing is concerned.

I'm not aware of said functionality on the client-side. Out of curiosity, do you mind linking me to said documentation or article on how to circumvent routing on the client-side without using fs-based routing?

Yes, NextJS does ship with an imperative router, but you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory.

I also agree that there's more to caching and SSG with NextJS. I'm simply stating some notable differences between NextJS and Remix, answering the top-most parent comment.