In this article, I will cover how we can deploy the same Angular application image but use a different configuration for each environment. Before we start, however, let’s review what we mean when we talk about “continuous delivery.”
Continue reading “Handling Angular environments in continuous delivery with Red Hat OpenShift”
In the previous article, we took a quick look at a new source-to-image (S2I) builder image designed for building and deploying modern web applications on OpenShift. While the last article was focused on getting your app deployed quickly, this article will look at how to use the S2I image as a “pure” builder image and combine it with an OpenShift chained build.
Continue reading “Modern web applications on OpenShift: Part 2 — Using chained builds”
In this multi-part series, we will take a look at how to deploy modern web applications, like React and Angular apps, to Red Hat OpenShift using a new source-to-image (S2I) builder image.
Series overview:
Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”
Web development has become increasingly complicated in recent years. The questions of which framework to use often can eat up much time at the start of a project. I can’t remember the number of times people have asked me while working on a Knockout project if I’ve heard of Durandal, or when considering Angular 2 – what about React/Flux or Aurelia?
Patternfly is a community project that promotes design commonality and improved user experience. Its offerings include open source code, patterns, style guides and an active community that helps support it all. But, this complexity, choosing web frameworks, also affects PatternFly. Our goal is “to build a UI framework for enterprise web applications”. That requires that we remain outside of the discussion of which framework is best and provide a solid set of patterns and designs for developers to rely on.
How can you build a UI framework when there are so many choices and so many strong feelings about the different choices? In my opinion, it’s important for developers to choose the framework that is best for the project and fits their skill set. There isn’t one choice that works for everybody and it’s important that we support all developers that want the benefit of well-designed components that can be used in enterprise applications.
Continue reading “Are “Web Components” in the future for PatternFly?”
I’m an avid follower of Hacker News and many various programming related subreddits. There is a constant flow of posts where the author expresses fatigue, weariness, and many times backlash at JavaScript and the plethora of front-end frameworks. Much of this conversation surrounds React and Angular and then other frameworks such as Mithirl, Meteor, Ember, Vue and others (and there are many others). The conversation many times will go X is the best framework, or X is not the best framework Y is, and the reasons, or much consternation that X or Y is short lived and will be superseded soon by Z. Then many times it is just complaining about X, Y, Z, and frameworks and JavaScript in general.
I’d like to offer a few thoughts counter to this outcry of fatigue in the industry.
What if you viewed the churn and the constant creation of frameworks and libraries as a positive growth factor. What if you viewed the JavaScript ecosystem as parallel to the machine learning ecosystem.
Continue reading “Angular, React, and Javascript framework fatigue”
