I've tried InVision Design Studio, Adobe XD and Figma. They all now are available both on Mac and Win for free, however, only Figma is also available in browser where you can collaborate real-time even with non-designers which is essential for any business. As a PM I prefer Figma and have seen many designers, including in my teams, switching from Sketch/InVision to Figma. It's very simple tool where whole team can speak same language and draw real-time right in the browser. However, from the point of view of UX, I like Adobe XD more, it also comes with whole Adobe suite integration like fonts. In Figma, if designer is using specific fonts, another collaborator on another machine might have a bit different experience. Design Studio is still young and hard to say, overall, it was best for easy animations and transitions. Sketch is just a design tool and doesn't give you clickable prototype, collaboration, comments, etc; You have to use another tool and sync with InVision all the time. With Figma and Adobe XD you have all in one place. Overall, Figma is tool I always recommend everyone , at least for projects when you are starting, especially if you are a non-designer or a Product Manager, UX Researcher. It's very easy to do rapid prototyping and collaborate with a team within Design Sprint and work on low-fidelity design, UX guidelines, user flows, UI elements and GUI kit, etc. After that it's up to Design Lead to take it from there. Most of Design Teams continue working in Figma and converting work into high fidelity design. If after that a lot of animations are required, then they can move to another tool.

Data Structures are must-have for any software engineer, obviously No matter is it backend or frontend. How can you write JavaScript if you have no idea what DS is? You, of course, don't need to remember all state of the art DS, but you should be able to know basics and write few basic algorithms from scratch.

If you don't want to use a framework, it means "Vanilla JavaScript". You really don't need any framework to do fetch()+FormData API (AJAX) calls to your Node backend, however, on backend, I would recommend using at least Express. It's very lightweight http library on the top of of Node API. Yes, Vanilla JS in frontend is very common in production and I use it often as well. Here is my article which might give you some tips on how you can do Vanilla JS components without any frameworks. https://medium.com/bunnyllc/vanilla-js-components-8d20c58b69f4

I suppose you are talking about writing automated tests. QA and testing != writing automated tests. YES, you should ALWAYS test everything you write, how otherwise you can tell your client it works? It is ready only when you delivered a feature in a good quality which does what it should do and it works in all situations and it will work after 10 years. How do you test, it is up to you. Manual or automated or both, however you always should use both, but you ALWAYS TEST. When you will get tired doing same work all the time, you will start automating anyways. Eventually if you have only small projects and small customers who have no idea what they are doing, it DOESN'T mean you should write automated tests against anything. Start from what you test most of the times, what is a dependence to a 3rd parties used by other people/projects (especially when it is a public API) and just test your critical parts. Also, please, DO NOT CALL YOURSELF a SENIOR, if you don't know what system and business analysis IS and that you shouldn't just do what people tell you and don't do what they don't tell you. I REALLY HOPE you hash your passwords you store in DB because no customer would ever ask for that! P.S. I would advise you to REMOVE 2nd paragraph ASAP to avoid shame and being indexed by search engines so one day one of your potential employers couldn't find it and instantly reject your application. It means you are JUNIOR, because seniors do NOT define themselves, they ARE defined by OTHERS and they know what they SHOULD do and HOW as a professionals.

Stop asking questions in wrong order. Define them in correct one and you will get an answer yourself You always start from the end and go backwards from there until you will arrive at point where you are now. Now you see all steps clearly and what it would take to achieve. What do I want? Learn basics of Game Dev and I don't know how to start What most of the businesses today use for professional and commercial Game Dev? Unity, Unreal Engine What is easier for beginners to start from? Unity What programming languages are available for Unity? C# and JS-like syntax. So answer to your question is C# and Unity, but only to get started. Of course you shouldn't be focused on using ready Game Engines only but also learn how it works and write basic engine yourself from scratch someday. After that you will also need to get your hands dirty with UE4 which is using C++. I would say C++ is a general Game Dev language and most of industry is written on C++. Finally, it is never about a language, but as I said - about a goal. Game Dev is extremely huge industry and there are just too many types of games. Always start from the goal and ask yourself same stupid questions going backwards again and again. Now when you have some basics of Game Dev, C#/C++ and Unity/UE which are required by every Game Dev studio recruiting junior engineers, you will start asking yourself: what exactly do I want to do - engine, scripting, animations, level design, game design, whatever (or what business needs now) and what type of games do I want to build - 2D/3D, RPG, AR/VR, shooter, whatever (or again what business is doing now) If it is "RPG with some PVE", then you just Google "How to build AI in C++ or Unity or whatever" and Google all the time. Also browse source code of open-source engines and projects on GitHub and learn from them. But always remember Focus on basics, on principles, and on theory. Become Guru of both 2D and 3D graphics from scratch, building basic AIs, UIs, physics and all the related math. Principles and laws never change. Engines, language, teams, projects change. Requirements define action. Not vice versa.

NEVER just "copy and paste". As Marco said Optimize at compile/build-time, not runtime Compress your assets using a lot of already available node scripts and build tools. On server side, enable http2 and nginx caching. On application level - compress/compile views as well depending on language. If it is PHP and you use template engine, you might generate a final vanilla PHP file itself like Laravel is doing out of the box. Same with any template engine you use in Node. You might also remove all tabs/spaces from HTML to make it even smaller. You HAVE to know how everything works on lower level and you won't have any questions ever again. Start from "History of the Internet", "How the Internet works?", OSI model, HTTP1, http server (nginx) configuration, then you just apply that knowledge to your current needs. You don't need to do anything at the beginning, only ADAPT to a situation. Start small, simple.

Negative At least because it just transforms your code into React Native, that's it. So, instead of transforming garbage into "pseudo-native" mobile app, Vue Native is transforming mini-garbage into garbage first and than again garbage into mobile app. "Let's write a dropdown in a browser in a JavaScript because it is the only language browser understands, but let's do it in TypeScript, but before that let's write in PHP and before that let's write it in Java and just transpile Java > PHP > TypeSript > JavaScript." I can tell you a secret, you can just write an iOS app using Swift itself and you do NOT need over 9000 other steps to get to the Swift, and same for Android, you can even use Kotlin! It's like "I wanna leave in China, but I don't wanna learn Chinese and only less 1% understands English, so I will just hire a translator who will be walking with me whole my life, la la la, cha cha cha". So, at least until Apple, Microsoft and Google won't be providing, supporting and maintaining official JavaScript API and compiler for their native platforms... Use the right tool for the right job

This is my favorite image perfectly explaining whole field. This is a very dirty job, you literally dig s*t in the dark tunnel, often need to explain basics to people all the time, and most of people are not helping you, moreover, they also occasionally bring you even more problems. However, of course this field has a lot of bright side, especially when you are around like-minded and exceptionally smart and very curious people, including Leaders (Managers).

You always need to manage any society and social groups, especially at such scale, otherwise, things can become really bad. Laravel community has grown to a global level. How much spam do you receive and do you see any other problems in the community? Have you been thinking about finding community admins and moderators or even make this community vote for them itself like StackOverflow does? It is physically impossible to process so many requests, feedback, proposals and provide good support. What about official list of top local Laravel communities and their leaders/contacts around the world on Laravel website itself?

Async those days became very popular because of Node.js and there is now ReactPHP. Do you plan to use async in php and maybe make a socket server integrated with Laravel in PHP itself?