projekt202 Delivers Improved Experience for Global CEO Network

projekt202 Delivers Improved Experience for Global CEO Network

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.

projekt202’s UX-Defining Design System Maps Out Cohesive Digital Experience for Travel Tech Leader

projekt202’s UX-Defining Design System Maps Out Cohesive Digital Experience for Travel Tech Leader

A leading tech provider to the global travel industry recognized a visual disconnect in its product portfolio and a need to redesign its robust catalog of digital properties. The organization relied on projekt202 to map out and implement a successful new software strategy.

projekt202 podcast: How projekt202 Delivered the Full Omnichannel Experience for a $60 Billion Retailer

projekt202 podcast: How projekt202 Delivered the Full Omnichannel Experience for a $60 Billion Retailer

In this brand-new podcast, projekt202 Vice President of Technology Paul Tidwell describes how the projekt202 team worked within a tight timeframe to deliver an outstanding omnichannel experience for a $60 billion retailer.

ES Next: What Do I Need to Know?

By Joshua Kemmerling
Architect, projekt202

Joshua Kemmerling
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.

After features are accepted and officially added to a new version of ECMAScript, these features can begin to be added to JavaScript engines, which is when developers can get hold of them with an extra framework.

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

Because ES Next features have not been officially added to JavaScript engines, the only way to start utilizing these features are to use a transpiler to convert your ES Next code to a supported format that browsers accept. There are a bunch of transpilers out there, but I am only going to talk about a few different ones. All of these transpilers can easily be brought into your current workflow by using something like Grunt, Gulp or Webpack to have them generate your JavaScript.


Babel is a great compiler to get started with. It supports ES2015, ES2016, and features that are in Stage 1, Stage 2 and Stage 3. Babel even has an interactive shell that let’s you see what your ES Next code will compile to. Babel is my recommendation for people getting started with future features of JavaScript.


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?

I know it won’t be the popular opinion, but I don’t think we should start using ES Next quite yet. The reasons are pretty simple. Using a transpiler adds another step to the development process without any true benefit. I say that there isn’t any true benefit because these transpilers convert your code to the most recently-supported version of JavaScript. Plus, not all transpilers support the same ES Next features, meaning if you want to switch transpilers, you will most likely have to rewrite some of your ES Next code.

Stay up-to-date on projekt202 news by following us on LinkedIn, Twitter, Facebook,YouTube and Instagram.

Is React JS Good for the Web … Right Now?

By Joshua Kemmerling

New technologies for web developers are introduced all the time. Especially in the world JavaScript, it seems like there is something new every week, although recently very few things have been as popular as React. For anyone who doesn’t keep up with web technologies, ever since React was publicly released, there has been a large number of plugins, blog posts and other projects created using the framework, such as (or most famously…) example. Plus, at the time of this writing, React has over 21,000 stars and over 2,900 forks on the Github repo. But just because a new technology is popular doesn’t always mean it is the right choice for client projects.

To determine whether React is a good choice for projekt202, I needed a baseline to compare it against. That baseline is AngularJS. AngularJS is one of the most popular JavaScript frameworks out right now and we have grown fond of it here at projekt202 and have leveraged it to successfully deliver numerous projects for our clients. It packs a lot of features into a small space and allows us to make a high performance front-end app without needing to bring in extra files or frameworks.

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.