text:
Commonwealth v. Garcia (Lawyers Weekly No. 10-179-14)
COMMONWEALTH vs. JOONEL GARCIA.
Essex. December 6, 2013. – October 29, 2014.
Present: Spina, Cordy, Botsford, Duffly, & Lenk, JJ.
Homicide. Home Invasion. Burglary. Armed Assault with Intent to Rob. Felony-Murder Rule. Joint Enterprise. Evidence, Joint venturer, Impeachment of credibility, Cross-examination, Redirect examination, Accident. Constitutional Law, Assistance of counsel. Practice, Criminal, Required finding, Instructions to jury, Assistance of counsel, Capital case. Witness, Impeachment, Cross-examination, Redirect examination.
The cases were tried before David A. Lowy, J.
Jeffrey L. Baler for the defendant.
Kenneth E. Steinfield, Assistant District Attorney, for the Commonwealth.
DUFFLY, J. The defendant was indicted on charges of murder in the first degree and five related offenses in connection with the death of Rafael Castro on August 26, 2004.1 A Superior Court jury found the defendant guilty of murder in the first degree on theories of extreme atrocity or cruelty and felony-murder, based on the underlying felonies of both home invasion and armed or assaultive burglary. The jury also found the defendant guilty of the other charges. The jury did not specify whether they found the defendant guilty of any of the offenses as a principal or as a joint venturer.
On appeal, the defendant maintains that the evidence was insufficient to show that he shared the requisite intent to commit the crimes charged. The defendant contends also that his right to a fair trial was denied when he was not permitted to impeach a Commonwealth witness by confronting her with a child she observed outside the court room, whom she testified she believed to be her deceased child, although the witness was permitted on redirect examination to testify to the reasons she had formed that belief. In addition, the defendant asserts that a new trial is required because the judge erroneously declined to give two requested jury instructions, and because his counsel was ineffective for failing to object when the judge instructed that accident was not a defense to the killing. The defendant also requests that we exercise our authority to provide relief pursuant to G. L. c. 278, § 33E. We affirm the convictions, and discern no reason to grant a new trial or to reduce the verdict of murder in the first degree to a lesser degree of guilt.
Background. We summarize the facts the jury could have found, reserving certain facts for later discussion.
1. The shooting on August 26, 2004. Castro, whose street name was "Calvo," was a drug dealer. In August, 2004, Castro lived with Ramona Gonzalez in a sixth-floor apartment in an apartment building in Lawrence. At times, Gonzalez also was involved in drug dealing, as was her daughter, Norma Cedeno, who lived primarily in the Dominican Republic. On August 26, 2004, Gonzalez was in New York. Castro drove to Logan airport in Boston to pick up Cedeno, who was to arrive that evening from the Dominican Republic. After picking up Cedeno, Castro drove her back to the apartment building, where they arrived at approximately 11:15 P.M. Castro used his key to unlock the front door to the apartment. Cedeno entered the darkened apartment first, putting down some takeout food they had purchased en route, and heading directly to the bathroom. Although the apartment lights were off, there was some illumination from exterior street lighting. As Cedeno took a step into the bathroom, a man grabbed her and threw her to the floor, holding her down while putting a gun to the back of her neck and ordering her to look down. Cedeno cried out, "Oh my God."
Earlier that day, the defendant and his girl friend, Jessica Encarnacion, had been in their apartment when a man known as "Gringo"2 arrived with two other men, Cesar Santana and Alfredo Catalino. Another man, "Propeto," had arrived at the defendant's apartment separately several hours earlier in the day, and was there when Gringo and the other two men arrived.3 The four men often socialized together. Gringo, who was acquainted with Castro, told the defendant that there was "a job to do," and that they were going to "take something from Calvo . . . some drugs that he had" that had been brought from Texas. If the defendant agreed to help, they would be able to live as "retirees." Around 2 P.M., Gringo drove the defendant to Castro's apartment building and pointed it out to him. Later that night, Gringo drove the defendant, Santana, and Catalino to the apartment building.4 Gringo said that he had learned that Castro was not there, and they would wait for Castro to return.
The four men, two of whom had guns, entered the building using a pass card Gringo had and then entered Castro's apartment using a key that Gringo produced. They waited in the apartment for approximately thirty minutes before they heard a door opening. At that point, Gringo told the defendant, Santana, and Catalino to go into the bathroom and that he, Gringo, would remain in the living room. Castro entered the apartment after Cedeno, and started to run toward the living room when another man "jumped" out to meet him. Castro lunged at the man, and the man shot Castro in the forehead, seriously injuring him. The bullet, which did not penetrate Castro's face, traveled diagonally downward from the top of his forehead, where the wound was deepest, over his right eye and cheek, lacerating the skin. He was alive, but bleeding profusely. Some of the men, including the defendant, took Castro into the smaller of the apartment's two bedrooms. The men, whose voices she did not recognize, told Cedeno that they would kill her if she looked up because she "was going to know who they were," and put a pillow case over her head, which remained covered until the men left the apartment. Cedeno was taken to the larger bedroom where one of the men remained with her.
Some of the men wrapped duct tape around Castro's ankles and wrists,5 and one or more yelled at Castro, demanding drugs and money. When Castro denied that he had any drugs, the men demanded that he make a telephone call. Castro offered to get them $ 20,000 if they cut him loose, but the men laughed at this offer and refused. They continued to yell at Castro, and to hit him. Cedeno could hear Castro whimpering and groaning in pain, asking them to remove the tape, and repeatedly asking for water. At one point, Cedeno was brought into the room with Castro; the men took off her shirt and threatened to burn her with a hot iron. Cedeno "could smell the burn of the iron," and she implored Castro to tell the men what they wanted to know. In a weak voice, Castro said, "Don't do it." One of the men put Cedeno's shirt back on and took her back to the other bedroom. Cedeno could hear the men walking around the apartment making calls on their cellular telephones, becoming angrier, and saying things like, "He doesn't want to talk," and, "He doesn't want to make the phone call. What are we going to do next?" One of the men said they should "[j]ust kill him."
A man tied Cedeno's ankles with duct tape, but she persuaded him not to tie her hands. The man told Cedeno that three of them were leaving, but that one was going to stay behind in case she tried to call the police. In an angry voice, he told her, "We already know who you are, so if you call the police, or . . . one of us get[s] caught, we [are] just going to come back and get you." He said that he had a blade in his hand and would cut her face, and that they "all [had] guns." Approximately ninety minutes had passed since the incident began. When the man left, Cedeno heard the door shut, but was not sure whether any of the other men remained in the apartment. She waited before calling out to Castro and asking if he was there alone; in a faint voice, he asked her to open the door and help him. Cedeno pulled herself into the kitchen and cut the duct tape from her ankles with a knife.
The door to the bedroom in which Castro had been placed was locked, and Cedeno used part of a bracelet to pick the lock. Castro was lying on the floor and there was a lot of blood, particularly on his face. She removed the duct tape binding him, and held his hand for a short time to comfort him. She tried calling for help on the apartment's telephone, but it had been pulled from the wall, and the intruders had taken Castro's cellular telephone. Cedeno found another telephone and telephone cord in a drawer, and used it first to call her mother and Ricardo Rosa, a former boy friend who lived in the same building and was a friend of Castro's. She was afraid to contact police at that point because she did not know if the men were waiting to see if she would do so. After speaking with her mother and Rosa, Cedeno telephoned 911; an ambulance, dispatched at 12:53 A.M., arrived three to four minutes later. Upon arriving, paramedics saw an "extremely large pool of blood" and found Castro lying on the bedroom floor. They determined that Castro was dead and notified Lawrence police at 1:03 A.M. The cause of death was cardiac arrest resulting from loss of blood from the gunshot wound to the forehead.
2. Flight from Massachusetts. Encarnacion and Propeto were watching television when the defendant returned to his apartment at approximately 1 A.M, accompanied by Gringo, Santana, and Catalino. The defendant was not wearing the clothes he had been wearing when he left, but, rather, was wearing "girl's pants" and a different shirt. When he took off that shirt, Encarnacion could see the front of the shirt that the defendant had been wearing earlier, covered with blood spatter. Encarnacion also observed blood spatter on the defendant's shoes. When she asked about the blood and the pants, the defendant said that nothing had happened and not to worry about it. He told her: "Just, [s]hut up. Get me a bag. I need to take these clothes off and put them in a bag. And just keep packing. We have to leave here to [go] out of state."
Encarnacion gave the defendant a trash bag; he put the clothes he had been wearing into the bag, and left the apartment with it. Gringo, Santana, and Catalino went with him. They returned five minutes later, without the bag.6 The defendant was acting nervous. In response to Encarnacion's questions, he told her that he had discarded the bag; when she asked why, he said, "I'll talk to you when we get out of here." He then said that they would have to go to the Dominican Republic because his visa was expiring. Less than fifteen minutes later, they left in Gringo's automobile, headed for John F. Kennedy Airport in New York.
During the drive, the defendant took a gun from a bag; it was gray with a laser light. Encarnacion had never seen the gun before. The defendant said, "Damn, I bought a gun and now I have to throw it away," then, later, "[s]uch a good gun, and I have to throw it away." The men discussed how to get rid of the gun. After approximately half an hour, they took an exit off of the highway and stopped; the defendant and Gringo took the bag that held the gun and disappeared into the woods. They were gone seven minutes while the others waited in the vehicle. When the two men returned, the defendant said that they would go to New York "as soon as possible" and take "the first plane to [the] Dominican Republic." No one responded when Encarnacion asked what had happened.
At the airport, Gringo gave the defendant $ 1,000 in cash, which Encarnacion used to purchase two one-way tickets on a flight leaving for the Dominican Republic at 7 A.M. During the flight, the defendant told Encarnacion that something really bad had happened, but that he was not going to talk until he had a chance to calm down and get some rest. Once they had landed and had reached the defendant's brother's house, the defendant told Encarnacion that he had gone to claim some money that someone owed him for drugs, and that he, Gringo, Santana, and Catalino waited in the man's apartment until the man arrived. The defendant said that he was with Gringo in the bathroom, and Gringo had the gun because he planned to scare the man into giving him the money that the man owed. When the man opened the bathroom door and turned on the light, he was shocked to see Gringo with a gun. The man was trying to take the gun from Gringo when the gun went off accidentally and shot the man. The defendant said that they had not expected the man's daughter, who had walked into the apartment with the man, to be there. The defendant and Catalino tied the man up using duct tape and told the man that they would make a call for the money, but they did not get anything and left.
Encarnacion eventually returned to Lawrence and spoke with police several times concerning the events of August 26. The defendant was arrested after he, too, returned to Lawrence. While at the Suffolk County house of correction, the defendant gave an audiorecorded statement to police, in which he admitted to going to Castro's apartment with the other three men on August 26, intending to rob Castro, but stated that Gringo had been the one holding the gun, which the defendant said discharged accidentally when Castro lunged at Gringo.
Discussion. 1. Sufficiency of the evidence. The defendant claims that the evidence was insufficient to establish that he shared the intent required to support his convictions of murder, home invasion, armed or assaultive burglary, and armed assault with intent to rob.7 In reviewing a claim of insufficient evidence, we ask whether, viewing the evidence in the light most favorable to the Commonwealth, "any rational trier of fact could have found the essential elements of the crime beyond a reasonable doubt." Commonwealth v. Perez, 460 Mass. 683, 702 (2011), quoting Commonwealth v. Latimore, 378 Mass. 671, 677 (1979). We take this view of the evidence notwithstanding any evidence to the contrary presented by the defendant. Commonwealth v. Latimore, supra at 676-677.
In reviewing the sufficiency of the evidence on a theory of joint venture, we consider whether the evidence supports a finding that "the defendant knowingly participated in the commission of the crime charged, alone or with others, with the intent required for that offense." Commonwealth v. Norris, 462 Mass. 131, 138-139 (2012), quoting Commonwealth v. Zanetti, 454 Mass. 449, 468 (2009). "The felony-murder rule 'imposes criminal liability for homicide on all participants in a certain common criminal enterprise if a death occurred in the course of that enterprise.'" Commonwealth v. Hanright, 466 Mass. 303, 307, (2013), quoting Commonwealth v. Matchett, 386 Mass. 492, 502 (1982). To be liable for felony-murder, a defendant need only possess the intent necessary for the underlying felony. Commonwealth v. Hanright, supra. Because the underlying felonies here of home invasion, G. L. c. 265, § 18C, and armed burglary, G. L. c. 266, § 14, as well as the separate offense of armed assault with intent to rob, G. L. c. 265, § 18 (b), require that the Commonwealth establish that the perpetrator was armed, "knowledge of a weapon is an element of the Commonwealth's proof when a defendant is prosecuted on a theory of joint venture." Commonwealth v. Britt, 465 Mass. 87, 99 (2013). See Commonwealth v. Gorman, 84 Mass. App. Ct. 482, 489 (2013).
The evidence presented would have allowed the jury to find that the defendant intended to aid in robbing Castro and that he knew that at least one of the intruders was armed. The jury heard evidence that the defendant agreed to go with Gringo to take a large quantity of drugs from Castro; that the defendant went to Castro's apartment with Gringo to become familiar with it and then returned at a time when they had information that Castro would not be present; that at least two of the men were armed when they entered the apartment; that upon hearing Castro unlocking the door, some of the men secreted themselves in the bathroom; that one of the men wanted to use a gun to scare Castro into giving them money, and shot Castro soon after Castro entered the apartment; and that one of the guns wielded belonged to the defendant who was in possession of it shortly after the men left the apartment. This evidence sufficed to show that the defendant had the requisite intent to commit home invasion, armed burglary, and armed assault with intent to rob.
The defendant's actions after the men left Castro's apartment provided additional evidence of an intent to participate in a joint venture to commit the crimes charged. The four men returned together to the defendant's apartment, where they discarded his bloodied clothing, and planned and executed a further escape. See Commonwealth v. Akara, 465 Mass. 245, 255 (2013), and cases cited (defendant seen holding gun and standing near coventurer immediately before shooting, and fleeing while laughing with coventurers immediately after shooting); Commonwealth v. Williams, 422 Mass. 111, 121 (1996) ("Joint venture may be proved by circumstantial evidence, including evidence of flight together"). Hence, viewing the evidence in the light most favorable to the Commonwealth, the jury heard sufficient evidence to conclude beyond a reasonable doubt that the defendant was guilty of armed home invasion and armed burglary and, consequently, of felony-murder, as well as of assault with intent to rob. See Commonwealth v. Pytou Heang, 458 Mass. 827, 836 (2011).
There was also sufficient evidence from which the jury could have concluded that the defendant possessed the requisite intent to commit murder in the first degree on a theory of extreme atrocity or cruelty. The mental intent necessary to support such a conviction is malice. Commonwealth v. Szlachta, 463 Mass. 37, 47 (2012), quoting Commonwealth v. Cunneen, 389 Mass. 216, 227 (1983). "Malice is defined in these circumstances as an intent to cause death, to cause grievous bodily harm, or to do an act which, in the circumstances known to the defendant, a reasonable person would have known created a plain and strong likelihood that death would follow." Commonwealth v. Szlachta, supra at 45-46, quoting Commonwealth v. Chhim, 447 Mass. 370, 377 (2006).
Here, the Commonwealth introduced evidence that, while Castro was bleeding profusely following the shooting, the defendant and the other intruders bound and repeatedly struck him as he moaned in pain and asked for water. See Commonwealth v. Semedo, 422 Mass. 716, 720 (1996), citing Commonwealth v. Mahoney, 406 Mass. 843, 848 (1990) (sufficient evidence of malice based on plain and strong likelihood of death, where reasonable person would have known that victim could suffer death as beating progressed); Commonwealth v. Plunkett, 422 Mass. 634, 637 (1996) (evidence would have sufficed to show malice based on plain and strong likelihood of death where defendant bound and gagged victim, resulting in victim's death). Castro's voice became weak during the time the intruders were in the apartment, while they were musing aloud on whether they should kill him; the defendant himself described Castro as barely alive by the time he and the other men left. Furthermore, before departing, the intruders locked the door to the bedroom where Castro was restrained at both his hands and his feet, pulled the apartment telephone cord from the wall, took Castro's cellular telephone, warned Cedeno not to call for help, and left her in another room with her ankles bound. The jury could have found that a reasonable person would have known that all of these actions impeded Castro's ability, while bleeding heavily, to obtain emergency assistance, and that there was a plain and strong likelihood that death would follow. See Commonwealth v. Auclair, 444 Mass. 348, 363-364 (2005); Commonwealth v. Maynard, 436 Mass. 558, 562-563 & n.4 (2002); Commonwealth v. Perry, 432 Mass. 214, 218, 221-224 (2000).
2. Impeachment of Commonwealth's witness. In addition to challenging the sufficiency of the evidence, the defendant contends that he was denied his right to a fair trial because he was not permitted to impeach Encarnacion by confronting her with a child whom she had observed outside the court room and believed to be her deceased daughter. On direct examination, Encarnacion testified that she became pregnant with the defendant's child while they were in the Dominican Republic, after their arrival on August 27, 2004. She returned to the United States in February or March of 2005, and ended her relationship with the defendant that June. Encarnacion gave birth to her daughter on August 22, 2005.8
Toward the end of Encarnacion's direct examination, the prosecutor questioned her about statements she made to police soon after returning to Lawrence. Encarnacion testified that she had lied at that time, in particular regarding her knowledge of the gun and its disposal, and her trip to the airport in New York with the defendant in August, 2004. She testified that she had been afraid, that she believed she could go to jail because she knew something about a murder, and that she had been depressed, but that she had since been seeing a therapist and taking medication. Encarnacion said that she was in court because she wanted to be honest and tell the truth and she no longer wanted to put herself in the "middle of anything."
On cross-examination, defense counsel elicited testimony that Encarnacion had sworn to tell the truth when she appeared before the grand jury, but that she had lied in testifying that, when the defendant came back to their apartment with blood on his clothes, he was crying and saying things such as, "I can't believe Gringo made me do this." Encarnacion insisted that although she had lied out of fear for her life, she was being honest in her trial testimony. "At that point, I was trying to defend him, but now I'm not defending nobody. . . . I have three kids. I have two living with me. One, his mother took away, which I'm going to fight back. And I am not here to put him down. Because if I really wanted to put him down, I would have just came to the police and made up another story saying maybe he shot the guy; don't you think?"
At that point, defense counsel asked, "You just told the jury that [the defendant's] mom -– who's out in the hall, right? – has your daughter, [a]nd you're now going to fight to get your daughter." Encarnacion responded:
"Because she told me my daughter was dead for three years. She adopted my daughter, and made me believe my daughter was dead for three years. And she brings her today, to this court, to make me look nervous and make me look stupid and maybe put myself in the middle for this: okay. I'm very nervous right now. My daughter is alive. She made me believe for three single years. I ended up in a psychology center, cutting myself, going crazy, thinking my daughter is dead. And all of a sudden, she's here today? That's not fair. That's not fair."
See note 8, supra. Defense counsel also asked whether Encarnacion had attempted suicide because the defendant's mother had custody of her daughter, to which Encarnacion replied, "No. Because she made me believe my daughter was dead."
After a brief recess, defense counsel questioned Encarnacion regarding her perceptions of the child in the hallway whom she believed to be her daughter. He elicited testimony that Encarnacion's daughter would have been a little over three years old, and then sought to present the child, whom defense counsel described as fifteen months old, to the jury, in order to show that the child could not rationally have been mistaken for a three year old. The judge denied as collateral and unduly prejudicial the request to present the child for Encarnacion to identify and for the jury to see. He noted that the information could be introduced through other means, such as testimony by other witnesses.9
The defendant contends that the judge impeded his ability to cross-examine Encarnacion by denying his request to present the child in court and by allowing the Commonwealth to rehabilitate Encarnacion on redirect examination with details regarding the circumstances in which she saw the child. The Massachusetts and Federal Constitutions guarantee a defendant's right to cross-examine prosecution witnesses. See Commonwealth v. Meas, 467 Mass. 434, 449 (2014), quoting Commonwealth v. Allison, 434 Mass. 670, 681 (2001); Commonwealth v. Mercado, 456 Mass. 198, 202 & n.9 (2010). "Nevertheless, a judge may limit the scope of cross-examination as long as he or she does not completely bar inquiry into a relevant subject." Commonwealth v. Williams, 456 Mass. 857, 873 (2010). A judge has broad discretion in circumscribing the proper scope of cross-examination, Commonwealth v. Mercado, supra at 203; Commonwealth v. Vardinski, 438 Mass. 444, 451 (2003), and may impose such limits "based on concerns about, among other things, harassment, prejudice, confusion of the issues, the witness's safety, or interrogation that is repetitive or only marginally relevant." Commonwealth v. Johnson, 431 Mass. 535, 540 (2000), quoting Delaware v. Van Arsdall, 475 U.S. 673, 679 (1986). See Commonwealth v. Avalos, 454 Mass. 1, 7 (2009), and cases cited. To determine whether a judge acted beyond this discretion, "we weigh the materiality of the witness's direct testimony and the degree of the restriction on cross-examination." Commonwealth v. Mercado, supra, quoting Commonwealth v. Vardinski, supra. The defendant bears the burden of proving that the judge acted improperly. See Commonwealth v. Avalos, supra, quoting Commonwealth v. Weichel, 403 Mass. 103, 105 (1988).
We conclude that the judge did not abuse his discretion in prohibiting the defendant from presenting the child for Encarnacion to identify and for the jury to see. Notwithstanding the materiality of Encarnacion's testimony in corroborating the defendant's participation in the killing, the judge did not "bar all inquiry into the subject" of her mental state. See Commonwealth v. Avalos, supra at 7, quoting Commonwealth v. Allison, supra at 681. Defense counsel elicited testimony that Encarnacion had struggled in the past with mental health issues, that no one had told her that the child she saw was her daughter, that her only reason for believing the child to be her daughter was that she saw from afar the defendant's mother holding the child, and that she made no attempt to verify the child's identity at that time. Furthermore, although he would not allow the child to be brought into the court room, "[t]he trial judge provided counsel an opportunity" to present other evidence of the child's age and physical appearance, which counsel ultimately decided not to do. See Commonwealth v. Williams, 456 Mass. at 873. The judge had discretion to limit the manner in which counsel could offer evidence of the child's apparent age. Cf. Commonwealth v. Mercado, supra at 203-204 (judge could limit defense counsel's use of "inflammatory" photographs on cross-examination where counsel thoroughly cross-examined witness regarding point in question). In particular, the judge noted his concern that presenting the child in the court room would cause Encarnacion unnecessary distress. Cf. Commonwealth v. Johnson, 431 Mass. at 540, quoting Alford v. United States, 282 U.S. 687, 694 (1931) (judge should "protect [a witness] from questions which go beyond the bounds of proper cross-examination merely to harass, annoy or humiliate").
The defendant contends also that Encarnacion's testimony on redirect examination was overly broad and unduly prejudicial because it suggested that the defendant and his mother had acted intentionally to provoke Encarnacion's response to the child. "The purpose of redirect examination is to explain or rebut adverse testimony or inferences developed during cross-examination." Commonwealth v. Borgos, 464 Mass. 23, 35 (2012), quoting Commonwealth v. Hoffer, 375 Mass. 369, 375 (1978). As with cross-examination, a trial judge has considerable discretion over the scope of redirect examination. See Commonwealth v. Rosario, 460 Mass. 181, 193 (2011); Commonwealth v. Ostrander, 441 Mass. 344, 356, cert. denied, 543 U.S. 867 (2004). A defendant who asserts an abuse of this discretion on appeal "assumes a heavy burden." Commonwealth v. Arriaga, 438 Mass. 556, 577 (2003), quoting Commonwealth v. Maltais, 387 Mass. 79, 92 (1982). See Commonwealth v. Ostrander, supra at 356-357, quoting Commonwealth v. Roberts, 433 Mass. 45, 51 (2000) (judge has "nearly unreversible discretion" with respect to redirect examination).
The judge in this case carefully limited the scope of redirect examination. The defendant's challenge to Encarnacion's credibility, based on her belief that the child she saw in the court house was her daughter, opened the door for the Commonwealth to rehabilitate Encarnacion by allowing her to explain the circumstances that led her to form this belief. See Commonwealth v. Arriaga, 438 Mass. at 577; Commonwealth v. Marrero, 427 Mass. 65, 69 (1998); Commonwealth v. Olszewski, 416 Mass. 707, 718 (1993), cert. denied, 513 U.S. 835 (1994). In particular, the judge permitted Encarnacion to testify that the defendant's mother had informed her of her daughter's death in the course of berating and threatening her for cooperating with police; that she never received confirmation of her daughter's death, such as a death certificate or photographs from the funeral; that she saw the defendant's mother holding a baby girl in the court house hallway; and that the child resembled her daughter. "Having opened the door to this information, . . . the defendant's claim of prejudice is highly suspect." Commonwealth v. Marrero, supra, quoting Commonwealth v. Otsuki, 411 Mass. 218, 236 (1991).
At the same time, the judge minimized the prejudicial impact of the testimony by preventing the prosecutor from suggesting that the defendant or his mother intentionally arranged Encarnacion's encounters with the child in order to provoke her reaction.10 He sua sponte cut-off Encarnacion's testimony when it appeared that she would begin testifying about the motive of the defendant's mother. Likewise, when Encarnacion testified that she thought the defendant's mother was attempting to "intimidate" her, the judge asked defense counsel if he would like to have that comment stricken. Defense counsel declined, apparently based on his strategic assessment that Encarnacion's testimony sounded irrational and only harmed her credibility; at sidebar, defense counsel suggested that the longer Encarnacion testified about the child, the more irrational she appeared. Finally, the judge repeatedly offered to issue a limiting instruction, which defense counsel declined, that Encarnacion's testimony on redirect examination was to be used only to evaluate her credibility. See Commonwealth v. Stone, 70 Mass. App. Ct. 800, 807 (2007) ("The trial judge's offer to give a jury instruction to emphasize the limited relevance of [the witness's] testimony shows the extent to which he analyzed the prejudicial effect versus the probative value before deciding in favor of admissibility").
The defendant argues that presenting alternative evidence of the child's appearance or requesting a limiting instruction would have exacerbated the prejudice to him by drawing greater attention to his possible role in a scheme to manipulate Encarnacion. Defense counsel was free to make such a tactical assessment, but we presume that the jury would have heeded any limiting instruction. See Commonwealth v. Roberts, 433 Mass. 45, 52-53 (2000). There was no abuse of discretion in the manner in which the judge limited the scope of Encarnacion's cross-examination and her redirect examination.
3. Failure to instruct on second-degree felony-murder based on uncharged offense. The defendant argues that it was error to decline to give an instruction on felony-murder in the second degree based on the uncharged offense of distribution of cocaine. Whereas felony-murder in the first degree is predicated on a felony that is punishable by a sentence of life in prison, felony-murder in the second degree is predicated on a felony with a maximum sentence of less than life in prison. See Commonwealth v. Burton, 450 Mass. 55, 57 (2007). To support a conviction of felony-murder in the second degree, there must be a homicide that occurs during the commission or attempted commission of a felony; the homicide must be a "natural and probable consequence" of the predicate felony, see Commonwealth v. Stokes, 460 Mass. 311, 315 (2011); and the felony must be either "inherently dangerous" or "committed so that the circumstances demonstrate 'the defendant's conscious disregard of the risk to human life.'" Commonwealth v. Burton, supra, quoting Commonwealth v. Matchett, 386 Mass. 492, 508 (1982). A defendant is entitled to an instruction on felony-murder in the second degree only if there is a rational basis in the evidence to support such a conviction. See Commonwealth v. Bell, 460 Mass. 294, 306-307 (2011). "[T]he felony on which a charge of felony-murder is premised may be uncharged, so long as the evidence supports it." Commonwealth v. Stokes, supra.
The defendant requested an instruction on felony-murder in the second degree predicated on the uncharged offense of "drug distribution." The judge denied the request on the ground that the evidence did not provide a rational basis for conviction of that offense. The predicate felony of "drug distribution," whether understood as distribution of a controlled substance or as possession with intent to distribute a controlled substance, requires proof of possession. See G. L. c. 94C, §§ 32A, 32B, 32C, 32D, 32E. The only evidence supporting the defendant's theory of "drug distribution" was that the defendant, the joint venturers, and the victims all were drug dealers, and the defendant's statement that he went to the apartment to collect "like a debt" from Castro in the form of drugs that he believed Castro had "brought . . . from Texas." There was no evidence that controlled substances were present in the apartment, or that any of the intruders came into possession of the drugs the defendant alleges they were there to collect. In the absence of evidence supporting possession or constructive possession of a controlled substance, the jury could not permissibly have found that the defendant committed the felony of distribution of a controlled substance or possession with intent to distribute a controlled substance. Therefore, there was no error in the denial of the defendant's request for an instruction on murder in the second degree predicated on such offenses.11
4. Instruction on intervening cause. The defendant maintains also that the judge erred in declining to give a requested instruction on intervening cause, arguing that the evidence warranted a finding that Castro's death was caused by Cedeno's intentional delay in contacting emergency personnel.12 This argument is unavailing. If "death follows as a consequence of [an individual's] felonious and wicked act, it does not alter its nature or diminish its criminality to prove that other causes cooperated in producing the fatal result." Commonwealth v. McLeod, 394 Mass. 727, 744-745, cert. denied sub nom. Aiello v. Massachusetts, 474 U.S. 919 (1985), quoting Commonwealth v. Hackett, 2 Allen 136, 142 (1861). See Commonwealth v. Davis, 403 Mass. 575, 582 (1988). "The general rule is that the intervening conduct of a third party will relieve a defendant of culpability only if such an intervening response was not reasonably foreseeable." Commonwealth v. Rosado, 434 Mass. 197, 203, cert. denied, 534 U.S. 963 (2001), quoting Commonwealth v. Niemic, 427 Mass. 718, 727 (1998). Although "the judge was required to instruct the jury on any issues which could be inferred from the evidence," Commonwealth v. McLeod, supra at 745, he was not required to give a requested instruction unless competent evidence proffered by the defendant, viewed in a light favorable to him, reasonably supported such an inference.
The defendant points to evidence that, viewed favorably to him, he contends would support a reasonable inference that Cedeno delayed at least several minutes before calling 911 and requesting emergency medical assistance: she first made telephone calls attempting to reach her mother and her former boy friend who lived in the same apartment building as Castro.13 It was reasonably foreseeable, however, that there would be a delay before emergency medical assistance would reach Castro. At most, the effect of Cedeno's delay "was merely to prevent any recovery that might otherwise have taken place." Commonwealth v. Costley, 118 Mass. 1, 27 (1875). It was not an intervening cause that then became the proximate cause of Castro's death. Because the evidence does not support the defendant's theory of an intervening cause, the judge did not err in refusing to grant the requested instruction. See Commonwealth v. McLeod, 394 Mass. at 744-745.
5. Instruction that there was no evidence of accident. The defendant contends that the judge provided an erroneous instruction in connection with the charge of murder in the first degree based on the theory of extreme atrocity or cruelty, and that his counsel was ineffective for failing to object to the instruction. Because the defendant did not object, we review to determine whether any error created a substantial likelihood of a miscarriage of justice. See Commonwealth v. Jewett, 442 Mass. 356, 370 (2004). Likewise, when "the defendant has been convicted of murder in the first degree, 'we consider his claim of ineffectiveness of counsel to determine whether there exists a substantial likelihood of a miscarriage of justice . . . which is more favorable to a defendant than the constitutional standard for determining ineffectiveness of counsel.'" Commonwealth v. Franklin, 465 Mass. 895, 909 (2013), quoting Commonwealth v. Walker, 460 Mass. 590, 598 (2011). We conclude that there was no error.
As to the first element of murder in the first degree on a theory of extreme atrocity or cruelty, the judge instructed:
"[T]he Commonwealth must prove to you beyond a reasonable doubt . . . that the defendant committed an unlawful killing. For a killing to be murder, it must be unlawful. An unlawful killing is a killing done without excuse. Not all killings are unlawful. A killing may be excused, for example, in cases of self-defense, defense of another, or in some cases, accident. The evidence in this case does not raise the issue of whether the killing was excused as a result of self-defense, defense of another, or accident."
The defendant argues that the last sentence of this instruction prevented the jury from considering accident to mitigate malice. However, a "judge's comment to the jury regarding the absence of accident [is] not an invasion of their fact-finding function" unless the issue of accident is "fairly raised" by the evidence. See Commonwealth v. Podkowka, 445 Mass. 692, 698-699 (2006).
In support of his argument that the killing occurred accidentally, the defendant focuses exclusively on evidence related to the shooting itself. As the judge instructed, however, "As to the charge of murder, the Commonwealth does not allege that the shooting of Raphael Castro, in and of itself, was the act that constitutes the killing. Rather, the Commonwealth alleges that the shooting, along with the acts allegedly taken thereafter, caused Mr. Castro's death." We presume that the jury followed this instruction, see, e.g., Commonwealth v. Morales, 461 Mass. 765, 784 (2012), and therefore that they relied on the evidence introduced regarding the intruders' conduct after the shooting. This evidence included that the intruders bound Castro with duct tape, repeatedly struck him, and left him in a locked room without a telephone, while he bled profusely. Evidence of such conduct suffices to prove malice, even if the defendant did not intend Castro's death, see Commonwealth v. Plunkett, 422 Mass. 634, 637 (1996), and there is no suggestion that any of this conduct was accidental. Hence, because the jury were not called upon to decide whether the shooting itself was accidental, the issue of accident was not fairly raised and the judge's instructions were not erroneous.
6. Relief pursuant to G. L. c. 278, § 33E. Having carefully reviewed the entire record pursuant to our duty under G. L. c. 278, § 33E, we discern no reason to reduce the verdict of murder in the first degree or to order a new trial.
Judgments affirmed.
1 The other indictments charged home invasion, G. L. c. 265, § 18C, armed or assaultive burglary, G. L. c. 266, § 14, armed assault with intent to rob, G. L. c. 265, § 18 (b), and two counts of kidnapping, G. L. c. 265, § 26, one with respect to Rafael Castro and one with respect to Norma Cedeno.
2 The defendant rented the apartment from "Gringo," who was also known by several other names, including Ramon Ortiz, Ramon Ortiz Peralta, Josue (or Joshua or Joseph) Martinez Vargas, and Santo Delarosa.
3 Although the spelling "Propito" also appears in the record, we refer to "Propeto" for convenience.
4 Propeto did not go with the others to Castro's apartment, but was watching television with the defendant's girl friend, Jessica Encarnacion, when the four men returned at approximately 1 A.M.
5 According to expert testimony, the defendant's right thumb print matched a latent print on a role of duct tape police found in the apartment.
6 Propeto left with the other men, but did not return with them.
7 The defendant conceded at trial that the evidence was sufficient to support a finding of guilt as to both charges of kidnapping.
8 Encarnacion subsequently testified that she agreed to surrender the child to the defendant's mother in the Dominican Republic because of Encarnacion's then drug problems and unstable living circumstances. Sometime roughly in December, 2006, after Encarnacion had begun speaking to police and the defendant had been charged in this case, the defendant's mother and brother told Encarnacion that her daughter had died. Encarnacion neither sought nor received confirmation of her daughter's death.
9 At side bar, counsel described Encarnacion as having gone off "on this tirade that I think is irrational, and shows she's psychotic." The judge inquired of both attorneys if they thought the witness was "too distraught to testify" further that day, and the prosecutor agreed that she was. Encarnacion's testimony resumed the following day.
10 The judge expressed concern that the defendant might be unduly prejudiced if the jury were to conclude that the defendant or his family had devised the plan to bring the child into the court house and display her to Encarnacion in order to unhinge her, and, on that basis, further conclude that the defendant had done so because he was guilty of the charged offenses and needed to impeach the person to whom he had confessed.
11 In his reply brief, the defendant suggests that the evidence sufficed to show attempted distribution of a controlled substance. We need not address the merits of this argument because the defendant was not charged with this offense and did not request an instruction on the basis of this offense. See Commonwealth v. Stokes, 460 Mass. 311, 315 (2011). Moreover, even had there been error, there would have been no prejudice to the defendant in declining to give such an instruction where, as here, the defendant "was also convicted under the alternate theor[y] of . . . extreme atrocity or cruelty." See Commonwealth v. Brum, 438 Mass. 103, 119 n.23 (2002).
12 This claim hinges in part on the defendant's argument "that Cedeno had a motive to allow Castro to bleed to death by delaying the 911 call in order to advance in the drug organization." The evidence does not support such an inference.
13 Viewing the evidence favorably to the defendant, Castro was still alive when the men left the apartment. In his statement to police, the defendant described Castro's condition as "kind of alive," and said, "Calvo was still sort of alive" when they left.
Posted by Massachusetts Legal Resources - October 29, 2014 at 8:19 pm
Categories: News Tags: 1017914, Commonwealth, Garcia, Lawyers, Weekly


text:
\section{Introduction}		\label{sec:intro}

In this note we prove two results, one known and one new, involving binomial
sums where the absolute value function occurs in the summands.

Lemma~\ref{lemma:Best} is a binomial sum which has appeared
several times in the literature, e.g.~Alon and Spencer~\cite[\S2.5]{AS},
Best~\cite[proof of Theorem 3]{Best}, Brown and Spencer~\cite{BS},
Erd\H{o}s and Spencer~\cite[proof of Theorem 15.2]{ES}.
It was also a problem in the
1974 Putnam competition~\cite[Problem A4]{Putnam74}.
Lemma~\ref{lemma:Best} can be used
to calculate the mean of each diagonal term that arises
when the probabilistic method is used to give lower bounds for
the Hadamard maximal determinant problem, as in~\cite{rpb253}.

Our new result is Theorem~\ref{thm:double_sum}, which gives a closed-form
expression for a double sum which is analogous to the single sum of
Lemma~\ref{lemma:Best}. Theorem~\ref{thm:double_sum} can be used to
calculate the second moment of each diagonal term that arises when the
probabilistic method is used to give lower bounds for the Hadamard maximal
determinant problem.  In~\cite[Theorems 2--3]{rpb253} we gave lower bounds
without using this second moment, but such results can be improved if
the second moment is known~\cite{rpbxxx}.

To prove Theorem~\ref{thm:double_sum} we first use symmetry to eliminate the
absolute value function occurring in the sum, and then use a
two-variable variant of the method of telescoping sums, where the
double sums collapse to give single sums which can be
evaluated explicitly. The ``magic'' cancellation giving the final result
suggests that a simpler proof could exist, but we have not found such
a proof.

\subsection*{Notation}

The variables $k$, $n$, $p$, $q$ denote integers
(not necessarily positive).

The binomial coefficient $\binom{n}{k}$ is defined to be zero if $k < 0$
or $k > n$. Using this convention,
we can often avoid explicitly
specifying upper and lower limits of sums involving binomial coefficients.

\pagebreak[3]
\section{A well-known single sum}

Lemma~\ref{lemma:Best} is well-known, as noted
in the Introduction. We give a proof because it illustrates some of the
ideas used in the proof of Theorem~\ref{thm:double_sum}.

\begin{lemma}	\label{lemma:Best}
For all $k \ge 0$,
\[
\sum_p \binom{2k}{k+p}\,|p| = k\binom{2k}{k}\,.
\]
\end{lemma}

\begin{proof}
Let $S_0 := \sum_p \binom{2k}{k+p}\,|p|$. Splitting the sum into sums
over positive and negative $p$,
using $\binom{2k}{k+p} = \binom{2k}{k-p}$,
and observing that the term for $p=0$ vanishes,
we see that
\begin{equation}
S_0 = 2\sum_{p>0}p\,\binom{2k}{k+p}\,.	\label{eq:Sigma_1}
\end{equation}
Writing $p = (k+p) - k$ gives
\begin{eqnarray*}
p\binom{2k}{k+p} &=& (k+p)\binom{2k}{k+p} - k\binom{2k}{k+p}\cr
	&=& 2k\binom{2k-1}{k+p-1} - k\binom{2k}{k+p}\,.
\end{eqnarray*}
Substituting this into~\eqref{eq:Sigma_1} and using
\[2\sum_{p>0}\binom{2k-1}{k+p-1}
 = \sum_p \binom{2k-1}{p} = 2^{2k-1}\]
and
\[2\sum_{p>0}\binom{2k}{k+p}
 = \sum_{p \ne 0} \binom{2k}{k+p}
 = 2^{2k} - \binom{2k}{k}
\]
gives
\[S_0 = k2^{2k} - k2^{2k} + k\binom{2k}{k}
 = k\binom{2k}{k}\,.\]
This completes the proof of Lemma~\ref{lemma:Best}.
\end{proof}

\section{The main result~-- a double sum}

\begin{theorem}		\label{thm:double_sum}
For all $k \ge 0$,
\[
\sum_p \sum_q \binom{2k}{k+p} \binom{2k}{k+q}\, |p^2-q^2| =
 2k^2{\binom{2k}{k}}^2\,.
\]
\end{theorem}
\begin{proof}
Write
\[S_1 :=
\sum_p \sum_q \binom{2k}{k+p} \binom{2k}{k+q}\, |p^2-q^2|\,.\]
The terms in $S_1$ for which $p=0$ or $q=0$ are
\begin{eqnarray*}
S_2 &:=& \sum_p \binom{2k}{k+p} \binom{2k}{k}\,p^2 +
	\sum_q \binom{2k}{k} \binom{2k}{k+q}\,q^2\\
    &=& 2\,\binom{2k}{k}\sum_{p}\binom{2k}{k+p}\,p^2\,,
\end{eqnarray*}
and the other terms are
\[S_3 := \sum_{p\ne 0} \sum_{q\ne 0}
	\binom{2k}{k+p} \binom{2k}{k+q}\, |p^2-q^2|\,.\]
Considering the generating function
\[
  f(x) := \sum_p \binom{2k}{k+p}x^p
	= x^{-k}(1+x)^{2k} = (x^{1/2} + x^{-1/2})^{2k}\,,
\]
applying the operator $x{\rm d}/{\rm d}x$ twice, and evaluating
the resulting expression at $x=1$, we see that
\[
\sum_{p}\binom{2k}{k+p}\,p^2 = k2^{2k-1}\,,
\]
so
\begin{equation}						\label{eq:S2}
S_2 = k2^{2k}\binom{2k}{k}\,.
\end{equation}
Also, using symmetry, we have
\[
S_3 = 8 \sum_{p>q>0} \binom{2k}{k+p}\binom{2k}{k+q}\,(p^2-q^2)\,.
\]
Now write
$p^2-q^2 = (p-k)(p+k) - (q-k)(q+k)$,
so
\[
\binom{2k}{k+p}\binom{2k}{k+q}\,(p^2-q^2) =
\phantom{\binom{2k-2}{k+p-1}\binom{2k}{k+q}
	 \binom{2k-2}{k+p-1}\binom{2k}{k+q}}
\]
\[
2k(2k-1)\left[-\binom{2k-2}{k+p-1}\binom{2k}{k+q}
	      +\binom{2k}{k+p}\binom{2k-2}{k+q-1}\right]\,.
\]
On the right-hand side we use
\[\binom{2k}{k+p} = \binom{2k-2}{k+p}
	+ 2\binom{2k-2}{k+p-1} + \binom{2k-2}{k+p-2}\]
and the corresponding identity for $\binom{2k}{k+q}$.
After cancelling the terms involving
$\binom{2k-2}{k+p-1}\binom{2k-2}{k+q-1}$ and regrouping, this gives
\begin{eqnarray*}
\frac{S_3}{8} &=& 2k(2k-1) \times\\
&& \left\{
\left[
\sum_{p>q>0}\binom{2k-2}{k+p}\binom{2k-2}{k+q-1}
-\sum_{p>q>0}\binom{2k-2}{k+p-1}\binom{2k-2}{k+q-2}
\right]\right. \\
&+& \left. \left[
\sum_{p>q>0}\binom{2k-2}{k+p-2}\binom{2k-2}{k+q-1}
-\sum_{p>q>0}\binom{2k-2}{k+p-1}\binom{2k-2}{k+q}
\right]
\right\}\,.\\
\end{eqnarray*}
Changing variables in the second and third summations, we obtain
\begin{eqnarray*}
\frac{S_3}{8} &=& 2k(2k-1) \times\\
&& \left\{
\left[
\sum_{p>q>0}\binom{2k-2}{k+p}\binom{2k-2}{k+q-1}
-\sum_{p>q\ge 0}\binom{2k-2}{k+p}\binom{2k-2}{k+q-1}
\right]\right. \\
&+& \left. \left[
\sum_{p>q \ge 0}\binom{2k-2}{k+p-1}\binom{2k-2}{k+q}
-\sum_{p>q>0}\binom{2k-2}{k+p-1}\binom{2k-2}{k+q}
\right]
\right\}\,.\\
\end{eqnarray*}
The expressions inside each pair of square brackets
both involve a kind of two-variable
telescoping sum~-- the only terms that do not cancel are those
for $q=0$.  Thus, we obtain
\begin{eqnarray*}
\frac{S_3}{8} &=& 2k(2k-1) \times\\
&& \left\{
\sum_{p>0}\binom{2k-2}{k+p-1}\binom{2k-2}{k}
-\sum_{p>0}\binom{2k-2}{k+p}\binom{2k-2}{k-1}
\right\}\,.\\
\end{eqnarray*}
Taking out the factors that are independent of $p$, we are left
with two easily-evaluated sums, giving
\begin{eqnarray}
S_3 = 8k(2k-1) \!\!\!&\times&\!\!\!
\left\{
\binom{2k-2}{k}\left[2^{2k-2} - \binom{2k-2}{k-1}\right]
- \right.  \nonumber \\
&& \left.  \,\binom{2k-2}{k-1}\left[2^{2k-2}
-2\,\binom{2k-2}{k} - \binom{2k-2}{k-1}\right]
\right\}. \label{eq:S3}
\end{eqnarray}
Recall that $S_1 = S_2 + S_3$. Using the expressions~\eqref{eq:S2} for
$S_2$ and~\eqref{eq:S3} for $S_3$, and simplifying,
we obtain the desired result for $S_1$.
\end{proof}

\subsection*{Acknowledgement}

We thank Warren D.\ Smith for his comments on earlier drafts of this note.

redpajama_set_name: RedPajamaArXiv


text:
European Parliament Reports on Property Rights for Couples
September 10, 2013 /2 Comments/in /by Gilles Cuniberti
On 21 August 2013, the Committee on Legal Affairs of the European Parliament issued its Report on the proposal for a Council regulation on jurisdiction, applicable law and the recognition and enforcement of decisions in matters of matrimonial property regimes (COM(2011)0126 – C7-0093/2011 – 2011/0059(CNS)).
The procedure file of the proposal is available here. The rapporteur was Alexandra Thein.
On the same day, the same Committee also released another report: Report on the proposal for a Council regulation on jurisdiction, applicable law and the recognition and enforcement of decisions regarding the property consequences of registered partnerships (COM(2011)0127 – C7-0094/2011 – 2011/0060(CNS)).
The procedure file of the proposal is available here. The rapporteur was again Alexandra Thein.
According to the final draft agenda of the Parliament, a joint debate took place yesterday on the property rights for couples in the EU, namely on the two above-mentioned reports. The final draft agenda is available here.
H/T: Edina Márton
https://conflictoflaws.net/News/2020/08/CoL_Banner-1.png 0 0 Gilles Cuniberti https://conflictoflaws.net/News/2020/08/CoL_Banner-1.png Gilles Cuniberti2013-09-10 02:01:272013-09-09 16:05:34European Parliament Reports on Property Rights for Couples
Jan von Hein says:
With due respect for the considerable efforts made by the rapporteur and the other EP members, there are two points in the revised draft referring to general principles of PIL which do not appear fully convincing. First of all, the reformulation of the Commission's proposal for overriding mandatory provisions is not made clearer by the proposed amendment 69. Whereas modern conflicts doctrine and the existing EU conflicts regulations clearly distinguish between a special connection devised for internationally mandatory rules ("Eingriffsnormen") on the one hand (see Articles 9 Rome , 16 Rome II), and a primarily "negative" function of public policy on the other (cf. Articles 21 Rome I, 26 Rome II), Amendment 69 mixes the two concepts by describing overriding mandatory provisions as "provisions the disregard for which would be manifestly incompatible with the public policy (ordre public) of the Member State concerned". This brings us back to the notion of a "positive" public policy clause that has a venerable tradition in the romanic legal family, but which is not supported by the more differentiated EU legislation so far. Moreover, it begs the question why such a provision should be necessary if there is already a general public policy clause in Art. 23.
Apart from that, it is quite surprising that, in spite of the ambition to ensure coherence with the Regulation on successions, renvoi (Article 24) remains — contrary to Article 34 of the Successions Regulation — totally excluded, even in relations with third states, which is merely justified by a reference to the Rome I Regulation (Amendment 71). Why this should be so (coherence with Rome III, perhaps?) remains a mystery.
Is it really necessary to reinvent the wheel every time that another EU Regulation on the conflict of laws is prepared? Or do we need a Rome-0-Regulation, after all? See https://conflictoflaws.de/2013/do-we-need-a-rome-0-regulation/
Laura | Dutch Law Firm AMS says:
Thanks for sharing this information, I agree with Jan von Hein, is it necessary to reinvent the wheel every time? In my opinion it is not!
US Court Enforces Award Nullified in Country of Origin Yearbook of Private International Law, Vol. XIV (2012-2013)

redpajama_set_name: RedPajamaCommonCrawl


Connaught Place, or CP as referred to by the locals, is Delhi's commercial center. It also happens to be the location of the AIG's pop-up office for the month. Located conveniently near the Rajiv Chowak metro stop at the intersection of the 2 & 3, it's a short ride up in the tube from the Defence Colony. CP's streets radiate outward from the central hub dividing the area into blocks dense with shops, offices, upmarket hotels, and at the moment, plenty of construction.
This entry was posted in People, Travel and tagged India, Street.


Using ES6/7, create-react-app, and Electron!
Mikeal Rogers, Rachel White, and Alex Sexton discuss how they're using ES6/7 with and without a compiler, updates to create-react-app, and the beloved Electron.
Toptal – Hire the top freelance software developers, designers, and finance experts with Toptal. Email adam@changelog.com for a personal introduction.
Linode – Our cloud server of choice. Get one of the fastest, most efficient SSD cloud servers for only $5/mo. Use the code changelog2017 to get 4 months free!
Fastly – Our bandwidth partner! Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform.
[laughs] Rachel and I are back from a nice little vacation in Europe. If you didn't check out the episode where yayQuery took over, definitely go back and listen to that one. That one was so good that Rachel and I were actually fired… I got a text from Adam Stacoviak while I wasn't here; he just said "You're fired!" and then it turned out that they can't do it, they can't schedule it for another nine months, so we're filling in now for them until they can come back around.
Alright, let's jump into it. We're gonna talk about actually using ES6 and ES7, new language features, with and without compilers, some of the tradeoffs and stuff like that.
I think that we should just talk about specific features rather than what bucket they land in, because they actually get implemented out of order anyway, so… Rachel what features are you using that you've been enjoying from the new language stuff?
You don't write any ES6?
No, I mean… The only thing that I've used really – because since I don't write production code, nobody tells me what to do, so I kind of just do what I've always done… I've worked with some things that have the new variable naming and stuff like that, but that's really all that I've dipped my toes in. And what is the other thing…? "let" is in there? I don't know… Enlighten me.
"let" has been there forever. The big ones for me have been arrow functions and template literals.
Yeah, the arrow functions are super cool and I totally get that it helps with readability so much, but I'm still stuck in that mindset of like forgetting to use it, and I feel like if I'm going to incorporate all of the new type of things, I'm gonna have to enforce it to strict in my code linting… But other than that, I'm not actively going out of my way to use it, because nobody tells me what to do when I write code.
Yeah, it certainly encourages unnamed functions, for one thing.
Yeah, that's true. I don't line anonymous functions. I like to try and name everything if I can.
I don't know… They've gotten so small and so easy to use that I'm able to use them in ways that you wouldn't use functions before, because it would just be too verbose.
[00:04:09.24] There's a couple libraries that I've written for templatized HTML, and using functions inside of a template literal and stuff like that. That would have just been too verbose beforehand, right?
Sorry to interrupt… The semantics are maybe easier, because it's just like – we talked about this a little bit while you guys were gone… It is kind of just the literal scope of the variables; there's no bound… It's just the lexical scope of variables, so you can reason about what a variable or what this is much more simply, because it's impossible for it to be anything but lexically bound. So to some degree, you can forget about some things that functions add, and then to another degree it's hard to scan maybe, especially implicit returns.
Yeah, I was just gonna say… Whatever complexity they take out of the pool by not having this, they probably add it with the implicit return stuff.
Is this just for like personal projects, or is this in practice in his job? Or do you not know?
I think both. I mean, he is certainly advocating it to other people, which I assume would also be for production use. But I think that the argument that this actually can reduce complexity if you stop using older syntax is one that comes up a lot. People talk about – eventually, the language does get simpler if we can stop using some of these older forms, and this is certainly somebody advocating for that.
[00:07:53.22] The problem is that… I forget who he said does this, but the class functions, if you just use the syntax inside classes, or you do a class and then you just tab inside the blocks and you do a function name - that is not an arrow function, it's not lexically bound. You have to do "function name = (arrowFunction) function" in order to get a lexically bound function in there. So it's actually like you kind of have to modify some of that syntax.
Then if you decide "Okay, I'm always gonna use that syntax", the constructor inside of there can't be listed like that. You have to do the constructor the old way, so it could be bound, but you can't bind constructors; then a whole bunch of things like that start getting weird.
Well, in the case of classes though, you often do wanna reference this though… You have a use for that. I think what he was saying was that we can take the function keyword out of it at least, and then we can not have this ambiguity.
No, what I'm saying is that if you use arrow functions, the functions can't be rebound. It's guaranteed to be lexically bound, whereas if you use just the class syntax, it more mimics using the function keyword, and then using this will default to the right thing probably, to what you want. But pulling out, like if you just use an instance, kind of like a static function, this can change very quickly to a window. All those types of problems start to show up again. It's just sugar for prototypal properties on an object.
So there are still gotchas if you use the class syntax. You could still go further and say "I still want to use arrow syntax inside of my classes", if that makes sense.
And I think if you are going to say "We require arrow functions everywhere they can be used", you should also require them in classes, too. So rather than saying "function name(arguments)" and then brackets with the function, you should say "function name=(fatArrow)" brackets, if that makes sense.
Yeah. I don't think that the point that any of these people are trying to make though is to be zealots about arrow functions. I think the point that they're making is that we can deprecate the use of the "function" keyword and just rely on these numerals, and then we get out of a lot of ambiguity if we're just using the new rules around classes and arrows.
I think I disagree on what those people – at least the people I've talked to who are doing this aren't necessarily… They're not doing it just because they think it looks better or it's smaller or it's more streamlined or anything like that; they're explicitly doing it because the lexically bound ambiguity problems go away. So you end up with a program that only has lexically bindable functions, so it's important to do it everywhere, even if the syntax is old. If there's some way to use the old function syntax and then just say "Oh, this is a lexically bound function" - they would still be cool with that. It's not about the fat arrow, it's about the semantics of how the function exists and how it can change and what contexts it can run in. It's taking away the footgun of this changing out from under you I think is the goal.
Okay. Transitioning a little bit… We're talking about all these features, and my assumption is that we're talking about using them without a compiler, and I think that that may not be your assumption. I'm wondering, where do you have to have a compiler done to ES5 to use this stuff right now? Are there IoT devices that have older dates that we have to worry about? Which browsers still don't support this kind of garbage? I mean, we're not supporting IE6 anymore, right? We're done with that.
[00:11:59.23] Yeah… IE9 doesn't – IE10 and IE11 get into some of the territory, but still are missing quite a bit. I think the problem is that – and Babel is perfectly capable of doing this, it's just somewhat uninteresting to try to solve unless there's a performance problem… But if you think about your application, let's say you're using ten new ES star features, and one of them is object spreads, which is totally gonna get in the language, but isn't in any browsers or Node or anything like that. It's just like an obvious thing that we're gonna do, and it's really useful to be able to – much like an argument spread or an array spread, you can do the same thing into an object. It kind of like finally solves the jQuery.extend thing. So does Object.assign. But the problem is that you're already compiling with Babel at that point, so you're saying "I want all these features in Babel", and you could just say "Well, I just want object spreads and I know the rest will", but at the point where you pull in a compiler, you're like "Well, I might as well just go down to ES5", and I think that's the common way… It's just "Let me pull in everything that I know I need to compile to, because I want to just work everywhere" and then people don't think about it too much past there because there isn't too much of a hit for many things.
This isn't my thinking at all, though. I don't know if Rachel feels similar to this, but I don't use a compiler, like ever, for down to a different language. I only use browsers that support this, and if it's a feature that isn't widely available, I just don't use that feature.
I think you guys are definitely the minority.
Well, yes… Provided that you have all that tooled properly, and it can be kind of a pain. Look, if you're gonna use Babel, then you're already in this – or sorry, if you're gonna use React, you're already in this, right? So there's enough people using frameworks or other upper-level tools where the compiler is just a part of that toolchain already, but I'm certainly not gonna add Babel to my Node project in order to use object spread. That's not gonna be – I don't understand that thinking, and I don't think that a lot of people do that.
In your pure Node module you're already gonna have a compiler.
I think Node is a little bit less this way, because there are different norms there. But I think even in those cases it's somewhat common to see… Yeah, sure.
So if you're working in Vue or you're working in React or you're working in Ember or you're working in Angular or you're working in any of these things, you have a Babel-like compiler already in your stack, so adding object spreads is just like a decision you can make or not.
I feel like most of the features that I have used and interacted with would have been like things that we touched on already: [unintelligible 00:15:57.04] arrow functions, some of the way they're doing class definitions and stuff like that. I guess this is gonna be the same thing that Mikeal was just about to ask - are there any features that you aren't using…? Which ones do you two think are the ones that people aren't really fully embracing or trying out yet?
[00:16:18.04] I guess there's two buckets there… The ones that people aren't trying out yet because they're bad, and the ones that people aren't trying out yet because they aren't' fully aware of them or they aren't fully powerful, or things like that. I guess there's also things that go in both buckets.
A lot of the stuff we use in Babel and the stuff that we're compiling down to is stuff that isn't even finished getting through ECMA and will change. Modules is something that everyone uses and a lot of the semantics of how modules load haven't been known for a very long time and that's kind of the driving force behind the problem with getting proper modules into Node specifically, because we've been doing it slightly wrong for so long, because we kind of just wanted to compile ahead of time. Now there's a clash in the semantics of how it should really work and we're gonna have to kind of work around that problem for a little while.
Yeah. I mean, without getting into the specifics there, there's actually a particular point where the spec sort of implies but does not define how things are supposed to work, and Babel made a decision about how they work at one point, and we're not gonna be able to support that in Node. In fact, the spec committee said that we should not do that and go that route, because of some of the other tradeoffs that we would have to make.
That one's even out. That one is actually in the spec, we just haven't had enough implementations to know what some of these really nitty-gritty details are.
You're by definition kind of on the bleeding edge if you're using features that aren't even actually in the browser yet.
Modules are now in the browser though.
I think proxies are a terrible idea and I don't know why we should use them; they're just kind of a performance bottleneck.
Proxies were a really good idea for like a hot second. It seemed like a really solid solution to a thing that everyone was trying to solve at the time, and then we found better ways to solve those userland problems and then proxies became this thing that made a lot less sense… Namely like the "get set" type problems… The way that Ember used to work where you had to do .get and .set… There was a world where proxies in the future could do more .get or .set or .type stuff to where you could just say "myObject.foo=5" and then that would be the same as saying "myObject set foo 5" or whatever… It would need to do that because we need to run functions when things change in order to rerender. But now with virtual DOMs and all that kind of stuff,t the community moved on to different techniques for solving that problem that are a little less magic. So I think proxies kind of fell – there are certainly use cases, but I think they're pretty small.
[00:19:53.18] Other things - I'm trying to think… There are definitely proposals that – I think it's less about… I'll use anything that's kind of in the language; they're pretty conservative, I think, about – by the time it gets in the language, everyone's already been using it for so long that it's not even that cool. But there are definitely things that are level two in the spec that I don't think are ever gonna make it. Things like you could turn on stuff for immutable types, or even like – one thing I don't use is decorators; I am skeptical that decorators are gonna go the distance, so I've been avoiding decorators. I don't have any data, I'm just waiting till they're more of a sure thing, I guess, if that makes sense.
I used them when I was a Python programmer, and my general feeling is that they complicate more than they simplify.
Yeah. There are some cases where they're really – I think the authentication case for decorators is so pretty all the time; it's just like "This is an authenticated function" and it just magically makes off something that makes sense on a per-function basis. That's such a cool use case for decorators that it makes you wanna use them a little bit more.
Ember concurrent uses decorators to do some of their stuff and I think it's a decent use case for it. But in general, I haven't seen a huge need for them, even though I'd probably use them once they made it into the language… Once they became more of a first-class supported thing by the libraries I was using.
I don't know, I'm more on the functional programming side of things, so I just don't – I don't like encouraging people to write more classes.
Sure. That's a different conversation, but there are kind of two properties – I'm pretty happy with the React world's… There are function components and some people are very big into that, but if you don't mind the class components. But then all functions that are a part of it are pure functions, and that kind of stuff… Kind of a mix of some of the better parts of each of the patterns to where you don't have crazy side effects and you don't have these different things, but then your Vue layer is a little more readable than just a function that calls a function that sends half of its arguments to another function. I don't know… I think there's a middle ground there that's nice.
Yeah. I think that we've hit a nice little spot here… I think we can take a short break, and when we come back we're gonna get into create-react-app.
We're gonna get into some new features that just landed in create-react-app. It actually seems like a pretty substantial change.
That's tough… That's an Alex problem. Alright, create-react-app is very similar to Ember CLI, if you've ever used Ember. I think Angular has its own CLI tool as well that I don't know the name of, but pretty much the goal of create-react-app is to manage all of the things that Mikeal's always complaining about for you, that way you don't have to care about them.
The history is interesting… It was like a hack weekend project, because React was one of – a lot of the feedback React got was that there's no kind of baseline of guaranteed, supported tools that work together, and this is kind of like an answer to say like "Well, this stuff all works together." So it's kind of like a hackathon one-day thing, and then it's grown up a lot since then. This is the 1.0 release. It's been in use by a lot of people already, but now it's 1.0.
The idea is you have to stay within their – so it even configures your ESLint, it configures your Webpack, it configures your CSS, it configures your Babel… All these different things. And that configuration is even hidden from you, because if you change it, then it's harder for them to make the assumptions that they can make. So you can either choose to use create-react-app as this thing that you can constantly update because you're staying within the coloring lines, or you can use create-react-app to generate a thing, and then you can do what they call ejecting. You can eject from create-react-app as soon as you create your app. It will pull all that configuration into your core directory or where it would go if you wrote it yourself, and then you can just edit it and all that stuff. But you can no longer pull updates from create-react-app in order to get automatic updates, if that makes sense.
Does that make sense as kind of a background?
Cool. In general, I found that with the things at work that are difficult to do, if I wanna do a create-react-app, I have to eject pretty fast, because we need to change one ESLint thing in order to work with our build servers, and it's "Ugh, that kind of stinks." And that's like part of the deal… It's like if you can't do it, then you just don't get the updates. And sometimes that is not a problem.
In general, I haven't paid enough attention to create-react-app to get mad when they have an update and my thing can't update with them, but this release would be maybe a good example of something that's like "Well, if you stayed in the coloring lines, this would be a really nifty change." So we can go through the changes in 1.0 if you all want.
Sure, sure. My first question… So it says something on the order of like "Okay, you can use import/export semantics now without actually compiling down to CommonJS", but it's compiling down to something, just to get into the browser. It's not relying on the browser's support yet.
[00:27:55.09] It could… I think you skipped ahead. Webpack 2 is part of create-react-app now; it used to be based on Webpack 1. Most people were on Webpack 1. Webpack 2 is pretty new and it's a larger departure than a lot of 2.0 would be, so it's gonna take some work to get people moved over. But one of the features of Webpack 2 is that it supports imports and exports natively, like at all, as part of its parser.
Before, if you gave Webpack 2 imports and exports ES6 modules and you weren't using Babel, nothing would happen; it would break because it wouldn't understand that. So what the steps would be would be compile with Babel to require statements, and then pass this to Webpack, and then Webpack could understand the require statements.
But there are some features in ES6 modules like static analysis and stuff like that that are more guaranteed in ES6 modules, so they were able to say "Alright, we no longer care if you pass this require or these things, and so may skip the Babel step in order to pass imports and exports rather than first compiling down to Webpack." And then it can use the proper static analysis that is guaranteed as part of the ES6 modules in order to do better things with regards to bundle size and tree shaking and dynamic loading and all that kind of stuff.
So it's more of a "What does Webpack understand?" rather than… You still more than likely at the end will compile it down to require statements from whatever library in order to bundle it all together - it's part of what Webpack does - but it natively understands imports and exports now. And that is now included automatically in create-react-app, which means that if you were coloring in the lines before, all you have to do is update your create-react-app instance, the version, and you were automatically upgraded from Webpack 1 to Webpack 2, which is kind of the amazing thing. It's like, wow, that was a pretty big upgrade from Webpack 1 to 2. A lot of people are gonna spend a lot of time rewriting their Webpack configurations, and it was free because you stayed within the lines. Someone else worked on the hard parts of that… Which is cool. It's nifty. It's a good idea. Does that make sense, Mikeal?
Yeah, I'm just constantly sort of reframing how to think about Webpack. I think that for the longest time everybody thought of it as this compile tool, but in actuality it's more like a platform onto itself. It has a lot of primitives, like its own module system with more types and things like that than Node does… So yeah, I'm just kind of reframing how to think about that.
I was going through and reading the whole What's New in the create-react-app article, and a bunch of it made sense to me, but there's some things in here that I never heard of and I have no idea what they are… One of those being Jest 20.
[00:31:49.26] So they've just upgraded Jest I guess two versions. It used to be Jest 18, or something like that. Testing - we should do a whole episode on testing some time in the future, but one of the hardest parts about testing in the past, if you guys have done testing at scale for a web app (which may not be the case), functional tests are so sad… Where you need to pop open a browser with Xvfb and then send web driver commands to it in order to try to click around… They're so slow, they have so many false positives and timeouts and problems, and Chrome automatically updates and breaks all tests, and web driver implementations are shady between the different… But there's so many problems with that that there's this new world of writing unit tests where you can kind of mount components directly into memory, and then kind of write functional style tests as something that doesn't need a browser at all.
And it's a little different than running jsdom, which is essentially providing a subset of a browser. And you can do a lot of the tests that you used to do very slowly, very non-deterministically with browsers as a unit test, where you say "If a click is applied here, the DOM should then reflect these different things", and you can test all that stuff, on kind of a per-component basis very quickly, without spinning up a whole browser.
So Jest is good at helping you manage those types of things. In general, if you're writing React code, there's a pretty – Jest would be your default choice, even if it's not. I doubt it has more than 7D% saturation, but that's pretty good. There's still quite a few other options that people use… Ava, and a few different things. Jest I think is coming around and winning the default choice for testing, because Facebook wrote it and supports it and stuff.
Yeah. So it this one just bundled with the new release?
Yes. Jest used to be bundled… It's just a new version, so there are new things; the highlights include immersive watch mode, better snapshot format… Snapshots are where you can say like "Once this is rendered with this data, the HTML should look exactly like X." It's kind of like whenever people do screenshots with CSS frameworks and stuff like that, it needs to be pixel perfect - you can do the same thing with the HTML output of your components. You can just Snapshot like "I don't need to write down what it should look like, but I know this is good. Snapshot shouldn't change unless I change that module." So if some dependency accidentally starts changing your HTML, you'll get a test failure. And then just like the output and stuff, the APIs for new stuff in React… You also get automatic coverage reporting, which is good.
Yeah, and whenever you do a create-react-app it'll start you up with the test directory, with the test already written and imported and building and all that kind of stuff to where it's like really as soon as you write your thing it's a very fast and easy example on how to start writing tests for your thing without needing to learn about how to configure Jest.
So there's definitely some danger to where you can get yourself in a place where you accidentally cache everything and there's no way to break out, and that can be unfortunate.
I haven't dug deep into their service worker implementation, but my gut is if you don't do anything weird it should be fine, and if you do something weird - sorry. My gut is that it's fine for normal stuff, and you'll probably need to turn it off for crazier stuff.
It's probably very baseline, very lazy in the sense that it isn't gonna do too much because it can't assume as much. But if you think about just like a caching strategy of "Have we seen this before?" [unintelligible 00:38:10.23] if we've seen it before, return the old one, and always go grab the new one. And if there is a new one that's different from the old one, go ahead and also send up another event for new data." If that's kind of built into the idea of how you render things, which a lot of the React stuff is, as things change, it automatically updates, and it can kind of be a good default strategy.
Oh yeah, I hadn't really thought about that. React has a lot of understanding about the individual components, so it knows its rerenders need to happen when the backend updates. That's interesting.
Yeah, there's some nice synchronicity in some of that stuff, I think. It's not gonna be a silver bullet, but I think it's pretty good. Ember CLI doesn't have service worker, but by default whenever you do Ember serve a CSP (content security policy), which I think is a really cool default to have, just to make that a more widely used thing… Just like by default XSS is harder in Ember apps than it is in other apps because they do CSP.
So I really like these toolkit style CLI helper things doing things like solid generic defaults, that maybe aren't the best version of them, but maybe get people thinking about service workers or get people thinking about CSP. And it'll work in all the simple cases, as well.
[00:39:52.20] No, I think just in general – on the surface this looks like a boilerplate generator, and it's actually very much not just a boilerplate generator.
Well, it's a boilerplate generator but it keeps on helping. It just helps you continue on developing the app; it doesn't just run once and then you don't use it, right? Because it helps you put together all of the tools that you need for it.
Scaffolding… It was called scaffolding.
Yeah, that's the word. And it definitely feels kind of like scaffolding, and there's a bit of scaffolding in the initial create-react-app, but I think it focuses less on generating code for you and more about providing tools and examples and kind of a baseline for you to build on, and then allowing – one of the things that scaffolding is it's like once it generates that code, that code is stuck there forever in that format… Whereas more of the strategy with create-react-app is that hopefully it scaffolds little enough to where it can update those things that it has generated on the fly.
I think the last thing that's interesting in the create-react-app 1.0 release is the code-splitting stuff, and that's part of Webpack, as well. But there's a standard that no one uses for dynamic imports… It mixes async/await with import.
I hadn't looked into it much, because it wasn't really a great place to use it, but it's part of the standards track. I don't know where it is in that, but… You're gonna have an async function and then you can import something… You can do "await import" and then that will automatically build into a separate – all the dependencies of the thing that you're asynchronously importing can be built into a separate bundle.
I guess I was complicating it because it would be invalid syntax to just throw an import there. It needs to be supported syntax; it's not just like something you could do before but people didn't know about it. I think awaiting in import is not – like, it needs to be statically analyzable or at least known to be a part of it that isn't statically analyzable, because it doesn't need to be… Something like that. And that's why I think it's part of the standards track to do asynchronous imports like this.
[00:44:08.01] Following on with your talk about scaffolding, it seems like the big difference between this and what Rails does is, like you said, Rails will generate a lot of boilerplate code. This seems to generate a lot of configuration, right? The joke about Webpack is you only write one Webpack configuration and then you copy/paste it into every project.
Yeah, exactly. [laughs] But I think also, like you were saying, one of the things that this does is really standardize what is the proper path for writing a React app with all these different configurations. So this allows you to sort of add features over time to that configuration without trying to get thousands and thousands of developers to update this particular line in their Webpack config.
Right. It's a noble cause. And other people are doing it. Ember CLI - they're doing this as well. When you upgrade these new-world configuration CLI tools, you get instant improvements in your applications, which is cool. Everything still works, and now it's 20% faster. Whenever Ember did the Glimmer update, all you did was upgrade Ember CLI and suddenly everything was using Glimmer. It was all supported, unless you were doing something weird, and suddenly your website rendered faster. I think that's a cool world – I think that's a good goal for these well-used frameworks to go after.
Definitely. One thing I can't wait to see is not compiling down to ES5 anymore, but compiling down to a set of features that are actually mostly supported, because there's a lot of performance benefits, too. Arrow functions are faster than regular functions in V8, and for the most part, people that are working with compilers aren't getting those performance benefits right now.
Yeah. You can configure that… Not in create-react-app, but in a generic Babel config you can say "This is the target set of features that I want to compile down to." So it's certainly possible, but I don't think many people go that far.
And also there's only one minifier that supports it as well… And it's still under really active development, so that's one of the things that you kind of lose.
Anyway, I think that it's about time for another break. We're gonna take a short little break here and when we come back we're gonna talk about the project of the week.
Just for some quick background, Electron is a way to build desktop applications for Mac, Windows and Linux using Node.js and browser technologies. If you can make a website and use Node.js, you can write an Electron app.
It was originally broken out of the Atom editor that GitHub was doing. it was initially called Atom Shell, and then Jessica Lord and some of the good people at GitHub moved it into its own project and now it's really taken off.
[00:48:09.02] And some of the Electron apps that people might know of is like Hyper and Slack, and something that we talked about recently, which is WebTorrent, and stuff like that.
Visual Studio Code, my current editor of choice, as well. Yeah, one of the interesting things that I've seen about it is that I think a lot of people initially viewed it as "Oh, I can take my website and turn it into a desktop app." That's sort of what the Slack app does. Or "I can write desktop apps, but it's a pain to do it across browsers, so I will write them in this instead." But what I've seen lately are applications that I don't think would even exist if it wasn't for having unrestricted access to Node.js, and then just being able to put a browser frontend on that. Just the size of the ecosystem is so amazing.
MongoDB has like a new DB Admin thing that's like a desktop app with Electron. Voltra is like this new music app that is way prettier and nicer than iTunes, and that is just because they knew Node.js really well, they can really dig into the nitty-gritty there. And a lot of the stuff that they're doing with data storage and sync-ing and stuff - they need that performance, that layer; they couldn't just do it as a pure web app. So it's awesome.
Have you built anything with Electron?
Yes. I wrote a little kind of a browser viewer on top of IPFS… Because I wanted to play around with IPFS, so I made a little drag-and-drop thing. I'm about halfway done with a desktop version of Roll Call, that uses Electron as well. And then I pulled down and just worked with a couple projects. I dug into the Brave code at one time, which is also an Electron app – or was back then; I think now they're on their fork of Electron. And there was another app that I can't remember that I sent a pull request to, so I had to pull it down that way. And all of them have been great. I'm comfortable with Node, so it's a really comfortable place to be to develop in it.
Yeah. I mean, I'm super comfortable with Node too, and Electron has always been something that I have known existed as a thing, but is there anything extra that people that already know how to build web applications with Node would need to know in order to get up and running with Electron? Or does Electron kind of just wrap around all that stuff?
It wraps around all of it, but also… I don't think that we can underestimate how much stuff there is in NPM right now, like how many modules. And to make a lot of web apps work, a ton of what you do is that you build these backend services that just talk to something that has less security around it and more of the Node ecosystem, and then you push that to the browser in some way.
I've seen a lot of people just get up and running so quickly on their ideas because they can just store directly on the file system and access every module in NPM and then put a web front-end on it and not have to spin up a back-end service, not have to deal with a front-end and a back-end, where they just kind of have it all mashed together in this environment in Electron.
[00:51:43.23] In Electron, no? My experience in Electron has been installing the Electron bin for – actually, we used Electron in order to do screenshots for our CSS library visual diffs, because it was easier to just run Electron cross-browser, render something and then use the stuff to take a screenshot… And then not even reload pages, just inject the new components into the same page, and then you could take a ton of screenshots all in a row, and it ended up being really fast. I think it was an open source library that we have; I can find a link.
So yeah, I used it for a pretty different thing. That may be an interesting use case of it… It's just a cross-browser environment to run HTML in headlessly, which is kind of cool.
Yeah. What was the thing that…? Oh, this is gonna be horrible – it's gonna showcase my horrible memory. What was the thing that Adobe had that was allowing you to make apps easier? It might have just been like in Max, or something? Does anyone know what I'm talking about?
Thank you, Corvin U. in the channel.
And Flex I think is what it eventually became, right?
Flex was the framework that you wrote in. AIR was the container that it would run in.
Okay, cool… So I remember when that came out and I was like, "Oh, this is rad!" I mean, Electron seems like – I know that people are talking about it a lot, but I feel like people should be talking about it more… I know that's just like a handwavy thing to say, but why aren't people that are making pretty rad apps just not also by default making them in Electron as well? Does anybody know?
Because the web is an important distribution platform, and defaulting to native applications is maybe not the best strategy to reach the most people.
If you talk to people that have apps that people use daily - any app that you use for business or anything that you open up daily, people prefer desktop applications.
They don't have to, but if you talk to Slack, for instance… They have ostensibly the exact same thing on the website as they do on the desktop, and the desktop has a lot more engagement. Getting to people initially, asking them to (before they've seen any value) download this thing is a bit of a stretch for a lot of use cases. But I think that once you have people's attention and you really wanna up their engagement, that's where desktop applications are really useful.
We still value the desktop, it looks like. There's been some great articles lately… GitHub actually – they have these GitHub desktop apps that they've built a while back, and they have not actually moved them to Electron yet, so they wrote up their experiences - some C# and Objective-C developers that are used to writing native applications for Windows and Mac - what they experience was like moving to Electron and doing Electron stuff. It's pretty interesting, I recommend it.
Alright, moving on to our picks… Everybody got their picks locked and loaded?
[00:56:12.23] Yeah, but mine's a copout.
Okay… Well, we'll start with your cop-out then, and then we'll go up from there.
Oh, shut up… [laughs] You can't pick the project of the week. That's like cheating.
[laughs] Tell us about Webpack 2. What's in it?
I was gonna say that I agree to an extent that if you write something that has a few too many things, then tree shaking becomes a crutch, but I also think that take a substack or take a set of tools that are only substack and you'll still get some benefit from tree shaking in the end. It won't be massive, but you might as well do it.
I think tree shaking becomes even more cool when it can – I guess you guys were gone when we made this the project of the week… What was that thing? Code-something came our recently… Facebook – it was the project of… Anyways, it tries to code unroll and precompute things that are already available to compute at runtime or at compiler time… Things like that are also going to be massive, to where like there's an if statement inside of a substack module and there's no way that's gonna run based on the configuration, and therefore it can be compiled out. That's tree shaking-like, and it should be fine. Use it all. Use everything. Use every minifier at the same time.
[laughs] Alright. Rachel, what's your pick?
My pick of the week is a talk from JSConf EU that just happened that I unfortunately did not get to see in person… It's from Anjana Vakil and it's about immutable data structures for functional JS. She explains it in such a really simplified, easy to understand way for people that don't really understand what immutability or mutability or functional programming looks like, a.k.a. me… She just gives visuals that explains how nodes work and how you can do different things with it, and how you can have the arrays structured in – well, I guess that's what mutability and immutability is, but she explains it in a way that makes sense and she talks about it in context of David Nolen's mori library, and Facebook's Immutable.js library and shows examples from both, so that you're able to understand the concept and see how different libraries are handling that kind of thing.
So yeah, if anybody else was wondering about that kind of thing, there's a link to it and it's pretty great.
[01:00:10.11] Earlier in the episode we talked about features that we don't use… My wish is that there was a way to use Immutable.js as the default in the syntax… Like there could be a Babel plugin for immutable versions of things. And there actually is a spec - I think Sebastian Markbåge proposed immutable data structures to ECMA, but I think it's dead and it's not gonna go, and it makes me sad… I really want to use Immutable.js but I really hate changing the syntax for everything. I want native immutable data structures… So that's a good example of something that I don't use that I wish I could.
It's not – there's no rollerblading… [laughs] Hackers is about the origins of hacker culture, which eventually kind of became early technology and open source culture. You can skip the third part – the book is in three parts, and the third one does not hold up. The first one is basically from the Tech Model Railroad Club at MIT in the late '50s and early '60s… They started using computers in a very different way, and how their kind of culture evolved and became the AI lab at MIT, which spawned a bunch of other AI labs and all of the early programming culture came out of what was going on there.
So hold on… The second chapter is about the Homebrew Computer Club and early Apple and early computing in the Bay Area, and also how a bunch of really crazy counter-culture political figures also informed that culture and what they were doing, and that's super interesting.
The third section is about the gaming industry, about Sierra and all those companies that were in the early '80s. At the time it was like, "Oh, and then this is what people are doing right now", but it really doesn't connect very well to the other parts and it really doesn't hold up as like "this particular section of computing is not nearly as influential as these other ones in hindsight." But also, there's some appendices.
One of the appendices is called "The last hacker", and it's about the last person in the MIT AI lab that is kind of the keeper of the flame for hacker culture. It's about Richard Stallman before he started the GNU project and before there was even such a thing as copyleft licenses or a GPL to argue about. It is fascinating! It explains so much!
I've been trying to read a lot about early hacker culture and how the counter-culture movement played into all this stuff, and this one of the best books to really dig into it. It's by Steven Levy and it's called Hackers. There you go.
My pick is the movie Sneakers.
Oh, that's a good movie!
Yeah, yeah… Oh man, that's a good one… That's a really good one. Some Robert Redford… Okay, anyway… Great talking with you all. I think that we're just about done now. Rate us on iTunes, check us out at Changelog.com/JSParty, you can get into our Slack, you can catch us live every Friday at noon Pacific time and something in other timezones, and thank you very much. Bye-bye!