6 ms·
Ask HN: Its summer 2016, you need to build HUGE JavaScript app, what do you do?
Hello everyone, before we start, lets try not to turn this into framework wars!!
We are now seeing quite renaissance of web frameworks, transpilers, and even standards getting approved faster than ever, there is almost no documentation on how to build large web apps, and some of the texts that are out there are quite outdated.
Also, some of the texts that do exist, they focus on solving framework specific problems, e.g. faster Angular 2 SPA's.
Yet, there are almost no material on how to write, deploy and maintain REALLY big Js app, consisting of many SPA's, reusable elements, theming, even different instances for different customers.
It would be great if someone who IS working on such website, and he IS using latest technology to share his experience with us.
- How do you develop, and organize your JS code?
- How do you manage partial deploys (not building/minifying/uglifying whole code base just to deploy single fix)?
- How do you manage reusable components?
- How do you handle complex components, where something is SPA on one page, and just a component of a bigger system on next.
- How do you do deploy/testing/staging in general.
I have this feeling that this topic is not covered at all, and the demand its getting higher by the day, so lets start discussing it here.
- diziet 10y agoWhat is a REALLY big js App in terms of sloc in your mind?
- kodisha 10y agoWell, I guess 100k+ but more than sheer lines of code, I'm talking complexity i described above.
- meric 10y agoI'd use separate libraries rather than monolithic frameworks. By the time you finished there'd be good chance the framework will be abandoned or have a huge backwards-incompatible update or two. With separate libraries you can swap those bits out, or otherwise it's manageable for you to take ownership of them by yourself.
- diziet 10y agoA lot of the problems are organizational and often due to scope changing over time, but in my experience aren't problems as much as opportunities for learning and optimization and leveraging technology. This is not unique to single page apps or JavaScript based apps but apps in general. With tools like Jenkins (and the ability to have multiple staging and testing servers) it is pretty straightforward to set up a system that continuously runs tests on the master etc branches. Similary, there are tools out there that will make compilation of us and assets fast, especially if only part of the code is changing. This depends on your technology stack specifically but in most architectures this is doable. As a guideline, you want to optimize / parallelize your testing so a full set of tests runs in some amount of time -- we aim for under 2 minutes. Front end tests can't run this fast unless you massively parallelize things but we use <15m as a guideline. There should be a single button deploy that works in 99.9% of all cases and the deploy should only run after all tests pass. Due to setups that only allow deployment of tags that passed all tests and passive in the background always running tests setup it should be reasonable to have a deploy fully run in <5 minutes, including all compilation or assets! non-front end tests, code style tests, etc. Why are you worried about deploying so often? Realistically you want a simple deploy process but if you are deploying so many times per day without a 300+ eng team working in the code base there is probably a bigger issue in play that has little to do with deploy speed or efficiency. Your teams can only design, produce,test, refine, optimize etc. features at some speed which is certainly slower than your deploy speed. Similarly, think about the human process of reviewing code, prioritization, communication of blockers, communication to the rest of the organization, and all the people involved and final directly responsible stake holders. Is that running well? If you are managing a large app, and have multiple single page apps and components etc you are either running an enterprise or business facing eng team or are at a later stage consumer company. In either case, think about the successful organizational structures and processes for other parts of the business (if they are working well) and apply some of those principles in improving the eng. process. If your marketing team is truly killing it, ask them how they organize and keep iterating and improving. The things that cause issues in engineering organizations are typically a step higher than the problems you brought up. If your deploy process involves one specific person doing some specific arcane thing, if your team is not aware how deploys work or complain about speed of tests ( they always will but if non-front end tests take actually a long time ) your problem in not in technology but rather lack of oversight and ownership over these functions of the engineering org. You don't have clear ownership or responsibility assigned properly or your team members don't have the avenues to suggest, take ownership of and carry out improvements. That would be the number one problem to look at, in my mind. * I used you to mean the reader in general
- bbcbasic 10y agoIt depends. June, July or August?
- atmosx 10y agoIf it's August and you're in Greece, you just hire someone in the other part of the hemisphere to do the job.
- deathtrader666 10y agoEmberJS would be a good fit for you. IMHO, usually it isn't the framework in isolation, but the surrounding ecosystem of plugins and dev tools that give one a hard time. Ember solves most of them off the bat - http://emberjs.com/blog/2015/06/16/ember-project-at-2-0.html http://emberjs.com/blog/2015/06/16/ember-project-at-2-0.html Please read through their release cycles too, especially the LTS ones - http://emberjs.com/blog/2016/02/25/announcing-embers-first-lts.html http://emberjs.com/blog/2016/02/25/announcing-embers-first-l...