search

BrisJS / meetups

https://brisjs.org
98 stars 8 forks source link

Talk Request: Managing large js applications #55

Closed xwipeoutx closed 8 months ago

xwipeoutx commented 9 years ago

I'm interested in seeing how people manage the complexity of a large javascript application. Here's my ideal:

And the stretch goals

So far, my solution has been to write refgen to traverse file dependencies type-script style, and include it as part of a gulp script to output an "application.js" which is bundled, or "dependencies.json" which I build <script> tags with at run time, but I feel I'm reinventing wheels here.

Anyone got a talk on getting such an environment set up? Or if this is something that everyone (but me) already know and do, got a link with instructions?

Failing that, I can present how to use refgen to get most of the way there...

Edit: I should mention, "large" in this case is about 1200 javascript files, average of 100 lines each, and around 6000 unit tests. To be fair, this is split up among a multitude of projects, but that just makes the automatic dependencies more important.

garrows commented 9 years ago

This is a pretty large request list for 1 talk. Maybe we should manage it by breaking it up into smaller talks.

I'm happy to talk about a design pattern I'm using that really helps break up the code into manageable chunks.

xwipeoutx commented 9 years ago

I guess my dream was that it shouldn't be a large thing - setting up a development environment like this should be npm install <a bunch of things> --save-dev and a fairly straight forward Gulpfile.

That's the dream, anyway.

That said, can't hurt to have some more smarts on code organization.

garrows commented 9 years ago

Ah the dream.

Problem is the dream is a matter of opinion.

My dream has angular. React people dont dream of angular.

On another note, perhaps every month should have a theme. i.e. "Large app organisation" or "Game Dev" or "UI Frameworks". I'll bring it up in another issue I guess.

govpack commented 9 years ago

Do Androids Dream of Electric Sleep? i mean sheep

is the project is node or browser based? or both? who's using a build step and why?

the internet is a large javascript application why not just do it like that? script tags are a great way to include javascript why not just add some script tags and leave it at that? each page loads what it needs, or dynamically as needs be the dream includes everything/anything that can run in [or by way of] a web page

i see build steps - browserifying a single large bundle of code - as being an unnecessary problem -- xcopy deploy, static pages, no build step, then if you start naming the script files, (or sub-project folders) numerically and keeping independent unit tests in individual files [or "sets of" in jsonp arrays] then it wouldn't be a problem to have random access to any of them (even millions of them) on demand

it's fine to go modular with node_modules, the trade off is that node_modules contains MANY things that you don't know anything about

the problem with "bundle.js" is that it's not readable, and the atomicity has been lost -- the individual parts are not accessible -- and you end up having to run a build step on every change.

magic has been gained, and for the most part it works!!! Although for me, i would prefer to start, and continue, from a simpler and more direct place (and on other occasions may do it the other way, and be happy with both!!! I believe the ESSENCE of that simpler place is INSIDE every project, although I have lost it many times myself. These comments are just opinion [and therefore mostly worthless!!!] and will in no way prevent the 1,000,000 and 1 other ways to achieve great results. I would love to have the knowledge and techniques of other people working on similar stuff, which is why this is a good open for discussion topic. Often it is the next iteration or re-write that hones in on more of that essence ~ going from magic to simple [in either direction] is not simple (or is it? ;-)

marak squires big company project includes a way of including dependency info in the actual script file and itself, which i thought was cool, i also like the way asp.v5 and C# is going with it's dependency injection annotations (and node inspired project.json, nugets, and quickstart standalone network stack) but am also in favour of inlining a few of the key things and flattening out the dependency graph and avoiding: build steps, version numbers, and nested dependency graphs as much as possible.

govpack commented 9 years ago

•The social coding contract - Justin Searls https://youtu.be/GxJW3Z_8Eew?t=10m

•Effective Dependency Management in JavaScript - Hector Virgen https://www.youtube.com/watch?v=Mxalg0ZN5XY

govpack commented 9 years ago

@xwipeoutx http://jspm.io/ as seen in https://www.youtube.com/watch?t=593&v=iukBMY4apvI or https://www.youtube.com/watch?t=795&v=NpMnRifyGyw might be worth a look, since it sends the browser separate files in development, (and i guess it builds smaller/changed bits as necessary only as needed) and has a large bower style look up, to resolve+include libraries using a short names, and can bundle up a build as well

iamkevinv commented 9 years ago

I've revisited this one - perhaps we could have some people who run node in production for companies in brisbane, who identify their apps as large, could explain some strategies employed to deal with it, and how successful each has been so far.