In light of the recent COVID-19 pandemic - OPTASY would like to offer DRUPAL website support for any Health Care, Government, Education and Non-Profit Organization(s) with critical crisis communication websites or organizations directly providing relief. Stay Safe and Stay Well.

When it is okey to use TypeScript?

When it is okey to use TypeScript?

by Adrian Ababei on Mar 28 2016

Last summer we had to convert a huge code base from Javascript to Typescript. During this transition I learned a lot about the differences and similarities of the two. I developed an idea about what makes a good use case for Typescript and when it doesn’t make sense to use it.

Use cases for Typescript

1. Code size: When the source code is huge and more than one person works on the project, a type system can help avoid the obvious errors. This is specially true for SPAs. When someone can change code that potentially breaks another one’s code, it’s generally good to have some sort of safety mechanism. The TS transpiler reveals the obvious mistakes and is kinda smart (but can’t eliminate the need for debugging of course). If the source code is not huge, it probably doesn’t make sense to make it longer by adding type annotations. I have converted 180+ files from JS to TS and in most cases it added roughly 30% to the code size. 2. Previous baggage: if you or the majority of the team come from a strongly typed language like C# and does’t really want to go JS all the way, TS is a good alternative. Even though I recommend learning Javascript for good, there’s nothing preventing you from using Typescript without knowing Javascript. In fact Typescript is made by the same guy who made C# so the syntaxes are similar. In my company we had a team of C# developers who were coding a sophisticated desktop application in C#/WPF (which is front end in the desktop world) and then they were tasked to join my web project as full stack. So it was relatively a shorter path for them to learn Typescript for front end and leverage their C# knowledge for the backend. 3. As a replacement for Babel: The old Microsoft used to take something that is standard (for example Java) and add proprietary non-standard stuff to it (for example J++) and try to force developers pick one. Typescript is exactly the same thing to Javascript (after another try in 1996 divertingJScript from Javascript). Anyway, since ES6 is basically a subset of Typescript and the Typescript transpiler generates ES5 code, it’s practically possible to transpile ES6 code to ES5 (just as Babel) using the typescript transpiler. Though it’s not a strong use case IMHO. Typescript’s transpiler generates pretty readable ES5 code as output and that was one of the reasons Angular 2 team chose TS over Google’s own Dart language. 4. Promoted by lib/Framework: If you are using Angular 2 or another library that makes it particularly interesting to use Typescript, go for it. Just know that even though Typescript can use all Javascript libraries out of the box, if you want good syntax errors, you need to add the type definitions for those libraries externally. Fortunately the nice guys atDefinitelyTyped have made a community driven repo and tooling for that. But that is one extra step when you’re setting up your project (side note: for the JSX fans I should mention TSX).

When you’re better off without Typescript?

1. Extra transpilation tax: There are no plans to support Typescript natively in the browsers (Chrome did some experiment but cancelled later). This means you will always have to transpile your TS code before running it on the browser. For the standard ES6 it’s a whole different story. When ES6 is supported by most browsers, the current ES6 to ES5 transpilation would be unnecessary. ES6 is the biggest change in the language and I suspect most people would settle there, but those who want to try the experimental features of the next version of the language will transpile anyway. You just modify the file and refresh the browser. That’s all — no “watching” or “transpiling on demand” or build system is necessary. If you choose TS, you probably end up doing some extra book keeping for the keeping the type definitions for Javascript library/frameworks up to date (using Definitely typed or writing your own type annotations). That’s something you wouldn’t do for pure JS projects. 2. Weird debugging edge cases: Sourcemaps make it easier to debug Typescript, but the status quo is not perfect and there are really annoying/confusing edge cases that the browser thinks you are running a certain line of code but you are not. Also there are some problems debugging the `this` keyword and properties attached to it (hint: `_this`works in most cases). That is because Sourcemaps currently don’t have a good support for variables (but that might change in the future). 3. Performance penalty: in our project we had 9000+ lines of ES5 Javascript that delivered pure horse power for a WebGL component but we kept it that way. Typescript transpiler (just like Babel), has features and generates code that no matter how good the transpiler is, can’t surpass the optimisations of a good programmer. So we decided to keep it in plain ES5 for ease of debug and deployment (no transpilation whatsoever). That being said, the performance penalty probably is negligible compared to benefits of a type system and more modern syntax for most projects, but there are cases that milliseconds and microseconds matter and in those cases transpilation of any kind is not recommended (even Babel, CoffeeScript, Dart, etc.). That being said, Typescript doesn’t add any extra code for runtime type checking. All the type checking happens at transpile time and the type annotations are removed in the generated Javascript code. 4. Agility: it’s quicker to set up something in Javascript. The lack of type system makes it super agile and easy to change stuff. Sure you can break things easily but if you know what you’re doing, Javascript is more flexible. Remember one of the main use cases for using a type system is to make it hard to break stuff. If Typescript is Windows, Javascript is Linux. In JS land you don’t get the “helper wheels” of a type system and you’re assumed to know what you’re doing but you can ride faster and maneuver easier. Particularly if you’re in the prototyping phase, don’t waste your time with Typescript because JS is simply more agile and flexible. That being said, if you use a typed language, it might be quicker to write/modify code in an IDE because the type system makes it easier to determine syntax. Source: https://medium.com

