Skip to first unread message
Gehan Gonsalkorale
Oct 14, 2013, 4:55:08 PM10/14/13
to
Guys,
Benefits
I'm in the process of writing a tutorial for wire, trying to build up an example which shows each of the benefits of wire! The idea here is to sell wire as well as explain it. With a million libraries to choose from, a clear tutorial that sells as well as informs is critical I think. For me and the guys at work, there was a lot of resistance until the benefits were understood through usage. Theory is good but it's not until you see how it improves your life that you are sold I think. Hence I'm making this as I think it's great! :D
So to guide the tutorial, I need to have the top benefits in mind! What do you guys see as the main benefits, like top 5? I have the below so far
- Gives you a structured environment to work in (DI?) - forget you're in a browser
Not sure how to express this, but you can just define components really easy and put them where you want. I guess this relates to DI? I really like the dom/render and css plugins. I can just start defining modules and start coding - I forget I'm even in a browser actually!
- Allows you to be modular (di/connect) - your specs are like systems diagrams.
This relates to DI and connect. I love being able to make s component and then define how it interacts with another one - but independently from the modules themselves. My work mate said wire came into its own when he first used connect. Side benefit of modular means you can split up work easier between the team
- Easier to test (DI)
Since dependencies are injected you can test more easily, as you've probably coded behaviours/concerns into different components
Tutorial Steps
Also these are the steps so far in the tutorial FYI. The example is recreating gmail essentially, but in steps. I'm not certain about the steps yet so just exploring! This is just the code for each step - changes will be broken down and motivations/benefits explained in some snazzy page ;)
0 - Setup environment, blank spec. Just get the setup done.
1 - Basic layout (so spec just has html/css - introduces basic spec, yet has something tangible and a visible app)
2 - Enabling email previews (by adding backbone view and collection - introduces connect / DI)
3 - Adding the full email view (adds new backbone view for email, just just template for now). Perhaps this needs the
4 - Enable full email?
I want to have these in the tutorial too
- creating child specs for email list / email (putting things into components)
- have 'user session' in parent spec but used in children etc (how to use common objects)
- testing
There are loads I don't have but brain dead right now! Suggestions?
*edited to check basic layout link
Gehan Gonsalkorale
Oct 13, 2013, 5:16:41 PM10/13/13
to cuj...@googlegroups.com
This is rough and missing a lot of benefits/explanations but what about these for top-level benefits? These are the ones general to DI/IOC containers.
For benefits directly associated to wire, I was going to mention the plugin architecture as that's really powerful. Something about how you can abstract your common modules behaviours and connections into your own plugins etc.
Also stuff about curl/cram/when, high code quality and so on.
On Sunday, 13 October 2013 15:45:47 UTC+1, Gehan Gonsalkorale wrote:
Guys,BenefitsI'm in the process of writing a tutorial for wire, trying to build up an example which shows each of the benefits of wire! The idea here is to sell wire as well as explain it. With a million libraries to choose from, a clear tutorial that sells as well as informs is critical I think. For me and the guys at work, there was a lot of resistance until the benefits were understood through usage. Theory is good but it's not until you see how it improves your life that you are sold I think. Hence I'm making this as I think it's great! :DSo to guide the tutorial, I need to have the top benefits in mind! What do you guys see as the main benefits, like top 5? I have the below so far- Gives you a structured environment to work in (DI?) - forget you're in a browserNot sure how to express this, but you can just define components really easy and put them where you want. I guess this relates to DI? I really like the dom/render and css plugins. I can just start defining modules and start coding - I forget I'm even in a browser actually!- Allows you to be modular (di/connect) - your specs are like systems diagrams.This relates to DI and connect. I love being able to make s component and then define how it interacts with another one - but independently from the modules themselves. My work mate said wire came into its own when he first used connect. Side benefit of modular means you can split up work easier between the team- Easier to test (DI)Since dependencies are injected you can test more easily, as you've probably coded behaviours/concerns into different componentsTutorial StepsAlso these are the steps so far in the tutorial FYI. The example is recreating gmail essentially, but in steps. I'm not certain about the steps yet so just exploring! This is just the code for each step - changes will be broken down and motivations/benefits explained in some snazzy page ;)0 - Setup environment, blank spec. Just get the setup done.1 - Basic layout (so spec just has html/css - introduces basic spec, yet has something tangible and a visible app)
Gehan Gonsalkorale
Oct 14, 2013, 6:16:49 PM10/14/13
to cuj...@googlegroups.com
Started drafting the tutorial here:
I'm just writing out the content before bothering with any visuals at all!
Brian Cavalier
Oct 18, 2013, 10:00:40 PM10/18/13
to cuj...@googlegroups.com
Gehan, this is really awesome stuff. Took me a while to get to it, but I love what I see :)
You've touched most of the major benefits: separation of concerns, architectural structure, decoupling, testing. Two terms that we use a lot are "Application Composition" and "Composition Plan". These may help you frame (or expand on) many of the benefits.
Application Composition is the act of composing components into part of, or an entire application. This presupposes highly decoupled components. Application composition is typically a *very different* activity than implementing the business logic inside components. Traditionally, in the JavaScript world, these two activities and the code associated with them are smashed together: components become hopeless entangled with one another and with the connection mechanisms themselves.
A Composition Plan is a specific place or specific places in your codebase where you do application composition. It's like you said: a "system diagram", only in code! It's totally possible to do this without something like wire, but wire helps to give you these specific places (wire specs) and a compositional dsl (the object literal wire spec syntax) with constructs, like connect and the various other aop advices, that are tailored to doing composition (rather than implementing business logic algorithms, loops, etc.)
It's great to hear that you "forget you're in a browser". We really push hard for separation of DOM and component logic (by injecting dom nodes, or using wire/on, connect, aop etc.), and to hear that it's working for you in practice is great. Recently, I've been asked to review an application at my day job, and it's an intertwined mess of logic and direct dom manipulation. Trying to modify the code is almost impossible because the whole app just breaks when I change anything. It's impossible to tell where dependencies between JavaScript and the DOM--there's simply nowhere you can look and get a sense for how it all fits together. The only way is to change something, watch the application break, and then manually trace that to figure out how your change caused it.
Another big benefit is team scalability, both horizontal and vertical. Because the DOM and business logic are well separated, HTML/CSS specialists are often more free to make changes without breaking the JS, and vice versa. So adding team specializations becomes easier. Also, because the JS is decoupled and testable, it's also easier to add more JS engineers as the project needs. They won't be stomping on each others globals or getting into intertwined-global-dependency hell with each other, and everyone's code can be tested.
Speaking of testing, being able to assemble coarser grained components (think complex view components with HTML, CSS, and JS aspects), or even entire sections of an application, can make it easier to test those pieces without having to run the entire application. One huge problem we see a lot is that designers have to run the entire app, and dig 3, 4, 5, or 10 screens deep to see their latest designs and test user interactions. If screen 3 is busted, the designer trying to test screen 4 is simply out of luck. He/she has to go tell the engineering team that it's busted and someone has to go fix it in order to unblock the designer. Selenium can help here, but still, if screen 3 is busted, selenium also can't test screen 4. If smaller sections of the app can be tested, this problem can be mitigated or at least reduced.
Hope that helps! Keep up the great work on these tutorials!
Johan Chouquet
Jan 22, 2014, 6:48:55 PM1/22/14
to cuj...@googlegroups.com
Hi Gehan, Brian,
Brian, you're absolutely right about testing. Great job with CujoJS. I will discover it more with time.
This is great !! It helped me to understand more wire, curl, and how they can work together.
I need practice.
Brian, you're absolutely right about testing. Great job with CujoJS. I will discover it more with time.
Regards,
Johan
Johan
Le dimanche 13 octobre 2013 16:45:47 UTC+2, Gehan Gonsalkorale a écrit :
Guys,BenefitsI'm in the process of writing a tutorial for wire, trying to build up an example which shows each of the benefits of wire! The idea here is to sell wire as well as explain it. With a million libraries to choose from, a clear tutorial that sells as well as informs is critical I think. For me and the guys at work, there was a lot of resistance until the benefits were understood through usage. Theory is good but it's not until you see how it improves your life that you are sold I think. Hence I'm making this as I think it's great! :DSo to guide the tutorial, I need to have the top benefits in mind! What do you guys see as the main benefits, like top 5? I have the below so far- Gives you a structured environment to work in (DI?) - forget you're in a browserNot sure how to express this, but you can just define components really easy and put them where you want. I guess this relates to DI? I really like the dom/render and css plugins. I can just start defining modules and start coding - I forget I'm even in a browser actually!- Allows you to be modular (di/connect) - your specs are like systems diagrams.This relates to DI and connect. I love being able to make s component and then define how it interacts with another one - but independently from the modules themselves. My work mate said wire came into its own when he first used connect. Side benefit of modular means you can split up work easier between the team- Easier to test (DI)Since dependencies are injected you can test more easily, as you've probably coded behaviours/concerns into different componentsTutorial StepsAlso these are the steps so far in the tutorial FYI. The example is recreating gmail essentially, but in steps. I'm not certain about the steps yet so just exploring! This is just the code for each step - changes will be broken down and motivations/benefits explained in some snazzy page ;)0 - Setup environment, blank spec. Just get the setup done.1 - Basic layout (so spec just has html/css - introduces basic spec, yet has something tangible and a visible app)
2 - Enabling email previews (by adding backbone view and collection - introduces connect / DI)3 - Adding the full email view (adds new backbone view for email, just just template for now). Perhaps this needs the4 - Enable full email?I want to have these in the tutorial too- creating child specs for email list / email (putting things into components)- have 'user session' in parent spec but used in children etc (how to use common objects)- testingThere are loads I don't have but brain dead right now! Suggestions?
Brian Cavalier
Jan 23, 2014, 8:32:28 PM1/23/14
to cuj...@googlegroups.com
Cool, glad to hear that helped, Johan, and glad you are discovering cujoJS :) Don't hesitate to ask if you have questions.
Gehan Gonsalkorale
Jan 26, 2014, 6:01:17 PM1/26/14
to cuj...@googlegroups.com
Glad it is helpful! I should probably finish the tutorial though..! Any feedback at all? It's still a draft so very much open to change
Johan Chouquet
Jan 27, 2014, 9:45:58 AM1/27/14
to cuj...@googlegroups.com
Hi,
Steps 0 and 1 :
I had to add some environmental setup to make it work, but maybe I did something wrong. Hopefully, I managed to get it work quite easily.
Here is what I had to do : in the index.html : the following links did not work as is : "/lib/curl/src/curl.js", and "/app/run.js", but this works: "lib/curl/src/curl.js" and "app/run.js".
It's because I set my Apache config, within virtual host section this way:
DocumentRoot "C://my_path/gehan"
<Directory "C://my_path/gehan/seed">
#All stuff here to allow execution of scripts and so on.
</Directory>
So, even on http://localhost:83/seed (port 83 is the one I choose), Chrome is looking for http://localhost:83/lib/curl/src/curl.js and http://localhost:83/app/run.js
And DocumentRoot were giving me 403 Forbidden access (moreover, there were no /lib directory in the DocumentRoot, the lib directory was in the /seed directory).
So, there are 2 solutions :
1. change the index.html the way I did, OR
2. set DocumentRoot to the same folder as the webapp, and add an Alias this way : Alias /seed C://my_path/gehan/seed
Next, step 2 : git checkout wire-html
It works fine, except that there is no normalize-css/normalize.css folder/file in the lib directory. I created them, and that's it, Working perfectly.
Next, step 3 : git checkout wire-view
I get the new files, but for now, it's not doing anything.
That's it for now. I didn't digg in it further now. Of course, I'd be very interested if there were more. If I can, I would even contribute to it...
Regards,
Johan
Reply all
Reply to author
Forward
0 new messages