Github repository for my examples that combine React, TypeScript, and Semantic UI

A couple of weeks ago, I posted about how I’m porting a Flex app to JS/HTML/CSS. It’s a pretty complex app that I’ve been working on for a number of years, and it’s sure to require many months to complete. I know that I’ll learn a lot in the process, and I hope to share what I can.

Right now, it looks like my technology stack will be mainly React, TypeScript, and Semantic UI. Obviously, I’m sure to eventually pull in some additional libraries, like React Router for URL routing, but those first three are the basic foundation.

I recently created a semantic-ui-react-typescript-examples repository on Github. I wanted a place to store some of the smaller scale UI prototypes that I’m building while I figure everything out.

These examples use create-react-app, which is the easiest way to get started with React. Without create-react-app, you’d need to figure out all of your dependencies, learn how to build with Webpack, set up a dev server, and all sorts of other things that create-react-app does to help you get started. I used react-scripts-ts with create-react-app to use TypeScript instead of JavaScript.

I won’t go into detail about every example here, but let’s take a moment to look at the Todos example.

This one, in particular, shows many of the things that you’d expect to find in a framework/library that you’re evaluating when porting a Flex app.

  • It displays data in a list, and items can be dynamically added and removed from the data provider.

  • The items in the list are rendered with a custom component, similar to how lists in Flex support custom item renderers.

  • The number of items is displayed as text, and it gets updated dynamically. This is similar to Flex’s data binding feature.

Right now, you’ll find five examples in this repository. Mostly I’ve been trying out some layouts, but my most recent example hooks up React Router to some tabs to support browser history with the back button. I still have a lot to explore, so I’m sure that I’ll be filling this repository with more examples in the future.

I’m migrating a web application from Apache Flex, Adobe Flash Player, and Adobe AIR to JS/HTML/CSS

For almost ten years, I’ve worked on one of my side projects, an app named Logicly. It’s an educational tool for teaching computer architecture and digital logic. It started out as a little SWF demo on my blog that I built because I remembered one of my professors in college wishing for a better way to demonstrate how logic gates work. He had been using some random Java applet that he found on the web, and he was looking for something with drag and drop and more bells and whistles. Eventually, I realized that there was enough interest in this basic version of this logic gate simulator that I had made for fun, and I could actually make it into a real product for students, teachers, and schools. Today, Logicly is used in classrooms around the world, and it earns me a modest supplementary income.

Logicly is currently built with Apache Flex and Adobe AIR. It also has an online demo that runs on Adobe Flash Player that you can try in your browser. With the official end-of-life for Flash Player approaching in 2020, it’s time to migrate Logicly to something else. While I could continue to provide Logicly as an Adobe AIR application beyond 2020 (and even if Adobe decides to discontinue AIR too, captive runtime could keep it going much longer), there are good reasons to go with some other technology for Logicly.

  • The online demo is the best way for potential customers to try Logicly. There’s nothing to install, and they don’t need to leave their web browser. I could get by with only the free trial download, but I’d rather avoid adding any extra friction in the process, if I don’t need to.

  • If I switch to Electron instead of Adobe AIR, I can bring back a Linux version of Logicly. Adobe discontinued Linux support for AIR after version 2.6, and unfortunately, that forced me to leave behind my Linux users. There weren’t a ton, but I’d still like to support them! If I can move to JavaScript/HTML/CSS, I can package the desktop app with Electron, and I’m no longer limited only to Windows and macOS.

With my goal to provide an Electron application for desktop and an online demo that continues to run in the browser, I now need to look into my options for which language to use and the libraries and frameworks necessary to build my application.

FlexJS?

First, let me get this out of the way: Even though Logicly was originally built with Flex, I won’t be using Apache FlexJS.

Over the last couple of years, I put in hundreds of hours contributing to FlexJS and promoting it. I believe ActionScript and MXML are wonderful languages that could have evolved and thrived on the web without being tied to a browser plug-in.

However, considering everything I put into it, I’ve reached a point where this work only makes me feel tired. With my other projects, like Feathers, I get these boosts of motivation and endurance as I see people build cool projects and push things beyond where I ever imagined. That’s what keeps me going for the long haul! With FlexJS, I don’t really get that feeling anymore, so I think that means that it’s time for me to move on.

It’s been quite an experience, though, and I learned a ton about compilers, video editing, marketing, and more. I wish my fellow contributors well on their continued journey!

Language

TypeScript is the obvious language choice in my mind. It’s very similar to ActionScript because it takes JavaScript classes and lets you add proper typing to variables. I’m certainly more than capable of writing pure JavaScript, but I’d rather take advantage of the benefits that come from the compiler watching for type errors and the extra features that IDEs can more consistently offer when they have access to type information.

