News for hackers. Stuff that matters.
Re:Designing very large JavaScript applications by tytytytytytytyt on Friday April 20, 2018 @08:46PM (#16889393)
Don't the popular web frameworks handle lazy loading things?
Re:Designing very large JavaScript applications by darkmarmot on Friday April 20, 2018 @09:22PM (#16889510)
Most of the popular frameworks generate a single JavaScript bundle that comprises an entire application. Some people break these bundles into multiple parts manually in a process called 'code-splitting' in order to do a really chunky kind of lazy load.
Re:Designing very large JavaScript applications by ngxoogler on Saturday April 21, 2018 @08:48AM (#16891239)
Code splitting via webpack is not a manual process.

Does your hand rolled framework handle minimization and obfuscation? Probably not because any changes would require a rebuild.

Are your assets cached? If they are, I'm curious how you handle the cache busting when a single file gets updated.

Re:Designing very large JavaScript applications by ec109685 on Saturday April 21, 2018 @10:00AM (#16891446)
With HTTP/2, you can send files down independently, without creating a large bundle, so each file can be cached. You couldn’t obfuscate function names across files though unless you made the process deterministic based on module name.
Re:Designing very large JavaScript applications by kilburn on Saturday April 21, 2018 @03:48PM (#16893050)
But you need some cache-busting functionality anyways (otherwise how does the client know that file "something.js" has changed?
Re:Designing very large JavaScript applications by ec109685 on Saturday April 21, 2018 @10:26PM (#16894404)
Etags could be used to cause the browser to revalidate the contents without too much overhead since the connection is already establishd, but good point.