
Ask HN: Its summer 2016, you need to build HUGE JavaScript app, what do you do? - kodisha
Hello everyone, before we start, lets try not to turn this into framework wars!!<p>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.<p>Also, some of the texts that do exist, they focus on solving framework specific problems, e.g. faster Angular 2 SPA&#x27;s.<p>Yet, there are almost no material on how to write, deploy and maintain REALLY big Js app, consisting of many SPA&#x27;s, reusable elements, theming, even different instances for different customers.<p>It would be great if someone who IS working on such website, and he IS using latest technology to share his experience with us.<p>- How do you develop, and organize your JS code?<p>- How do you manage partial deploys (not building&#x2F;minifying&#x2F;uglifying whole code base just to deploy single fix)?
- How do you manage reusable components?<p>- How do you handle complex components, where something is SPA on one page, and just a component of a bigger system on next.<p>- How do you do deploy&#x2F;testing&#x2F;staging in general.<p>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.
======
deathtrader666
EmberJS 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-l...](http://emberjs.com/blog/2016/02/25/announcing-embers-first-
lts.html)

------
bbcbasic
It depends. June, July or August?

~~~
atmosx
If it's August and you're in Greece, you just hire someone in the other part
of the hemisphere to do the job.

------
diziet
What is a REALLY big js App in terms of sloc in your mind?

~~~
kodisha
Well, I guess 100k+

but more than sheer lines of code, I'm talking complexity i described above.

~~~
meric
I'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
A 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

