Ask HN: Scaling the Front End?
What are your strategies to scale up frontend? What process and coding style do you follow so that the project could scale up easily in the future?
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.
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.
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.
But yeah ReactJS is good to know/has huge market share. I'm glad I picked it over Vue/Angular.
If you're looking for something else to learn, being able to setup a Node backend with auth is nice to have as well eg. using JWT. Then knowing general best practices about security eg. XSS/sql-injection.
But yeah... Depends what direction you're taken eg. strictly front end or both.
Anyway good luck.
Check out CSCareers the subreddit if you haven't already. That is more for school/compsci but can help with how to get jobs. And have a good GitHub/LinkedIn.
Even if you don’t want to use one of the larger frameworks like Angular or Ember I would still recommend doing a couple of tutorials to see how they construct things. Any app needs an architecture and you are more likely to get a feel for that with something larger like Angular or Ember.
Alternatively find something that can teach you about front end architecture. An SPA is more than a router, views/components and state management (and libs and service objects). Look around a bit to figure out how you want to architect things and what concepts exist.
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.