Code News

The Story of CSS Grid, from Its Creators

  • A note from the editors: We want to thank the Microsoft Edge team for sharing transcripts of the interviews they conducted with many of the brilliant people who have contributed to the development of CSS Grid. Those transcripts proved invaluable in compiling this history. You can watch the short video they produced from those interviews, Creating CSS Grid, on Channel 9.

    On October 17th, Microsoft’s Edge browser shipped its implementation of CSS Grid. This is a milestone for a number of reasons. First, it means that all major browsers now support this incredible layout tool. Second, it means that all major browsers rolled out their implementations in a single year(!), a terrific example of standards success and cross-browser collaboration. But third, and perhaps most interestingly, it closes the loop on a process that has been more than 20 years in the making.

    Not a new idea

    While the modern concept of a “grid layout” has been with us since the Industrial Revolution, grids have been a design tool for centuries. As such, it shouldn’t come as a shock that grid-based layouts have been a goal of CSS since the beginning.

    According to Dr. Bert Bos, who co-created CSS with Håkon Wium Lie, grid-based layouts have actually been on his mind for quite some time.

    “CSS started as something very simple,” Bos recalled. “It was just a way to create a view of a document on a very simple small screen at the time. Twenty years ago, screens were very small. So, when we saw that we could make a style sheet for documents, we thought, Well, what else can we do now that we have a system for making style sheets?

    Looking at what books and magazines were doing with layout was a great inspiration for them.

    “Independent of the content on every page, it has a certain layout,” Bos said. “Page numbers are in certain places. And images are always aligned to the certain sides—left or right or in the middle. We wanted to capture that.”

    Early on, browser makers wrote off the idea as “too complex” to implement, but grid layout concepts kept cropping up. In 1996, Bos, Lie, and Dave Raggett came up with a “frame-based” layout model. Then, in 2005, Bos released the Advanced Layout Module, which later turned into the Template Layout Module. Despite enthusiasm for these concepts from the web design community, none of them ever shipped in a browser.

    Once more, with feeling

    With grid concepts being thrown at the wall of the CSS Working Group with some regularity, folks were hopeful one of them would stick eventually. And the idea that did was a proposal from a couple of folks at Microsoft who had been looking for a more robust layout tool for one of their web-based products.

    Phil Cupp had been put in charge of the UI team tasked with reimagining Microsoft Intune, a computer management utility. Cupp was a big fan of Silverlight, a browser plug-in that sported robust layout tools from Windows Presentation Foundation, and initially had planned to go that route for building the new Intune. As it happened, however, Microsoft was in the planning stages of Windows 8 and were going to enable building apps with web technologies. Upon learning this, Cupp wanted to follow suit with Intune, but he quickly realized that the web was in desperate need of better layout options.

    He joined a new team so he could focus on bringing some of the rich layout options that existed in Silverlight—like grid layout—to the web. Interestingly, folks on this new team were already noticing the need. At the time, many app developers were focusing on iPhones and iPads, which only required designers to consider two different fixed canvas sizes (four, if you consider portrait and landscape). Windows had to support a ton of different screen sizes, screen resolutions, and form factors. Oh, and resizable windows. In short, Microsoft needed a robust and flexible layout tool for the web desperately if the web was going to be an option for native app development on Windows.

    After working extensively with various teams within Microsoft to assemble a draft specification, Cupp and his team shipped a grid layout implementation behind the -ms- vendor prefix in Internet Explorer 10 in 2011. They followed that up with a draft Grid Layout spec, which they presented to the W3C in 2012.

    Of course, this was not the first—or even the third—time the W3C had received a grid layout spec to consider. What was different this time, however, was that they also had an actual implementation to evaluate and critique. Also, we, as developers, finally had something we could noodle around with. Grid layout was no longer just a theoretical possibility.

    A handful of forward-thinking web designers and developers—Rachel Andrew, an Invited Expert to the W3C, chiefly among them—began to tinker.

    “I came across CSS Grid initially at a workshop that Burt Bos was leading in French. And I don’t really speak French, but I was watching the slides and trying to follow along,” Andrew recalled. “I saw him demonstrate … the Template Layout spec. I think he was really talking about it in terms of print and using this stuff to create print layouts, but as soon as I saw that, I was like, No, we want this for the web. This is something that we really need and its feasibility to properly lay things out. And so I started digging into it, and finding out what he was doing, and building some examples.”

    “Then I saw the Microsoft implementation [of the draft Grid Layout spec], which gave me a real implementation that I could build examples to show other people. And I wanted to do that—not just because it was interesting, and I like interesting things to play with—it was because I wanted to get it out there and get other people to have a look at it. Because I’ve been doing this for a long time and I know that specs often show up, and then no one really talks about them, and they kinda disappear again. And I was absolutely determined that Grid Layout wasn’t gonna disappear, it was gonna be something that other people found out about and got excited about it. And hopefully we’d actually get it into browsers and be able to use it.”

    The spec evolves

    The draft spec that Cupp presented to the W3C, and that his team shipped in IE10, is not the Grid Layout spec we have today. It was a step in the right direction, but it was far from perfect.

    “The one [Phil Cupp submitted] was a very track-based system,” recalled Elika Etemad, an Invited Expert to the W3C and an Editor of the CSS Grid Layout Module. “There was only a numeric addressing system, there were no line names, there [were] no templates, none of that stuff. But it had a layout algorithm that they … were confident would work because they had been doing experimental implementations of it.”

    “The original grid that Bert [Bos] came up with … was really the reason I joined the CSS Working Group,” recalled Google’s Tab Atkins, another Editor of the CSS Grid Layout Module. “At the time, I was learning all the terrible layout hacks and seeing the possibility to just write my page layout in CSS and just have it all, kinda, work was astonishing. And then seeing the draft from Phil Cupp … and seeing it all laid out properly and with a good algorithm behind it, I knew that it was something that could actually exist now.”

    It was also a compelling option because, unlike previous proposals, which specified rigid layouts, this proposal was for a responsive grid system.

    “You can [be] explicit about the size of a grid item,” Etemad explained. “But you can also say, Be the size that your content takes up. And that was what we needed to move forward.”

    However, the draft spec wasn’t as approachable as many on the CSS Working Group wanted it to be. So the group looked to bring in ideas from some of its earlier explorations.

    “What we really liked about Burt [Bos]’s proposal was that it had this very elegant interface to it that made it easy to express layouts in a way that you can intuitively see,” Etemad said. “It’s like an ASCII art format to create a template, and you could put [it] in your code, like the width of the columns and the heights of the rows. You could embed those into the same kind of like ASCII diagram, which made it a lot easier to see what you were doing.”

    Peter Linss, then Co-Chair of the CSS Working Group, also suggested that they incorporate the concept of grid lines in the spec (instead of only talking about tracks). He believed including this familiar graphic design concept would make the spec more accessible to designers.

    “When we were thinking initially about CSS Grid, we were thinking about it in a very app-centric model,” recalled Microsoft’s Rossen Atanassov, who is also an Editor on the spec. “But grid is nothing new. I mean, grid’s been here for a very long time. And that traditional type of grid has always been based on lines. And we’d been kind of ignoring the lines. When we realized that we could marry the two implementations—the app side and the typography side of the Grid—this for me, personally, was one of those aha moments that really inspired me to continue working on Grid.”

    So the CSS Working Group began tweaking Microsoft’s proposal to incorporate these ideas. The final result allows you to think about Grid systems in terms of tracks or lines or templates or even all three at once.

    Of course, getting there wasn’t easy.

    Refine, repeat

    As you can probably imagine, reconciling three different ideas—Microsoft’s proposal, Bos’ Advanced Layout, and Linss’ addition of grid lines—wasn’t a simple cut and paste; there were a lot of tricky aspects and edge cases that needed to be worked out.

    “I think some of the tricky things at the beginning [were] taking all the different aspects of … the three proposals that we were trying to combine and coming up with a system that was coherent enough to gracefully accept all of that input,” Etemad said.

    Some ideas just weren’t feasible for phase one of a CSS grid. Bos’ concept, for instance, allowed for any arbitrary descendent of the grid to lay out as though it were a child element of the grid. That is a feature often referred to as “subgrid” and it didn’t make the cut for CSS Grid Layout 1.0.

    “Subgrid has been one of those things that was pointed out immediately,” Atanassov said. “And that has been a blessing and kind of a hurdle along the way. It was … one that held back the spec work for quite a bit. And it was also one that was scaring away some of the implementers. … But it’s also one of the features that I’m … most excited about going forward. And I know that we’re gonna solve it and it’s gonna be great. It’s just gonna take a little while longer.”

    Similarly, there were two options for handling content mapped to grid lines. On the one hand, you could let the grid itself have fixed-dimension tracks and adjust which ending grid line the overflowing content mapped to, based on how much it overflowed. Alternately, you could let the track grow to contain the content so it ended at the predefined grid line. Having both was not an option as it could create a circular dependency, so the group decided to put the grid-snapping idea on hold.

    Ultimately, many of these edits and punts were made in light of the CSS Working Group’s three primary goals for this spec. It needed to be:

    1. Powerful: They wanted CSS Grid to enable designers to express their desires in a way that “made simple things easy and complex things possible,” as Etemad put it;
    2. Robust: They wanted to ensure there would not be gaps that could cause your layout to fall apart, inhibit scrolling, or cause content to disappear accidentally;
    3. and Performant: If the algorithm wasn’t fast enough to elegantly handle real-world situations like browser resize events and dynamic content loading, they knew it would create a frustrating experience for end users.

    “[T]his is why designing a new layout system for CSS takes a lot of time,” Etemad said. “It takes a lot of time, a lot of effort, and a lot of love from the people who are working on it.”

    Where the rubber meets the road

    Before a Candidate Recommendation (aka, a final draft) can become a Proposed Recommendation (what we colloquially refer to as a “standard”), the W3C needs to see at least two independent, interoperable implementations. Microsoft had implemented their draft proposal, but the spec had changed a lot since then. On top of that, they wanted to see other browsers take up the torch before they committed more engineering effort to update it. Why? Well, they were a little gun-shy after what happened with another promising layout proposal: CSS Regions.

    CSS Regions offered a way to flow content through a series of predefined “regions” on a page, enabling really complex layouts. Microsoft released an implementation of CSS Regions early on, behind a prefix in IE 10. A patch landed support for Regions in WebKit as well. Safari shipped it, as did Chrome (which was still running WebKit under the hood at the time). But then Google backed it out of Chrome. Firefox opposed the spec and never implemented it. So the idea is currently in limbo. Even Safari will drop its experimental support for CSS Regions in its next release. Suffice it to say, Microsoft wanted to be sure Grid wouldn’t suffer the same fate as Regions before committing more engineering resources to it.

    “We had implementers that immediately said, ‘Wow, this is great, we should definitely do it,’” recalled Atanassov of Grid. “But [it’s] one thing … saying, ‘Yeah this is great, we should do it,’ and then there’s the next step where it’s adding resources and paying developers to go and actually implement it.”

    “There was desire from other implementers—one of the spec editors is from Google—but there was still hesitancy to actually push code,” recalled Microsoft’s Greg Whitworth, a member of the CSS Working Group. “And … shipping code is what matters.”

    In an interesting turn of events, the media company Bloomberg hired Igalia, an open source consultancy, to implement CSS Grid for both Blink and WebKit.

    “Back in 2013 … [we] were contacted by [Bloomberg] … because they had very specific needs regarding defining and using grid-like structures,” recalled Sergio Villar Senin, both a software engineer at and partner in Igalia. “[T]hey basically asked us to help in the development of the CSS Grid layout specification, and also [to] implement it for [Blink and WebKit].”

    “[Igalia’s work] helped tremendously because then developers [could] see it as possibly something that they can actually use when developing their sites,” Whitworth added.
    But even with two ready-made implementations, some folks were still concerned the feature wouldn’t find its footing. After all, just because a rendering engine is open source doesn’t mean its stewards accept every patch. And even if they do, as happened with CSS Regions, there’s no guarantee the feature will stick around. Thankfully, a good number of designers and developers were starting to get excited about Grid and began to put pressure on browser vendors to implement it.

    “There was a pivotal shift with CSS Grid,” Whitworth said. “Starting with Rachel Andrew coming in and creating a ton of demos and excitement around CSS Grid with Grid by Example and starting to really champion it and show it to web developers and what it was capable of and the problems that it solves.”

    “Then, a little bit later, Jen Simmons [a Designer Advocate at Mozilla] created something called Labs where she put a lot of demos that she created for CSS Grid up on the web and, again, continued that momentum and that wave of enthusiasm for CSS Grid with web developers in the community.”

    Grid facilitates both traditional and (as shown here) non-traditional layouts. This is a Grid Layout example from Jen Simmons’ Labs, as seen in Edge 16. If you’d like to see it working in Edge but don’t run Windows, you can also view it in BrowserStack (account required).

    With thought leaders like Andrews and Simmons actively demonstrating the power and versatility of CSS Grid, the web design community grew more excited. They began to experiment on sites like CodePen, sharing their ideas and developing their Grid layout skills. We don’t often think about it, but developer enthusiasm has the power to bolster or bury a spec.

    “We can write a spec, we can go implement things, but if there isn’t developer demand or usage of the features, it doesn’t really matter how much we do with that,” Whitworth said.

    Unfortunately, with ambitious specs like Grid, the implementation cost can often deter a browser vendor from making the commitment. Without a browser implementation enabling developers to tinker and experiment, it’s hard to build enthusiasm. Without developer enthusiasm, browser vendors are reluctant to spend the money to see if the idea gains traction. I’m sure you can see the problem here. In fact, this is partly what has doomed Regions—performance on mobile chipsets was another cited reason—at least for now.

    Thankfully, Bloomberg willingly played the role of benefactor and got the ball rolling for this new incarnation of CSS Grid. So, with its help, Google landed an implementation of CSS Grid in Chromium 56 for Android in January of 2017. It landed its Chrome implementation in early March, just two days after Mozilla shipped its own implementation in Firefox. Before the month was over, Opera and Safari had also shipped support for CSS Grid.

    Ironically, the last company to ship CSS Grid was Microsoft. But it released its implementation in Edge earlier this week.

    “With features on the web platform … you’re waiting for a sweet spot,” Whitworth said, just prior to Grid’s release in Edge. “You want a solid spec, you want implementer interest, and you want tons of demand from web developers. Late 2016/early 2017 was that sweet spot. All of that happened. We upgraded our implementation and are stoked to ship it.”

    “I don’t recall a feature ever shipping like CSS Grid has shipped. Every major browser will have shipped it within a matter of a single year, and it will be interoperable because we’ve been… implementing [it] behind flags, testing it, making future changes behind flags, and then when it was deemed stable, all the browsers are now shipping it natively.”

    “With everybody shipping at approximately the same time,” Atkins said, “[Grid] goes from an interesting idea you can play with to something that you just use as your only layout method without having to worry about fallbacks incredibly quickly. … [It’s been] faster than I expected any of this to work out.”

    What Grid means for CSS

    With Grid support no longer in question, we can (and should) begin to make use of this amazing tool. One of the challenges for many of us old timers who have been working with CSS for the better part of two decades, is that CSS Grid requires a whole new way of thinking about layout.

    “It’s not just attaching your margins and properties to each individual element and placing them,” Bos said. “[Y]ou can now have a different model, a model where you start with your layout first and then pull in the different elements into that layout.”

    “It is the most powerful layout tool that we have invented yet for CSS,” Atkins said. “It makes page layouts so ridiculously easy. … [P]eople have always been asking for better layouts. Just for author-ability reasons and because the hacks that we were employing weren’t as powerful as the old methods of just put[ting] it all in a big old table element—that was popular for a reason; it let you do powerful complex layouts. It was just the worst thing to maintain and the worst thing for semantics. And Grid gives you back that power and a lot more, which is kind of amazing.”

    “CSS Grid takes all of that complicated stuff that we had to do to [achieve] basic layouts and makes it completely unnecessary,” Etemad said. “You can talk to the CSS engine directly[—]you, yourself, without an intermediary translator.”

    CSS Grid offers a lot of power that many of us are only just starting to come to grips with. It will be interesting to see where we go from here.

    “I think it’s going to be transformative,” Etemad said. “It’s going to take CSS back to what it was meant to be, which is styling and layout language that lifts all of that logic away from the markup and allows that clean separation of content and style that we’ve been trying to get from the beginning.”

    “I’m excited about the future of CSS layout,” Whitworth said. “CSS Grid is not the end; it’s actually just the beginning. In IE 10 … [we shipped] CSS Regions as well as CSS Exclusions. I think as web designers begin to utilize CSS Grid more and more, they’ll realize why we shipped all three together. And maybe we can continue what we did with CSS Grid and continue to improve upon those specifications. Get vendor desire to implement those as well. Get the community excited about them and push layout on the web even further.”

    “I think that now we have Grid, Exclusions makes absolute sense to have,” Andrew said. “It gives us a way to place something in [a grid] and wrap text around it, and we don’t have any other way to do that. … And then things like Regions … I would love to see that progress because … once we can build a nice grid structure, we might want to flow content through it. We don’t have a way of doing that.”

    “[A]s far as I’m concerned, this doesn’t stop here; this is just the start.”

    Getting into Grid

    4 days 9 hours ago

