All JavaScript podcasts produced by Devchat.tv:
- JavaScript Jabber
- My JS Story
- JS Rants
JSJ 269 Reusable React and JavaScript Components with Cory House
On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!
[00:01:35] – Overview
We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.
Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.
[00:04:50] – Browser support issue
The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.
Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.
[00:07:50] – Polymer
The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.
[00:14:20] – Standards are dead
No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.
Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.
[00:17:05] – Libraries making reusable components
There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.
As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there
[00:21:20] – Why opt for reusable components
Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.
As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.
[00:31:20] – Rigid component vs. flexible component
As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.
We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.
Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.
[00:36:00] – Reusable components
The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.
We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.
[00:42:45] – Component development on teams
Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.
[00:47:45] – Mobile to web crossover
Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.
[00:50:00] – Challenge
Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"
Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.
Picks
Cory House
Joe Eames
Aimee Knight
Charles Max Wood
JSJ 269 Reusable React and JavaScript Components with Cory House
On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!
[00:01:35] – Overview
We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.
Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.
[00:04:50] – Browser support issue
The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.
Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.
[00:07:50] – Polymer
The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.
[00:14:20] – Standards are dead
No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.
Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.
[00:17:05] – Libraries making reusable components
There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.
As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there
[00:21:20] – Why opt for reusable components
Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.
As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.
[00:31:20] – Rigid component vs. flexible component
As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.
We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.
Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.
[00:36:00] – Reusable components
The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.
We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.
[00:42:45] – Component development on teams
Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.
[00:47:45] – Mobile to web crossover
Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.
[00:50:00] – Challenge
Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"
Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.
Picks
Cory House
Joe Eames
Aimee Knight
Charles Max Wood
JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee
This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions!
[00:01:25] – Introduction to Tristan Davis and Sean Laberee
Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility.
Questions for Tristan and Sean
[00:01:45] – Extending Office functionality with Javascript
Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS.
[00:03:20] – This works on any version of Office?
It works on Office on Windows, Mac, Online and iPad.
[00:03:55] – HTML and CSS suck on mobile?
There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript.
[00:05:20] – Are these apps written with JavaScript or you have a Native with WebView?
Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript.
[00:06:35] – Why would you do this? How does it work?
The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts.
And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel.
[00:10:00] – How did this get delivered to them?
There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners.
For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away.
[00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office?
That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group.
For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model.
[00:14:20] – What about conversations or bot integrations?
There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook.
It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things.
And in the connector case, it’s a push model. The user could choose what notifications they want.
You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language.
[00:18:40] – How about authentication?
As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard.
If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end.
[00:20:00] – Where does it store the token?
That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario.
[00:20:55] – What does the API actually look like from JavaScript?
If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet.
[00:22:30] – What’s the process of getting setup?
There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up.
So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools.
[00:24:15] – How do you protect me as a plug-in developer?
There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff.
[00:27:20] – How do you support backward compatibility?
There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever.
But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need.
[00:30:00] – How does that work on mobile? Do they have to approve download for all components?
You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written.
[00:33:15] – How about testing?
It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this.
[00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript?
A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence.
Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background.
There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching.
[00:39:25] – Are there any limitations on which JavaScript libraries you can pull in?
There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript.
[00:45:20] – What’s the craziest thing you’ve seen done with this API?
Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint.
[00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that?
There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software.
But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can.
When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store.
[00:52:00] – The App Model
If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there.
PicksAJ O'Neal
Charles Max Wood
Tristan Davis
Sean Laberee
My JS Story 023 Laurie Voss
This week we have another My JavaScript story. This week’s guest is Laurie Voss. Laurie has worked with NPM from the start and has been a vital piece to getting it off the ground. Hear how Laurie got interested in computers, how Laurie got started with NPM, as well as a few things about the newly released NPM 5.
How did you get into programming?Laurie started by going into a computer camp, at the time Laurie hadn’t spent time around computers, and it wouldn’t be until the second time that he went to the computer camp that he would see a computer again. Laurie grew up in Trinidad where not many people could afford computers. He started making his first website in Angelfire using HTML before CSS became a thing.
How did you go from web development to hardcore Javascript?Laurie had been writing JavaScript since it was invented. Laurie started a web development company in high school using JavaScript. Laurie met Issac while working at Yahoo and he introduced Laurie to Node which was a starting point to taking JavaScript more seriously for Laurie. When Node was ready in 2013, NPM Inc was on it’s way.
What do you do at NPM Inc?IN the beginning of 2014, Laurie was doing a lot of the JavaScript and was the CTO. Laurie says that part of his strategy has always been to hire JavaScript developers that are better at writing JavaScript that he is. Making him the worst JavaScript programmer at NPM. Laurie’s main job was doing what was needed to get NPM happen, including talking to layers and the business side of things. There are many companies that don’t understand how open source works, and in many cases it leads to run ins with lawyers. Many times NPM acts as an umbrella for open source tools that aren’t able to fight overzealous corporations.
What do you think is your biggest contributions to NPM?Laurie expresses that it has changed over the years. A year ago he would say that he would have to say it leans towards the piece of software that is the registry. It’s very scalable and has worked great for small scale up to very large scale. Laurie works hard to gather funds and help make NPM grow as well as be scalable. He says that he is very proud that he build something that let’s others build things.
How did you get involved?Laurie has been with NPM since the beginning. He tells us how Issac had been running NPM on donated hardware in spare time while working with Node. NPM would break a lot and be down due to the borrowed equipment. They decided that they needed to create a business model around NPM to help it grow. Laurie had just finished working on a startup and knew how to get funding and got their first round in 2014.
How did you get to being profitable?Laurie talks about making sure that their plan is in line with their customers. NPM could easily charge for many parts of NPM but they would rather charge for things that make sense to charge, so in this case the private packages. Enough people are using the private package to getting NPM to profitability. Laurie says that even if money stopped coming in they would have to git rid of a few employees but would be able to keep a small team and sustain the NPM registry, but would never build anything new. It’s always between being profitable or using money to build new things.
What are you working on now?NPM 5 was just released and it’s much faster, five times faster. Laurie talks about being excited about the team and what they are putting into it. Things like making deployments easier. Many developers use NPM to put code together as well as to deploy it. If you didn’t have a lock file, it’s possible that it would change. But the lock file can take a long time, and you already know what needs to go there so they are adding npm store and npm fetch making deploys much faster. Additionally they will be adding a feature called insights. They are able to see information about different users packages, security information, performance information, etc. They can use that information to help developers with suggestions based off of data gathered by what other people are doing. Charles adds that it would be great for coming up with topics for the podcast.
Anything else?Laurie reminds everyone about NPM Organizations as well as NPM Enterprise. NPM Organizations is a way to organize packaging as well as teams of developers and helps you to collaborate. NPM Enterprise allows for single sign on support, license auditing, and features that corporations care about.
Picks LaurieZite and NextJS
Slides.com
VMWorld
Tweet or email if you’re looking at resources for learning VR AI or Iot
Twitter
NPM Organizations
NPM Enterprise
JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen
On today’s episode of JavaScript Jabber we have panelists Joe Eames, AJ O’Neil, Amiee Knight and Charles Max Wood and we are talking about Node 8. To help us we have special guests Mikeal Rodgers, Arunesh Chandra, and Anna Henningsen. It’s going to be a great show. Tune in.
[1:56] Is Node 8 just an update or is there more?Node8 Node’s Twitter Node’s Medium Node Evangelism Group
Mikael on Twitter and GitHub Arunesh on Twitter Anna on Twitter
Picks AJOverclocked Remix Super Mario RPG Window to The Stars
AmieeBlogpost RisingStack on Node 8
2 Frugal Dudes
Homeland
House of Cards
Shimmer Lake
MikaelBlake2b-wasm
AremeshCurrent Nightly News
My JS Story Cory House
On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned.
How did you get into programming?Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up.
Learning How to LearnOut of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus.
Getting Good With Your CraftCory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding.
How did you get into JavaScript?Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation.
Service Oriented ArchitectureCory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side.
Possible Future for Front-end and Back-end RolesCharles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web.
Reasonable Component StoryCory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years.
What contributions have you made to the JavaScript community?Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests.
What are you working on now?Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc.
Publicly Closed - Internally Open Source ProjectsCory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated.
Pull-request-Template.mdCory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well.
Documentation as Development EnvironmentA useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind.
Why React instead of the other frameworks?Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular.
Picks Cory’sCory’s React Courses on Pluralsight Essentialism the book
Charles’Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter
LinksCory’s Twitter
On today’s episode of JavaScript Jabber, Charles Max Wood and panelist Joe Eames chat with Rebecca Turner, tech lead for NPM, a popular Javascript package manager with the worlds largest software registry. Learn about the newly released NPM 5 including a few of the updated features. Stay tuned!
[1:58] Was the release of node JS 8 tied to NPM5?Rush Limbaugh’s children’s books
Tinker Crate
Kiwi Crate
NPM
Episodes on My JS Story.
Gravity Falls
Board Games
NPX
Funstream
Links to keep up with NPM and RebeccaTwitter @rebeccaorg
NPMjS on Twitter
blog.npmjs.com
My JS Story Justin Meyers
On this week’s episode of My JS Story, Charles Max Wood interviews Justin Meyers Cofounder and CEO of Bitovi, a Javascript consulting firm focused on simplifying Javascript development through the use and creation of open source tools as well general consulting, training, and web applications. He was on Episode 202 and talked about DoneJS and CanJS. Tune in to hear Justin’s full story!
7th Grade and a TI82 [3:02]
Justin’s discovery of conditional statements and methods on a classic TI82 was his first taste of programming. With a little guidance, he soon learned to program games on the TI82 and then later moved onto bigger and better mediums like C and QBasic.
Grunt work is good for you. [4:51]
While studying Computer Science, Justin finds out that professors often have grunt work, and although they may not pay well now, sometimes they can in time lead to loads of experience and maybe even a bigger job. After 4 years of working on websites and writing documentation, he gets his first real job at Accenture.
Open Source and reducing waste. [6:23]
Accenture, while giving him a great chance to make some impressive projects, provoked Justin to see the efficiency in sharing code. Justin and a college friend get together to work on a project to build a platform that…builds. Although their project was unsuccessful, the tools they started to create for the project had plenty of potential.
The Last desperate gasp. AKA shaving his head. [9:40]
Justin talks about the Ajaxian blog and conference. Ten years ago, the Ajaxian blog was one of the best online resources for Javascript news. Justin was running low on funds and struggling and as his “last desperate gasp” he heads to the Ajaxian conference with his head shaved. Leaving only “Javascript MVC” shaped out of his hair. This stunt gets him remembered by many of the important attendees and also scores him his big break with a consulting job with T-Mobile. Two to Three weeks later, Justin had a stroke. Justin talks about how incredible the timing was.
How Javascript MVC came to be. [13:23]
Justin talks about starting with JSJunction and modeling after it. Their first steps were to add a model layer as well as Event Delegation. Javascript MVC reflects some of Ruby on Rails. Justin worked with Peter Svensson from Dojo, with a methodology that at the time seemed crazy. Justin reminisces when Steve Jobs “Killed” Flash with HTML5 and CSS.
Bitovi begins. [17:24]
Justin talks about how the T-Mobile job meant that he would need an official business. Originally dubbing it JupiterIT. Justin found that MVC was too encompassing and that programmers enjoyed a sense of creativity. By pulling Javascript MVC’s tools apart and creating single frameworks from the tools, Justin then created tools like CanJS and DoneJS.
Who does the heavy lifting at Bitovi? [20:48]
As the CEO of Bitovi, Justin has less time to program as before. Working with Open Source, development is a mix between contributors and full time employees. The majority being the employees. Justin talks about not having a sales force and focusing on their product to drive sales. Mainly, long term cost of ownership and the ability for the framework to last, working hard to make sure that clients that have committed to Javascript MVC years ago still have a relevant use for the framework.
Exploring HTTP2 and Push. [23:42]
With the emergence of HTTP2 and Push, Justin talks about working on and exploring different ways for streaming/server side rendering. Justin describes one of the experiments with building an empty skeletons, javascript assets, but also pushing instructions on how to mutate the page to the client. Before the javascript payload is fully loaded, the page starts to mutate. Allowing for optimal performance on slower connections, fantastic for mobile. Problems they are looking at for the future include things like different ways that CDNs can work with HTTP2 and Push. Justin has also worked with using Fetch to enable streaming by building tools around that. He suggests that HTTP2 and Push will maybe bring a renaissance in the developer world.
Justin’s side Parsing Project. [28:45]
Additional to his other work, Justin is working on a generic parsing project. Similar to BISON or JISON. Designed for simple parsing at faster speeds. He describes how to compiles to the code that parses your code. Working in runtime.
A way other companies can learn from Bitovi. [29:52]
We don’t know what the future is going to be for code, so packaging the framework into separate repos allows for better scheduling and a better way to manage long term. Updating a segment of a framework can sometimes break another segment if having it all happen together.
Picks [34:26]
Justin:
Dean Radcliff’s Antares Framework
Charles:
Boom Beach
Clash of Clans
BlueTick.io
Nimble
Keeping up with Justin’s work.
Bitovi.com’s Blog
Justin’s Twitter.
Sponsors
Cachefly.com
Newbie Remote Conf 2017
JSJ 265 Wade Anderson and Ramya Rao on Visual Studio Code
This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Wade Anderson and Ramya Rao from the Visual Studio Code Team at Microsoft. Tune in and learn more about what’s new with Visual Studio Code!
[00:01:20] – Introduction to Ramya Rao and Wade Anderson
Ramya Rao and Wade Anderson are in the Visual Studio Code Team at Microsoft.
Questions for Wade and Ramya[00:02:00] – Elevator Pitch for Visual Studio Code
Our vision on Visual Studio Code is to take what was best out of the IDE world (Visual Studio, Eclipse, IntelliJ, etc.) and bring what was best from the lightweight editor world (Sublime Text, Notepad++, Atom) and merge those two together. We wanted the lightweight features from text editors and the debugging capabilities of Visual Studio and Eclipse. We did general availability last year. We’ve been stable for a year. Additionally, this is Visual Studio Code for Mac, Windows, or Linux. It’s also built in Electron.
[00:03:45] – What are your roles on the team? Do you have particular parts that each of you work on?
Wade’s title is a Program Manager. He does more non-developer things but Ramya is an engineer on the team so she gets a lot more coding that Wade does. Everybody has a key area to own but nothing stops them to go into another area. We try to share knowledge between people but we always have that one key owner that you always go to.
Ramya is a recent addition to the team. She started out maintaining the Go extension, maintaining and adding features. She’s slowly branching out to the Emmet features of the product.
[00:05:30] What is Emmet?
Emmet, or Zen Coding, is a must-have tool for you. You can write, say abbreviations and that expands to really huge HTML to update tags, rename tags, etc. That is one of the features of Emmet and Sergey actually wrote the library. We have an in built integration in the product. I [Ramya] am currently working on that.
[00:06:28] Does Visual Studio Code make it easy to go to the parts that I need to customize on an HTML?
In that case, we have a multi-cursor software in Visual Studio Code, as well. You could place your cursor in different positions, and then, simultaneously edit things.
[00:07:42] Is Emmet an extension or does it come with Visual Studio Code?
Right now, it’s in Built. If you want to know more about Emmet features, you can to emmet.io. That has all the documentation that you need to learn about Emmet features. In Visual Studio Code right now, we’re looking at making into an extension. We pull it out of the main code and maybe more people can contribute and make it even more better.
[00:08:21] – What’s new in Visual Studio Code?
One of our main pillars for this year is to improve performance of the product. We’ve grown a larger team so we’re adding a lot more features every month. Last few months has been, “How can we get some stability on the issues coming in while making sure we’re reducing our tech load?” We really keep to those core principles that we started with at the beginning, which was, we want a fast, lightweight editor.
We built a few extensions that we call key map extensions. They are just a mapping of key bindings that you learned in Sublime Text. You don’t have to re-learn any key bindings in Visual Studio Code.
We also build this Welcome page where you can flip through and see features really briefly. In that Welcome page, one of the key things is an interactive playground where you can play with existing code in different sections. Additionally, as we’ve mentioned, we also put multi-cursor features.
Another thing is workbench naming. You can change the theme of Visual Studio Code but it will be restricted to the editor and not the rest of the workbench.
[00:13:40] – Do you know how Xterm.js works as it was one of the features that you’ve added in Visual Studio Code?
Daniel’s another engineer that’s here with us today. He was the largest contributor to the Xterm.js project. He built the integrated terminal for Visual Studio code so I can’t speak to the internals of how that works.
[00:14:12] – Are we going to start seeing Visual Studio Code integrated into web experiences with other Microsoft products?
That’s actually where we started. We were Monaco editor where you get this cloud-based editing experience. We’re getting people to use it but we’re only getting people who were already using Microsoft products. When electron came out, we saw an opportunity of, “Hey, can we port this Monaco editor to Electron and we could then, run it on Mac and Linux.”
[00:19:45] – What are the performance things that you’ve done?
One thing that we did recently was adding an ability to calculate the start time for Visual Studio Code? That’s one of our full steps to get more information from the user-side. How can you get a profile of what things are running? Which part of the process took much time?
We also need to identify what are the things people are doing that’s causing the editor slow down. An example is when you open a large file and things get laggy.
Another exercise we did was we looked at all of our extension API’s to see which one of those could be a malicious extension.
The difference between VS Code and Atom is that, we ask questions like, “Are we using good data structures? Are we managing our memory properly? Are we removing stuff we don’t need anymore?” That just comes down to all those little things you learn from basic textbooks that have been around for decades about how to write good code. That’s what we have been doing and that’s what we’ll continue to try to do, to try and improve the performance.
[00:25:55] – Do you have problem on the desktop? Are all the modules just load at once?
We definitely don’t load everything at once. Different parts of the editor is loaded differently. When you do the Require, we don’t do it at first load. We do it when we notice that the user wants to use Emmet. We don’t try to load all the library at the beginning and delay the whole process.
We try to lazy load as much as possible, even the extensions. We have a separate process called extension host that takes care of loading all the extensions. Whether the extensions are completed loading or not, that does not stop you from typing in a file. Simple actions shouldn’t be bugged down by fancy actions.
[00:28:25] – What’s coming next for Visual Studio Code?
Every month, when we plan our iteration, we create iteration draft plan. We put it out there for people to see. Performance and helping people get started are probably the top two for us. You can look at github.com/Microsoft/vscode, look for the label ‘iteration plan draft.’ So that’s the current work that we’re doing that month.
Another feature is the multi-root workspace where you can open multiple folders. When you look at the issues and sort by most comments, multi-root is the number one. The second one that is little paper cuts around formatting and auto-intending – just things that make your code prettier.
PicksAJ O’neal
Charles Max Wood
Wade Anderson
Ramya Rao
On this week's episode of My JS Story, Charles Max Wood interviews Alex Russell. Alex is a software engineer on the Chrome team. He focuses on designing new features and running their standards work. He appeared as a guest on episode 87, where he talked about TC39. Tune in to his story!
This episode features Moving from Node.js to .NET and Raygun.io with John-Daniel Trask. John-Daniel is the Co-founder and CEO of Raygun, a software intelligence platform for web and mobile. He's been programming for many years, and is originally from New Zealand. Tune in and learn what prompted them to move to the .NET framework!