Not sure if you mean maintainability/ability to add future stuff. With that in mind for me it's to do some form of breaking things up so the side effects/remembering is low. Sucks to make a change and have to remember how everything works. In this case tests are nice for regression.
Yes that's exactly what i meant by scaling the frontend (maintainability and ability to add new features easily).
What's the tech stack you use on frontend? And for testing which library do you prefer? Do you rely on unit and integration testing only to avoid any regression?
Just FYI I'm a mid-level SWE at this time. Not an expert. This is just what I've encountered (corp day job) and personal pains of my own code.
I primarily use ReactJS.
We used a domain-driven pattern. Although there is still that component parent hierarchy thing going on.
TDD (tech design doc), write the code, linter, unit tests (Jest/Enzyme eg. render part of component take code snapshot, assert stuff) and then WDIO for visual regression testing (image diffs). It is a time consuming thing to setup but when you have like 600tests it's nice/assuring. Then it runs on a pipeline (Jenkins) for about an hour before it gets released to some domain.
Personally I am still in the get it done/MVP stage. The above is ideal case when you're established/dealing with many other people changing code.
I am going with a Selenium/functional test though personally for the thing I'm working on now (2-way real time interactive app).
There's different ways to test stuff depends what your thing is. The TAs I worked with use Eggplant.
The main thing though about separation of concerns is important when possible just to reduce cognitive load for the next stuff you add.
The above process I described I've been doing for over 2 years. I will be leaving them soon though.
Personally I've started learning since 2013, but I was still in jQuery/PHP days around that time. Didn't pick up React until like 2017. Now everything I do is JS based for the most part except things like Python/C++.
Professional experience about 4 years or so.
If you're just starting there's a developer roadmap (on GitHub) you might find interesting about all the different directions you can take.
Oh if you want to get your feet wet with ReactJS fast, I'd recommend Traversy Media's React JS crash course on YT. They're like an hour long. I say they're because he updates them per year.
Also if you look at the monthly HN who's hiring JS/React/Python are usually always at the top of the list in demand. Does depend where you're looking but yeah.
Thanks for the recommendations. I am already familiar with React, had built a web app at the start of the year. I had some unsuccessful interviews a couple of months ago for a React position and this question came up from the interviewer (it was a senior position) so I posted it here to know what are the approaches other devs are following here.
Right now i am working on a JavaScript/jQuery SPA, a huge app and a lot of bad approaches and coding conventions. I am going to resume with react ecosystem again to update myself with the current industry trends.
What is your definition of front end that it needs scaling? What is your setup that a proxy and CDNs aren’t enough scalability for a front end? I haven’t encountered a case where the front end is ever the scaling bottleneck so I have to assume that if it is in your case you either are doing something novel or you are defining something that is usually back end as front end.
Dude, it is not cool to downvote somebody for asking you to clarify what you mean with “scaling”.
If you want to know what you can do to prevent your projects from sinking into chaos:
1) Use a framework, even if it isn’t “Perfect” it is at least documented which is something you seldom have time for when you are working on your own. (I’ve never worked on an in house framework that was documented, I’ve worked on a lot of of in house frameworks)
Edit: Angular, Ember.js and maybe even Next.js are frameworks. Vue and React are not. You need more than presentation.
2) Settle on something for forms authentication eminently and make sore to keep to it. Doesn’t mater if it is frontend only, backend only or a mix. If you use a lib or if you do your own. This is one of the places where things can quickly become a mess so knock it out from the beginning.
3) Put as much of your logic into utility functions, service objects and so on as possible. Make sure you don’t pass huge “magic” objects into any of these functions and look into making them small, self explanatory and testable. You will need to reuse functionality a hell of a lot more than you think and having it mixed in with your presentation layer, or data layer will make it less testable and less reusable.
Edit: Also utility functions and service objects are easier to test than testing the same functionality in the UI.
4) Your presentation layer will turn into something ugly quickly especially if all you do is your work so:
a) Try do do small refactoring along the way and if things still get bad fight for the time for a larger refactoring so you spare yourself the rewrite.
b) Your first draft of the code will do the job but to get to a simple and clear version takes work, even if it doesn’t look like it so try to check the “simple” version in to git and not the “working” version.