Essential JavaScript Libraries and Frameworks You Should Know About

  • JavaScript has been around for 20+ years, and it's one of those languages that never stop evolving. The language has been experiencing a fast-paced growth recently that makes me wonder whether the modern front-end JavaScript technologies that are well known today will be relevant a couple of years later. 

    Nevertheless, it's important to be ahead of the game by working with the latest tools and frameworks for a better development workflow. This article explores various JavaScript libraries, frameworks, and tools that you should consider learning right now.

    Introduction

    The JavaScript environment has grown huge. It has its own ecosystem of libraries, frameworks, tools, package managers and new languages that compile down to JavaScript. Interestingly, npm, which is the de facto package manager for JavaScript, is also the largest software registry in the world. Here is an excerpt from a post published on Linux.com back in January 2017.

    At over 350,000 packages, the npm registry contains more than double the next most populated package registry (which is the Apache Maven repository). In fact, it is currently the largest package registry in the world.

    Fast forward eight months, and there are currently about 500,000 packages in the npm registry. That's a massive growth compared to other package repositories. 

    Source: ModuleCounts.com

    As a front-end JavaScript developer, it's important to keep up with the modern JavaScript tools and libraries. When a technology becomes popular, demand for it is high, which in turn means more coding jobs that pay the highest salary in the industry. So I've assembled a list of the popular JavaScript technologies that I think you should be aware of. 

    Libraries

    A library is a reusable piece of code that offers certain functionality. It is a collection of functions, objects, and classes that you can use in your application. A library abstracts different layers so that you don't have to be concerned about their implementation details. 

    You can call a library function and pass it some parameters, and the library executes it and returns the control back to you. However, it doesn't place any structural constraints that restrict how you use the library. Popular JavaScript libraries include:

    React

    React is a JavaScript library built by the developers of Facebook and Instagram. React was voted as the most-loved technology among developers, according to the Stack Overflow Survey 2017. React also holds the credit for being the most popular JavaScript project based on GitHub star count. 

    So why is React getting all the attention? With React, it is possible to create an interactive UI using a declarative approach where you can control the state of the application by saying "the view should look like this". It uses a component-based model where the components are reusable UI elements and each component has its own state.

    React uses a Virtual DOM so that you don't have to be concerned about directly manipulating the DOM. Other notable features of React include one-way data flow, optional JSX syntax, and a command-line tool for creating a React project with zero build configuration. 

    If you believe that React is the next best thing and would like to learn React, check out our React Crash Course for Beginners tutorial series.

    jQuery

    jQuery is a library that made JavaScript more approachable and DOM manipulation easier than before. jQuery's gentle learning curve and easy syntax gave rise to a generation of new client-side developers. A few years back, jQuery was considered a solid solution for building robust websites with cross-browser support. jQuery's core features such as DOM manipulation based on CSS selectors, event handling, and making AJAX calls fueled its popularity. 

    However, things have changed, and the JavaScript environment has steadily evolved. Some of jQuery's features have been incorporated into the newer ECMAScript specification. Moreover, the new libraries and frameworks in use today have a native way of binding the DOM, and hence plain DOM manipulation techniques are not required anymore. jQuery's popularity is on the decline, but I don't see it disappearing anytime soon.

    D3: Data-Driven Documents

    D3 (or D3.js) is a powerful JavaScript library for producing interactive visualizations using web standards such as SVG, HTML, and CSS. Unlike other visualization libraries, D3 offers better control over the final visual result. 

    D3 works by binding the data to the DOM and then making the transformation to the document. It also has an ecosystem of its own, which consists of plugins and libraries that extend its basic functionality. The library has been around since 2011, and it has tons of documentation and tutorials that can help you get started. 

    If you are looking to create simple visualizations without investing too much time in it, you should check out Chart.js. We have an introductory series on Chart.js that covers most of the visualizations that you can create with Chart.js

    Frameworks

    A framework has an architecture that dictates the flow of control in your application. The framework describes the skeleton and tells you how everything should be organized. The basic functionality required to get the application up and running is also provided to you. Moreover, you are bound to follow the framework's design principles and patterns. The difference between a framework and library is that you call a library, whereas the framework calls you. 

    A framework often comprises of many libraries and has a higher level of abstraction. Functionality such as event handling, making AJAX calls, template and data binding, and testing are built into the framework.  

    Angular

    AngularJS was once the most popular JavaScript technology among front-end developers. It was backed by Google and a community of individuals and corporations. Despite the popularity, AngularJS had its own share of flaws. The Angular team spent two years working on a newer version of Angular, which was finally released in September 2016. 


    The Angular 2 release was a ground-up rewrite of AngularJS. Some of the features of Angular 2 include:

    • TypeScript over JavaScript as the default language
    • component-based architecture
    • improved performance on both mobile and web platforms. 
    • better tooling and scaffolding options

    However, upgrading from Angular 1.x to Angular 2 is expensive because Angular 2 is an entirely different beast. That's one of the reasons why Angular 2 hasn't experienced the same adoption rate as that of its predecessor. But Angular and AngularJS continue to be among the most commonly used technologies according to Stack Overflow (2017). The Angular project has about 28,000 stars on GitHub.

    Vue.js

    Vue.js is a lightweight JavaScript framework that has been trending this year. It is the most popular JavaScript framework on GitHub in terms of the GitHub star count. Vue claims to be a less opinionated framework and thus easy for developers to catch up with. Vue's HTML-based template syntax binds the rendered DOM to the instance data. 


    The framework offers a React-like experience with its Virtual DOM and reusable components that you can use to create both widgets and entire web applications. Moreover, you can also use the JSX syntax to write the render functions directly.  When the state changes, Vue.js uses a reactivity system to determine what has changed and rerenders the minimal number of components. Vue.js also supports the integration of other libraries into the framework without much hassle.

    Ember.js

    Ember.js is a front-end framework based on the  Model-View-ViewModel (MVVM) pattern. It follows the convention over configuration approach which is popular among server-side side frameworks like Ruby on Rails and Laravel. Ember.js incorporates common idioms and best practices into the framework so that you can get an application up and running without much effort. 

    The Ember stack usually comprises:

    • Ember CLI: Provides basic scaffolding options and supports hundreds of add-ons.
    • Ember Data: A data persistence library that can be configured to work with any server back end.
    • Ember Inspector: An extension available for Chrome and Firefox.
    • Liquid Fire:  An add-on for transitions and animations.
    Tools

    A tool is a collection of routines that help you in the development process. Unlike a library, a tool usually executes a task on the client code. It takes your code as input, performs a task on it, and then returns an output. The commonly used tools include transpilers and build tools, asset minifiers, module bundlers, and scaffolding tools. 

    Tools: General-Purpose Task Runners

    General-purpose task runners are the tools used to automate certain repetitive tasks. The popular general-purpose task runners include:

    Gulp 

    Gulp is a JavaScript toolkit used as a task runner and as a build system in web development. Compilation, code minification, image optimization, unit testing, linting etc. are repetitive tasks that should be automated. Gulp makes the process of writing tasks easier, even for people who are less familiar with JavaScript. 

    Gulp uses pipelines to stream the data from one plugin to another, and the final result is outputted to a destination folder. Gulp performs better compared to Grunt because it doesn't create temporary files for storing intermediate results, which results in fewer I/O calls.

    Grunt

    Grunt is a task runner and an automation tool for JavaScript. Grunt has a command-line interface that lets you run custom tasks defined in a file called a Gruntfile. Grunt has thousands of plugins to choose from, which should cover most of the common repetitive tasks that you'd encounter. With Grunt, you can run all the tasks under a single command, making your life easier.

    npm 

    Gulp and Grunt require you to spend time learning and mastering a new tool, which takes time. Introducing additional dependencies into your project can be avoided by choosing an alternative that is already bundled with Node.js. Although npm is better known as a package manager, npm scripts can be used to perform the bulk of the abovementioned tasks. 

    Tools: Testing

    Testing is the process of validating and verifying that the application meets the expected business and technical requirements. The Test-Driven Development approach also aids in discovering bugs and therefore should be treated as an integral part of the modern front-end development stack.

    Jest

    Jest is a relatively new testing framework authored by Facebook and is well-received by the React community. There is a common misconception that Jest is specifically designed to work with React; however, according to the Jest Documentation:

    Although Jest may be considered React-specific test runner, in fact it is a universal testing platform, with the ability to adapt to any JavaScript library or framework. You can use Jest to test any JavaScript code.

    The biggest advantage of using Jest over other test suites is that you require zero or minimal configuration to start writing tests. The framework has a built-in assertion library and supports the use of mock functions or spies.

    Jest has a feature called snapshot testing that lets you ensure that the UI of the application doesn't change unexpectedly. The developers at Facebook and other contributors have been pouring a lot of work into this project recently, so it wouldn't be a surprise if Jest turns out to be the most popular testing framework for JavaScript in the years to come.

    Mocha 

    Mocha is a JavaScript testing framework that features browser support, async support including promises, test coverage reports, and a JavaScript API for running tests. Mocha is often paired with an assertion library such as Chai, should.js, expect.js, or better-assert because it lacks an assertion library of its own. 


    Jasmine

    Jasmine is a behavior-driven testing framework for JavaScript. Jasmine aims to be a browser, platform, and framework-independent test suite. Jasmine has its own assertion library called matchers that gives it a clean and easy-to-read syntax. Jasmine doesn't have a built-in test runner, and you might have to use a generic test runner like Karma instead. 


    Summary

    JavaScript, the language of the web, has stayed relevant since the days of its inception back in 1995. It will probably stay that way as long as browsers don't decide to ditch it for another language. Although there are a lot of other languages that compile down to JavaScript, there is no other scripting language that will replace JavaScript in the foreseeable future. Why? Because JavaScript has grown too popular to be replaced.

    The language is not without its learning curves, and there are plenty of frameworks and libraries to keep you busy, as well. If you’re looking for additional resources to study or to use in your work, check out what we have available in the Envato Market

    The JavaScript environment is definitely evolving, which is evident from the current trends in web development. Older libraries and frameworks have been replaced with new technologies. jQuery, which was once the most favored JavaScript library, is experiencing a decline in terms of appeal, usage, and popularity. The new generation of front-end libraries, frameworks, and tools are gaining ground and getting universal acceptance. 

    Adapting to the new trends in technology has benefits too. Coding jobs that require React have some of the highest salaries in the industry, with an average salary of $105,000 in the U.S. according to Stack Overflow (2016). So you need to continue learning and experimenting with the latest tools and frameworks to get the best out of JavaScript. 

    If you think I've missed a JavaScript framework, library or tool that is worth mentioning, let me know through the comments. 

    Further Reading

    4 days 10 hours ago