Development

We do Web development

Go to our Web development page!

Visit page!

Recommended Stories

5 Drupal Blog Posts That Have Made It to the Favorites Lists of All the OPTASY Team Members this Month
This month's "surreal" events have shaken the world as we had known it. They have "closed" us safely inside our homes, stopped us from doing many of what we had considered as "ordinary" activities, but it hasn't stopped us from... reading. And Drupal blog posts are always on our reading lists. We've recently compared our lists of favorites, put together OPTASY's monthly selection, which includes those Drupal articles that most of our team members found valuable, and... we're now ready to share it with you. Here they are: OPTASY's top 5 favorite Drupal tutorials, guides and insights in March.   1. Getting Started with the Gutenberg Editor in Drupal We, too, have recently shone some light on the Gutenberg module for Drupal 8, one of the latest layout tools added to Drupal's toolbox.  A tool aimed at improving the editing experience in Drupal. While doing our research, we “bumped into” this blog post. And it quickly became one of the team's favorite Drupal blog posts of the month since:   it's concise and to the point it's neatly structured it includes all the information that anyone interested in taking this Drupal page builder for a “spin” could possibly need From:   installation to configuration to the final step, where you use the Gutenberg Editor to publish content on your Drupal landing page   … the blog post takes you through all the steps you need to take to get yourself familiarized with using this site building tool. Source: Opensource.comNote: we loved that the Opensource team insisted on highlighting those Gutenberg features that are specific to the Drupal integration only (you won't find them in the WordPress plugin):   granular permission placeholder content the possibility to add Drupal blocks inline 2. Drupal Website Accessibility in Review: Key Features & Useful Modules “How to implement web accessibility?” “How do I make my website WCAG compliant?” Any responsible Drupal website owner asks himself this kind of questions these days. No one wants to risk getting sued for having underestimated the importance of color contrast. Or the importance of displaying web forms that can be easily filled in by all the website visitors. But what if your CMS helped you check off most of the recommendations on the W3C accessibility checklist by... default? This is what Drupal 8 helps you with.  And this is what the Wishdesk team's post, one of the best Drupal blog posts in March, is all about. It makes a useful inventory of Drupal's built-in accessibility features and contributed accessibility modules. “What makes Drupal 8 accessible out of the box and easily extendable, helping you reach even the “nice to have” accessibility levels on your website?” The post has all the answers to your question. Source: WishDesk.com It outlines all of Drupal's built-in features for accessibility:   the accessible inline form errors the shiny and new Olivero front-end theme the ALT text for images required by default in Drupal 8 ...   Then, it covers the key contributed modules that you could enable to further boost your website's level of accessibility: CKEditor Abbreviation, Siteimprove, Automatic Alternative Text, HTML Purifier, etc. A useful checklist to keep at hand whenever we add or improve accessibility on our clients' Drupal websites. 3. Using Drupal in a Pandemic, One of Our Top Favorite Drupal Blog Posts The Lullabot team stroke again. Just that this time it wasn't a valuable Drupal tutorial/technical guide that they put together, but a list of Drupal mindsets that we can all apply in the context of the COVID-19 pandemic. And the similes that they found and pinpointed are just fantastically... appropriate. Here are just some examples:   3.1. As Drupal contributors, we've come to learn that we can also help the community by stepping back and letting other contributors step forward. Likewise, we can still join the fight against COVID-19 by simply... staying home.Source: Lullabot.com   3.2. Over time, we've learned that by “getting off the Drupal island” and partnering with other communities we could help push Drupal forward. Likewise, these days we need to step out off our own circles of needs and put our skills and technical knowledge to work for others in need. Or for those who are directly involved in providing relief.   3.3. “Community” is the best term for defining Drupal. It's a community of contributors working together and not a community of individualistic “rock stars” contributing, each, merely for his/her own fame and gratification. Likewise, there's no way that we can fight this pandemic by being selfish and egocentric. We need to join forces. To join the global community of people who're applying the “social distancing” measures. It's something that we can all do and that we can all benefit from.   And these are but some of the Drupal-specific principles that the Lullabot team managed to turn into clear responses to the crisis that we're living. We invite you to discover their other Drupal lessons that you, too, can easily turn healthy mindsets these days.   4. Set Up Product Attributes in Drupal Easily & Boost Online Sales A useful step-by-step tutorial on how to set up product attributes on a Drupal Commerce website. Why has it made it to our list of favorite Drupal blog posts of the month?   because it tackles an all too common “To do” on the lists of our Drupal projects: setting up product attributes properly, in a way that's easy to manage by the site admins/editors and easy to scan through and to select from for the end-user because it's clearly written, with lots of helpful print screens and a logic structure    In short: it's an honest tutorial, written in a clear and accessible style, that shows you exactly how to set up product attributes in your online Drupal store. From the point where you add a new product attribute, all the way to the final step, where you connect that attribute to the specific product variation type on your e-commerce website. Source: Druedesk.com   5. Concurrent Editing in Drupal 8: Possible or Not?   “How do you implement concurrent editing in Drupal? Is there a solution for it already in Drupal core?” This is the question that the QED42 team asked themselves when they faced the challenge of setting up a system where multiple content creators could access and edit, simultaneously, yet independently, layouts and widgets in a Drupal app. Source: QED42.com And it's this problem, that they had to find an answer to while working on their project, that made them share their findings in the form of a useful blog post. A post that brings forward 3 modules that the team evaluated as possible solutions for concurrent editing in Drupal:   Paragraph Frontend UI Conflict Content Lock   What makes it set itself apart from other Drupal blog posts that we've read in March?   it's focused on a real Drupal limitation ... one that many Drupal teams struggle to find an answer to while working on their clients' projects: how to enable distributed editorial teams to edit content simultaneously, with zero conflicts that might arise from their concurrent actions it presents multiple possible Drupal solutions to it, each one with its strengths and weaknesses it shares their own custom solution to this Drupal shortcoming: turning the widget creation into a decoupled, separate node, and referring all those widget nodes into the Layouts   Useful, usable, relatable. In short, it's a Drupal blog post valuable enough to add it to our own resources list.   The END! Your turn now:  How does your own list of March favorites look like? What valuable Drupal guides, tutorials, and insights have you run into this month?Photo by Annie Spratt on Unsplash ... Read more
Adriana Cacoveanu / Mar 31'2020
You Have Your List of Web Accessibility Issues: What Do You Fix First? 8 Simple Ways to Prioritize Accessibility Problems
You've run your audit, you've got your list of web accessibility issues: now what? Where do you start? Before you get to the point where you ask yourself “How do I fix web accessibility issues on my site?” you wonder: “Which issue to address first?” How do you prioritize accessibility problems? By noticeability, by severity or by tractability? What criteria do you use? And this is the question that this post will answer to. It's a list of 8 simple ways to prioritize the issues included in your accessibility audit report:   If Your Website's Image-Heavy, ALT Text Becomes a Priority If You Host Lots of Videos, Adding Captions Is Critical Let the Data on Your Target Audience Dictate Your Priorities If the Issue Is Repetitive for Screen Readers, Then It's High Priority Put on Your List of Web Accessibility Those that Impact the User Navigation  Prioritize the Issues that Prevent Users from Submitting Forms Prioritize The Accessibility Issues Detected on Key Pages of Your Site Prioritize Low Complexity, but High-Value Issues 1. If Your Website's Image-Heavy, ALT Text Becomes a Priority Do you have lots of images on your website? Then adding ALT text is a top priority, by default. 2. If You Host Lots of Videos, Adding Captions Is Critical Do you have lots of video content on your site? Then adding captions should be one of the first tasks to carry out after you've run your web accessibility audit.    3. Let the Data on Your Target Audience Dictate Your Priorities Customer analytics should be the main criteria to use when you put together a list of web accessibility issues. How many people in your customer base use screen magnifiers to zoom in specific sections on your website? Are there users depending on screen readers in order to interact with your website?  What does the analytics data tell you?  It's those stats that determine how you should prioritize your usability problems. And how you should design your website accessibility plan. Source: Medium.com In this case, categorizing (and therefore prioritizing) web accessibility issues by their WCAG level (A, AA, AAA) is a bit rudimentary. The data that you have on your user target group might reveal to you that complying with certain AA (or “nice to have”) standards is more important for your audience than complying with some A standards... In short: start with those issues that have a direct impact on your specific customer base. 4. If The Issue Is Repetitive for Screen Readers, Then It's High Priority Take an issue listed in the W3C accessibility checklist as common as... link names. It says there that the displayed text should be unique, meaningful and descriptive enough. Has your automated accessibility testing tool identified multiple instances of this issue? Do they seem to be so repetitive that the experience of any website visitor using a screen reader is just... terrible? Then you should address them ASAP.   5. Put on Your List of Web Accessibility Issues Those that Impact the User Navigation  You've run your web accessibility audit and now you need to prioritize the issues detected. An effective criterion to use for setting up a hierarchy of “errors” is the impact that those issues have on users' navigation experience. For, if those issues prevent users who depend on assistive technologies from navigating your website, they'll get discouraged/frustrated. And leave your site. For instance, your accessibility audit might detect a problematic heading structure. Which, by the way, falls into the AA category. If that heading structure:   skips certain levels or, even worse, there is no heading structure at all or it contains too much irrelevant information   … and is the main “culprit” for the poor navigation experience on your website, then you should make it a priority.   6. Prioritize the Issues that Prevent Users from Submitting Forms For there's nothing that says “I don't care about you” like web accessibility issues that stop users from filling in a form on your site. In short, make sure you tackle those first. I'm talking here about usability issues like:   unhelpful error text messages like “please enter correct information” unaccessible inline error messages   … that make it impossible for these website visitors to submit any form.   7. Prioritize the Web Accessibility Issues Identified on Key Pages  Build your web accessibility test plan around the most important pages on your website. Source: support.siteimprove.com For instance, optimizing a page with a Help article isn't a top priority.  But optimizing for accessibility your:   Product page Login page Checkout page User Registration page Contact Us page Feedback or Survey page   … should be listed among your top priorities. Tip: a common web accessibility mistake is to ask people with disabilities to enter information from their paper receipts on the survey page.  Make sure this problem is among the first ones that you address. So, before you go ahead and add problems to your top list of web accessibility issues, you might want to ask yourself some key questions:   “What's the scope of the page presenting accessibility issues?” “What's the traffic on the page that you're about to optimize?”   8. Prioritize Low Complexity, but High-Value Issues And now you have your answer to the question: “What if I have a high-value issue, but with low complexity like... defining page titles for dynamic pages on my website?” Final Word: Internal Prioritization Is Crucial  Putting together a list of web accessibility issues to tackle first depends on your website's:   audience content functionality   Sticking to an “A level vs AA level” technique for figuring out what problems to fix first is... a bit too simplistic. For even not all A-level accessibility standards are of equal importance and not all AA-level issues are just “nice to haves”: Source: www.w3.org Your turn now: What criteria do you use to prioritize the accesilbity issues that you identify on your website? Are there other prioritization techniques that I should add to this list? Let me know in the comments below.Image by Gerd Altmann from Pixabay   ... Read more
Adriana Cacoveanu / Mar 27'2020
What Are the 10 Rules of Good UI Design? What Is Good UI/UX Design?
In this post, I'll share with you the top 10 rules of good UI design. You will be learning:   What are the essential elements of a good UI design What are the most common UI/UX mistakes that designers make What are the UI best practices in 2020 Lots more UI design tips   Now, let's get started.   1. Aim at an Almost Invisible User Interface  What is a good UI design? A logical structure & necessary visual elements only. In other words, in order to design an almost invisible user interface you need to:   be “merciless” and keep the essential elements only base your UI on a well-thought-out structure use clear language in your text messages and on your labels   Source: Medium.com A poorly structured and cluttered UI would only make the user ask questions like: “Where's the main menu?”   2. Keep It Consistent And this is one of those good UI design principles that's overlooked or undermined most often. Consistency should span over the entire ecosystem of elements that make up a UI design: fonts, colors, menus, buttons, icons. Keeping a consistent UI throughout your website translates into creating patterns aimed at enhancing efficiency. At improving the user experience. And here I'm referring to layout, design, language patterns. Once the user gets familiar with a given pattern, it will be easier for him/her to interact with other parts of your website that present the same pattern.   3. Be Purposeful with Page Layout One of the fundamental rules of good UI design is to structure your pages based on importance. In this respect, here are the crucial principles of user interface design to guide your page layout creation:   take into account the spacial relationships between various elements on the page place your UI elements strategically: draw users' attention to the most important information on the page and make it easy for them to scan it through  keep in mind that “form follows function”: design each item in accordance to its function (no need to reinvent the wheel and to turn the hamburger menu into a... sandwich menu, for instance) stay away from clutter, at all cost: keep the visual elements on the page to a minimum make smart use of headings, group similar elements together, add numbered items, as well, all in the name of readability    IMAGE Image by 200 Degrees from Pixabay     4. Use Color and Texture Strategically Make smart use of color, texture, contrast, and light to direct the user's attention to key elements and important information on the screen.   5. Use Familiar UI Elements: One of the Key Rules of Good UI Design One of the UI best practices that's both:   the easiest to implement the most underestimated   And it all comes down to intuitive design. To sticking to common elements when creating your user interface.  Again, the hamburger menu makes the best example: once spotted, the user knows what it is and how to open it. Restrain yourself from showing off your creativity as a web designer. From being "discouragingly" innovative. Form should follow function, remember?Instead of impressing your users, you should help them get things done quickly and easily. That's what delivering a good user experience is all about, after all.   6. Put the User in Control of the UI Instilling a sense of control in the user is one of the most powerful UI design principles. Source: xd.adobe.com In this respect, here are some specific measures that you can implement:   6.1. Provide enough context  Ensure that the user knows, at each stage of his journey on your website, where he is, where he's been, and where he could go next. Tip: place visual cues to help the user develop a sense of mastery and control.   6.2. Be transparent about the system status Another one of those golden rules of good UI design: Let the user know, at all times, what's the status of the process that he's initiated. For instance, he/she might have started an action that requires some time for the computer to carry out. In this case, make sure you provide feedback, at regular intervals, about the system status, about what's going on.   6.3. Make actions reversible In other words, allow users to:   unselect undo their last actions restart whatever processes that they've engaged in   6.4. Design your UI with all user skill levels in mind And this is one of the most obvious characteristics of a good UI design. It's an easy to use interface for both casual and expert-level users.   6.5. Provide feedback on every user action It's more than a good UI best practice: it's a matter of... good manners to provide at least some sort of feedback at each point of action. Therefore, make sure your system delivers a meaningful reaction each time a user:   clicks on a menu hits a button clicks on a text message tab   Let the user know, using specific UI elements — animations, progress bars, pop-up windows, color change — whether he's successfully carried out the action or not.   7. Minimize Cognitive Load: Recognition over Recall “Task-relevant information only” should be one of your key rules of good UI design. And sticking to a limited number of elements within the display aligns with the very limits that the human attention, itself, imposes. In this respect, it's human nature that your users prefer to recognize information across a sequence of screens rather than to strive and recall it from their memory. For instance, our cognitive load is always lighter when we're challenged to answer multiple-choice questions compared to having to tackle short answer questions.   8. Stick to One Primary Action per Screen And here, we go back to the “visual declutter” principle again: Make sure that each screen supports just one single main action. Squeezing too much information on the same screen and requesting the user to carry out more than one primary action will just:   confuse him/her distract him lead to attention overload  9. Use Typography to Create Visual Hierarchy Most likely one of the easiest to follow rules of good UI design. Strategically use different font sizes and display text to enhance:   readability scanability legibility   Photo by Alice Donovan Rouse on Unsplash    10. Stick to a Small Number of Gestures Gesturing, swiping, tapping, pressing... no need to “squeeze” all these user actions into your app. Keep them to a minimum. Tip: Facebook and WhatsApp make some good UI design examples; their interfaces require a limited number of user gestures. Pro tip: make sure it's crystal clear to your users what gestures they need to perform in order to carry out certain actions on your interface. Source: Medium.com     The END! Now, I'm really curious to hear/read your thoughts:  How does your own list of must-follow rules of good UI design look like? Have I overlooked any key best practices? Let me know in the comments below.Image by FiveFlowersForFamilyFirst from Pixabay   ... Read more
Silviu Serdaru / Mar 17'2020