TypeScript and JavaScript now also have a lot of interesting, useful language features that ActionScript doesn’t have, and it’ll be fun to play around with those. Type inference, async/await, the let keyword for proper block-level scope, and arrow functions to propagate this are among my favorites.

I’ve looked at other compile-to-JS languages, like Dart or Haxe. They’re perfectly good languages, but as I was trying them out, they didn’t have the right feel to me. Everyone has their own preferences, of course. Someone else might prefer one of those instead, or even one of the new functional languages that are gaining some traction, and that’s okay too. For me, TypeScript came out on top because it felt the most natural to me when I was using it. Just the right balance between ActionScript and JavaScript.

Framework

I’m heavily leaning toward using React. JSX reminds me a lot of working with MXML, but instead of code embedded inside XML, it’s XML embeded inside code. Having everything be a component in React is very similar to how I built apps in Flex. Things aren’t exactly the same, of course, but React is the first JavaScript framework I’ve used where I was reminded of the kind of productivity that I had with Flex.

This is only half of the UI story, though. I find it interesting how the popular frameworks in JavaScript (like React and Angular) are called UI frameworks, but they don’t actually come with any UI controls. In part, it’s because HTML has some of its own UI controls built in. However, native HTML is severely lacking in anything beyond some very simple basics. It’s somewhat difficult to find a comprehensive UI control library that’s as robust as Flex. Many, like Bootstrap, seem to be geared toward app-ish websites and not full-fledged web applications, so they can be somewhat limiting.

UI Controls

I’ve looked at many UI libraries for JS/HTML/CSS. A lot of them don’t offer the vast number of UI controls and layout options that I want in my toolbox. Here are some of the better options, in my opinion. I’ve tried to focus on libraries that aren’t tied to a specific framework, but will integrate well.

If you don’t need a ton of UI controls, and want something that’s well-supported and widely regarded, the latest version of Bootstrap is pretty nice. While I called out Bootstrap above for not having everything I need, it’s still very easy to use and it’s popularity means that you can find a ton of useful, real-world information on the web. Finally, since Bootstrap components are created directly in HTML, they should work well with React and other frameworks.

If you like the polish of Google’s Material Design aesthetic, Material Design Lite (MDL) is a good option. In a personal project, I found that it works pretty well with React, but it does some dynamic DOM manipulation that can make it tricky for some advanced customization. If you’re using React or another framework, I’d recommend looking at MDL’s successor, Material Components for the Web. Think of MDC as version 2.0 of MDL, with special consideration for frameworks like React, more UI controls, and a better architecture. It’s still undergoing some evolution, so you might hit the occasional breaking change, but I think they’re getting very close to finalizing things.

One thing with any Material Design library is that they’re definitely going to fit in best on Google platforms, like Android. Personally, I think Material Design works just fine on iOS too, and most people are used to seeing Material Design on Google’s web properties, regardless of platform. However, I know not everyone has that same opinion. For my app, I’d prefer something that doesn’t lean to heavily in the direction of any particular platform. It shouldn’t feel out of place, but it also shouldn’t look like it belongs more on Android than iOS (or vice versa).

ExtJS has been around for years, and it has a ton of components and layouts. Even though it’s technically an older UI library, I think that it has been evolving with the times pretty well. For instance, you can use ExtJS with React thanks to their new ExtReact library. ExtJS is extremely expensive for a solo developer like me, though. They’re clearly going after the deep pockets of enterprise market. I would have seriously considered this option, if the price were more reasonable. I don’t mind paying for quality.

Most recently, I’ve been looking at Semantic UI. This library reminds me a lot of Bootstrap, but with more components and more variations of individual components. I’ve been playing around with the React version of Semantic UI for a few days, and I’m really enjoying it. I haven’t found myself getting stuck at all (just a few minor delays where I need to figure out exactly which component to use in some situations). This one is definitely a contender.

Another UI control library that I haven’t tried yet, but I think is worth mentioning is Ant Design. This is another React library, and it seems to have even more components than Semantic UI.

More to come!

I’ve started putting together these pieces to see what feels most natural to me. I’m building little prototypes, and I’m going to share some of my code in the near future. I’ll write a little bit about each of my small prototype projects here, with links to Github.

A look at the architecture changes in Feathers 3.0.0

Over three years ago, I released Feathers 1.0, targeting Starling 1.3. Today, I release Feathers 3.0 targeting Starling 2. It’s been an amazing experience to work hard and improve an open source project every day with the enthusiastic support of both Adobe and the wonderful Starling community.

