A global CEO platform needed to take its tech presence to the next level. projekt202 harnessed a full tech stack, UX/UI research and proven methodologies to improve the experience for 24,000+ customers.
By Joshua Kemmerling
ES Next is a term used to refer to future versions of ECMAScript that have not been released. Most of the features have been proposed but are not very close to being approved. Developers usually don’t try to learn any new features until they make it to Stage 3. When a feature makes it to Stage 3, it will eventually be approved and put into a future version of ECMAScript. You can find out more about ECMAScript stages here.
Who is Using ES Next?
There are a lot of projects currently taking advantage of these new features. Some of these are projects that you are probably already using and didn’t realize it. Some of the projects are, but are not limited to, Angular, React, Ember and Node.
How to Start Using ES Next
Traceur keeps good documentation on the Github repository, has a huge following, and was created and is maintained by a team at Google. You know who Google is, right?
esnext is easy to use when getting started and the website provides an editor to try out some test code, but it is mainly used as a compliment for Babel.
Should We Be Using ES Next Now?
By Joshua Kemmerling
Before we go too far, I want to point out one thing about React. We usually build front-end apps in following the MVC (Model-View-Controller) pattern. Most people use React as the V of MVC but I feel like it can be used as the VC of MVC. AngularJS is a MV* framework so it has functionality for all parts of a MVC app. React is missing the Model (M) of MVC, though a developer should be able to create their own solution or leverage an existing framework like Cortex to give them the Modeling functionality they need.
Routing – This is the very first thing that jumps out at me when I was looking at how useful React could be. React does not come with supported routing functionality out of the box. AngularJS on the other hand, comes with built-in routing that is supported by the AngularJS team. This isn’t that huge of a problem because a router is something that could be easily created or we could use a pre-created option like Director that already exist and works well.
AJAX – This was the second thing that initially jumped out at me when I started reading articles about React. There is not a built-in AJAX library of any kind. This isn’t totally a deal breaker since most front-end developers are familiar with jQuery , which offers robust AJAX support. But without built-in AJAX functionality, this also leaves the developer to choose how he/she wants to include AJAX features. AngularJS utilizes jQuery Lite so it has AJAX functionality built in requiring no additional effort to get connected to services.
Templating – Templating is a hard thing to compare because most developers have a preference when it comes to HTML templating so I am not going to go too deep into templating in this article. The reason I bring templating up is because AngularJS provides “filters” which extend the functionality of their templating engine to allow the developer to format the value in the template any way they would like. React takes a different approach to templating that is best understood by getting hands on with it. React templating will be a future article.
Size – We look at size all the time in front-end development from a performance standpoint because we don’t want it to take too long for files to load up when it isn’t necessary. AngularJS minified is downloaded at 126 Kb and React minified is downloaded at 121 Kb. Not a huge difference, but with a lack of features in React we tend to lean towards AngularJS as our framework of choice.
That’s it for now. There are some other features that differentiate the 2 frameworks such as two-way binding, localization, and dependency management that allow developers to build powerful, dynamic web apps. But those are topics for the next post about React. In my opinion, React has made some big strides with their approach to front-end development but I don’t think it is fully ready for us to use on client projects as of right now. We need features like routing and AJAX in a small package to be able to build robust applications. And because we hand the code base off to the client, we need well-documented frameworks that have a lot of support from the community. Neither of which we get from React. I do expect it to get better and more useful in the future. To read more about React and to get to know it better, visit their website and follow the React blog.