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: hi@meeco.dev

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.

A good course/resource to go on a full and serious dive to CS:

https://github.com/ossu/computer-science

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.

While it is easy to use cache headers with NextJS -- as you said -- you have to know what you're doing.

It still boils down to use case, implementation, and quite possibly preference.

Personally, I'd still pick NextJS any time for any enterprise-level projects. Remix would be a fun little new framework to toy with for personal projects.

You can. I'm stating SSG in the context of caching and in comparison with Remix's approach.

That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps

Some of the notable differences between NextJS and Remix are the following:

- While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions

- NextJS banks on its static site generation to generate "cache-able" websites whereas Remix utilizes cache headers for its server-rendered pages

- NextJS has no baked-in support for handling session and cookies; Remix has

While it's true that it's a Node framework, NextJS can totally function like a client-side React framework. NextJS just bakes a lot of basic and common functionality such as routing, built-in support for CSS modules, as well as optimizations (it's not premature if it's baked in already).

The server-side mostly just takes place if you utilize the following: - Built-in API - Server-side Rendering

I actually had a chance to meet Martin once during JSConf in Singapore back in November 2014. Very cool guy with a hysterically fucked up humor with JS.

I mean... http://aem1k.com/world speaks for itself.

JSFuck was included in his presentation back then and boy did it inspire me to do more JS. Here we are, a little under 7 years later, still in the JS world.

What finish line?