FCC Shouldn't Give Up on Reforming Inmate Phone Services

To Survive the Streets, Self-Driving Cars Must Learn to Think Like Humans

Could San Francisco Get the Oil Industry to Pay for Climate Change?

Tony Fadell, Co-inventor of the iPod, Gets Back at Silicon Valley—From Paris

Alphabet, Google, and Sidewalk Labs Start Their City-Building Venture in Toronto

This Robot Tractor Is Ready to Disrupt Construction

How You Can Support LGBTQ Youth as a Mobile App Developer

  • October 19th is Spirit Day, a day for supporting LGBTQ youth and speaking about against the bullying and harassment they too often face. Here at Envato Tuts+, we're proud to stand against bullying and discrimination of any kind, so we're going purple to show we stand with lesbian, gay, bisexual, transsexual and queer youth.

    In this post, we'll take a quick look at some of the ways we can support LGBTQ youth as app developers.

    Avoid Coding Assumptions About Your Users' Identities

    It's really important that we as developers avoid coding assumptions about gender and sexual identity into our apps. Anyone in a gender or sexual minority will understand this point immediately, but for others it can be easy to let gender assumptions creep into our code without even realizing it.

    Gender Mutability

    In my role as editor of mobile content for Envato Tuts+, I see assumptions like this crop up occasionally when reviewing code snippets and examples. For instance, in the Swift language, you might model a person as follows.

    class Person { let gender: Gender // ... other data about a person init(gender: Gender) { self.gender = gender } }

    Pretty straight-forward, but there's one problem: the gender property of Person is immutable and set in the class initializer. But real people can change the gender they are identified with! This is a somewhat artificial example, of course there could be provisions in other parts of the codebase or system for users to change their gender, but it demonstrates how gender assumptions can cause problems. Imagine if the assumption that gender is unchangeable were coded into a university enrollment or drivers license database. It would lead to a system that was unable to accurately model the people it represents!

    Remember, in real life, gender is a var (mutable).

    Modeling Gender

    Similarly, how should we model the Gender type? In the past, a lot of devs and database designers have represented gender as an enum. Again, in Swift, we might have:

    enum Gender { case male case female }

    I'm sure you see the problem: a binary choice between "male" and "female" doesn't encompase the range of gender identities held by app users today. If you make your users choose between one of these alternatives, you will be sure to alienate a lot of them. The online dating app OkCupid had this problem in its early years, causing many potential users to be excluded—to be unable or feel uncomfortable to use the service. In 2014 though, OkCupid (along with social media giant Facebook) overhauled their gender and sexual orientation model.

    OkCupid's is an example of a well thought-out system for modeling gender and sexual orientation and it's worth referencing if you need to provide for gender in your app. 

    In Swift then, we might implement a very inclusive Gender type as follows:

    enum GenderCategory { case agender, androgynous, bigender, cisMan, cisWoman, genderfluid, genderqueer, genderNonconforming, hijra, intersex, man, nonBinary, pangender, transfeminine, transgender, transMan, transmasculine, transsexual, transWoman, twoSpirit, woman case other(String) } typealias Gender: [GenderCategory]

    This would let users select from a broad range of established gender identities, choose multiple simultaneous identities, and even supply their own if the supplied options were not enough.

    Non-Traditional Families

    For a final example, suppose that we had the following properties in the Person class:

    var mother: Person var father: Person

    This assumes that a person has one mother and one father. For many people, raised in non-traditional families, that is simply not the case. For instance, I have a friend who was raised in a house with five mothers. How lucky for her! 

    A better way to model parent relations might be:

    var parents: [Person] Inclusive Apps

    As mobile apps and software in general become more and more central to people's lives, we have a responsibility as developers to make sure that our apps are as inclusive as possible. If we make assumptions about gender or sexual identity, we exclude some potential users of our apps limit their opportunity to use the service our apps provide. 

    The same goes for other assumptions about users. Check out this great list of Falsehoods Programmers Believe About Names.

    Tell Stories and Explore LGBTQ Themes in Your Game

    If you are a mobile game developer, you have a great opportunity to support the LGBTQ community by including diverse characters in your game, and by allowing users to use their preferred gender identity and sexual orientation in the game.

    For an overview of ways that LGBTQ issues can and have been addressed in games, check out Michael James Williams' Spirit Day 2015 post.

    Write an App to Support LGBTQ Youth

    Whatever issue you are passionate about, you have a real opportunity to make a difference by developing a custom app to support that cause. Even if you're just learning to code apps, or only setting out in your career, this can be a great way to get started. Let's face it, your app has a much better chance of getting noticed if it is connected to a social issue that people care about. 

    Here is a list of some apps that have been created to help LGBTQ youth and other victims of bullying. Be inspired!

    Verena

    The title of this app means "protector" and it is intended to help its users find protection in times of crisis: directing them to police stations, hospitals, shelters and other places of refuge, as well as notifying a designated list of contacts in case of emergency.

    Verana was created by 15 year old Amanda Southwith to support her friends in the LGBTQ community. One clever feature is that the app has an incognito mode, disguised to look like a homework helper. That way, youth who might not be able to be open about their sexual identity are safe to have and use the app on their phone.

    You're Accepted

    Coming out is an extremely difficult and even dangerous time for many LGBTQ youth. Many teens have faced cruel bullying, abuse, or disownment and expulsion from their family home. The creators of the You're Accepted app are trying to make this transition easier by helping users build a network of safety and support before coming out.

    You're Accepted is a message platform that allows LGBTI youth to tell their friends their sexuality or gender identity, anonymously. You can see their responses and then decide who to tell. -- You're Accepted

    The creators of the app believe that no one should live in fear of being themselves and have written this app to help counter online discrimination against LGBTQ youth.

    PRIDE Study

    This app was created by doctors and scientists at the University of California in San Francisco to investigate connections between being a gender or sexual minority and long-term health outcomes.

    The PRIDE Study deeply explores how the experience of being LGBTQ is related to all aspects of health and life. -- PRIDE Study

    This will help doctors, governments and community groups understand how to support LGBTQ health.

    The PRIDE Study is built on Apple's ResearchKit framework, announced at Apple's Spring Forward event in 2015. This technology allows researchers to easily enroll and collect data from participants in large-scale, longitudinal studies—studies that collect health information over time.

    Know Bullying

    While not a problem unique to LGBTQ youth, all too many LGBTQ youth experience some sort of bullying. This experience can by deeply painful and has driven many young people to depression, self-harm, and even suicide. The app is a tool to help parents and teacher check in with children and detect the signs of bullying. Some of the features of the app include

    • tips about the kinds of bullying experienced in specific age groups
    • warning signs that a child might be bullied or be engaged in bulying
    • conversation starters to help engage with children

    Know Bullying was created by the US Substance Abuse and Mental Health Services Administration (SAMHSA) and it's packed with information for parents and educators to help them detect and prevent bullying.

    Quist

    Quist, short for "quistory" or "queer history", was created to celebrate and educate young people in the history of the struggle for LGBTQ rights. Every day, the app shows users a collection of events from that day in history so that users can see:

    How far the LGBTQ community has come over time—how we have been treated, how we have reacted, how our allies have supported us, and how others have worked vehemently to stop the progress. -- Quist 

    With this youth-friendly app, the Quist team is trying to educate and inform the world about the deep history of LGBTQ communities, and to provide support to individuals by showing how others throughout history have shared their struggle.

    Circle of 6

    Circle of 6 is an easy-to-use tool designed to help teenagers and college students prevent sexual violence and get out of bad situations.

    Need help getting home? Need an interruption? Two taps lets your circle know where you are and how they can help. Circle of 6 app for iPhone and Android makes it quick and easy to reach the 6 people you choose. -- Circle of 6

    The Circle of 6 app was created for the 2011 Apps Against Abuse White House challenge. And won! With more than 150,000 students in 32 countries, the app has received press from around the world. 

    The app creators say that they are inspired to make the world a better place with "technology that enhances friendship and trust". 

    Conclusion

    Bullying of LGBTQ youth is a huge problem, with 85% of LGBTQ youth reporting having been verbally harassed, 48% reporting experiencing cyberbullying, and 13% reporting having been physically assaulted—all because of their gender identity. 

    Spirit Day gives us a chance to support the LGBTQ community and show that we are against bullying. You can help out by wearing purple today and talking to your friends or young people in your life. As a mobile app developer though, you have special opportunity to help—by ensuring your apps are inclusive and perhaps even by creating an app to help youth at risk of bullying!

    4 days 14 hours ago

Pages