Thanks! This is a super helpful answer!
Thanks! This is a super helpful answer!
In that case you will love typescript. I’m not sure what other imperative languages have both type inference and structural typing.
My opinion is you should use it when it’s useful, but not when it’s unnecessary. Their main use case is when you need to couple the functionality of functions to a shared state, and it’s particularly useful when you have multiple interdependent functions that need to be tied to multiple codependent states.
I find it relatively rare when I really need to use a class. Between first class functions and closures and modules and other features, I find JavaScript has a lot of tools to avoid needing classes. Classes add complexity so I only use them when the complexity they add is less than the complexity of the task they’re needed for.
After experiencing ad hoc inline scripts, frameworkless jQuery spaghetti code, inflexible monoliths like angular, and overly simplistic micro frameworks like backbone, I’m super happy with where we’re at with react and react like frameworks. I really do feel like we’ve hit the sweet spot between power, simplicity, flexibility, and ease of use which is why I’m confident that things aren’t going to be as volatile as the past. React is already 10 years old now and still going strong with no new trends looking to usurp it. I think those old trends were necessary experiments to get to where we are now, and I think the old meme of web dev changing every week is no longer true.
I’ve had a good time with react SSR and SSG particularly when using next.js which does a great job optimizing out of the box, but really SSR and SSG are functionally just glorified string interpolators so anything will do. What matters is ease of use and with the strong community and toolset available to react I’ve had no trouble setting up react for SSR/SSG.
Where things still need improvement is with hybrid apps that take SSR/SSG pages and hydrate them to be ready for the client to take over, but that’s always been a pain point, and while we’re still not where we need to be I do think it’s better than it’s ever been and we’re on the right track to cracking it.
Maybe it’s because I’ve seen how bad things can get that I’m appreciative of what we have. After experiencing frameworkless jQuery spaghetti code, overly complicated monoliths like angular, and overly simplified micro frameworks like backbone, I’m really happy with the frameworks and toolsets we have now, and react’s ecosystem is very mature.
I would say that react is overkill for SSR, but pure SSR is pretty simple so react is also able to handle it just fine and elegantly as react is even easier to use when you’re not dealing with dynamic state, and if you find the need to introduce some hybrid client side functionally, which pretty much always happens eventually, it’s a good thing to be on react.
Here’s my hot take as a dev who’s been making websites since before JavaScript and css were invented: modern web development is leaps and bounds better than how it was and the rapidly changing best practices had a big part for how we got there in the time we did. I think the industry is in a great place now and now that it is things have slowed down and the focus is now on stability rather than changing development patterns.
The actual game part of ff7 could have easily run on the N64, it was just the fmvs and music that were too big.
I just hope it’s less linear. They had some really long portions where there was only 1 route to take.
I’ve always said JavaScript was an elegant language with a horrible implementation. Now that we have typescript and modern ecmascript standards I feel vindicated.
The prototype system is a bit confusing despite being simple, but it’s very powerful despite being simple, which I think balances it out. Also using modern classes abstracts the more confusing bits and you very very rarely need to actually understand the underlying mechanics if ever anymore. Plus you rarely even need classes either with the first class functions.
Parallelism could really improve. Don’t think I’d want to mess with shared memory, but I’d like to be able to pass actual in memory objects instead of having to serialize everything first. Maybe a child process sandbox that can be filled and relinquished once or something like that?
Just don’t leave your hand in it while running it!
I think that’s assuming a relatively consistent level of scope, but the scope will just get bigger. How big is your feature backlog? Will you be able to easily get through it even with the help of AI? How big will your feature backlog get if implementation friction is lowered?
It will be questioned, but you have a good explanation. The tricky part is explaining it elegantly. Hiring managers kinda glance at resumes so you should add a sentence at the end explaining that you were let off due to internal company reasons. You should also try and get a letter from the company explaining that it wasn’t for performance reasons. Even better would be to get letters of recommendation from your coworkers and manager. Hopefully they’ll be extra nice to you due to your situation, but you need to be proactive about it.