As a new major release, Feathers 3.0 gave me the opportunity to re-imagine part of the Feathers architecture, based on feedback from developers who use Feathers in their apps and from my own experiences building new components. Let me point out a few of those architecture changes and the reasons why I made them.

Shared Constants

Way back in 1.0, I should have moved shared constants into their own classes. Instead, with each new version of Feathers, duplicate constants like HORIZONTAL_ALIGN_LEFT, SCROLL_POLICY_ON, and others repeatedly appeared throughout the Feathers codebase. I now realize that a single place to find HorizontalAlign.LEFT and ScrollPolicy.ON would have been better, and this is one of the things I cleaned up in Feathers 3.0.

When I started developing these components, I defined constants on the classes that used them because it seemed very convenient. If you needed to use a constant with the Slider class, you’d find it… on the Slider class! At the time, Feathers didn’t use many subclasses, and it had only a handful of components and layouts. I didn’t fully realize that defining constants like this wouldn’t scale very well as Feathers grew much larger over time.

By the time I started developing Feathers 2.0, I got frustrated as I saw myself duplicating constants in subclasses (so that developers wouldn’t need to know the inheritance hierarchy to find them), and I sometimes forgot to do it when new constants were added to the base classes. It was clear that things were getting a little messy in ways that I did not foresee. However, I worried that making this change would be too disruptive at the time, with the big theme changes that were included in Feathers 2.0, so the constants stayed as-is.

As I started working on Feathers 3.0 this year, I decided that this change finally needed to happen. It would indeed be disruptive, but the duplication and its side effects were getting out of hand. Using shared constant classes like VerticalAlign, RelativePosition, and Direction would be way easier for me to maintain going forward with a smaller learning curve and fewer bugs. I really wish I had made this change three years ago, but if I had waited for everything to be perfect, 1.0 would never have been released.

I’ve done my best to ease the pain of this migration. The old constants still exist, and they will not be removed until at least 18 months from now or until the next major version (whichever takes longer). Take your time switching over, and don’t feel like it must happen immediately when you upgrade. Be sure to try out the regular expressions in the Feathers 3.0 Migration Guide. You can use them with your editor’s Find/Replace feature to quickly swap out the old constants with the new. I used them on the example themes, and it was so much faster than doing the replacements manually.

saveMeasurements()

When a Feathers component’s width or height is not set explicitly, it needs to calculate appropriate dimensions during validation. Usually, this calculation is based on the dimensions of its skins and sub-components. Custom component developers will be familiar with the old setSizeInternal() method that was used to commit the calculated dimensions. This method has been deprecated and replaced with one named saveMeasurements() that accepts width and height the same as before, but also minimum dimensions as well.

Previously, the minWidth and minHeight properties defaulted to 0, and you could change them manually. However, in many layouts, the minimum dimensions may be used as a fallback. For instance, in a VerticalLayout where percentWidth is specified on children, their minWidth values of those children may be used as a fallback when the parent container’s width is not set. In previous versions, 0 would be used, which wasn’t always ideal.

Now, all core Feathers components calculate their minWidth and minHeight when needed. Custom component developers are encouraged to do the same.

As a bonus, this change helped me discover me some places where I could optimize Feathers by avoiding validation when it wasn’t necessary. This leaves Feathers in a better place for new, more advanced components that may be coming in future versions.

feathers-compat

As Feathers evolves, some APIs are inevitably deprecated and, eventually, removed. For instance, Feathers 3.0 includes a new class named ImageSkin that replaces an “advanced” class named SmartDisplayObjectValueSelector that was more cumbersome to use. Both optimize skinning by reusing the same display object with multiple textures, but ImageSKin does it in a better way.

It would be better if developers did not use SmartDisplayObjectValueSelector anymore, and I’d like to remove it from Feathers. However, existing code doesn’t rewrite itself, so developers may want to continue using this class for a while and still benefit from the bug fixes in Feathers 3.0. That’s where feathers-compat comes into play. Classes like SmartDisplayObjectValueSelector can be moved into feathers-compat so that they’re still available, if needed.

If you’re upgrading an app built with an earlier version of Feathers, and you find that some classes are missing, be sure to check if they’re included in feathers-compat.

New components on the way!

Feathers now has a stronger foundation that has been re-enforced with these architecture improvements (not just in Feathers, but in Starling too!). Starting with version 3.1 and beyond, I can start adding new and more advanced components. Stay tuned for news on what I have planned!

Also, thank you again to the community for your support, bug reports, and feedback. With your help, Feathers is better than it ever could have been if I were developing it alone. Happy coding!