I'm a full-stack JavaScript developer, co-founder of a design and development agency in Germany and a maintainer of the open-source NoSQL document/graph database ArangoDB where I mostly work on the Foxx framework which lets you host JavaScript apps directly inside the database.
When I'm not procrastinating on Hashnode, HN, Twitter or IRC, I work for clients or on our commercial e-learning product, mostly using React, Node.js and ArangoDB.
Nothing here yet.
No blogs yet.
I started writing my first homepage in plain HTML in late 1995 at age 10 on a Windows 95 PC using Notepad. I fiddled with JavaScript when it landed in Netscape Navigator (so mostly playing with the status bar and mouseover image swaps) and taught myself PHP around 2000 (so around age 15). However I frequently went months and years without doing any programming until age 20-ish and only really started doing it professionally at age 25.
It depends. The main use of react helmet (not to be confused with express helmet for node.js) is server-side rendering. Even in an SPA you may want to do server-side rendering, in which case helmet will likely be useful. But if you're not doing any SSR, there's no point in using helmet. You don't want to render into the html <head> directly, instead you probably want to generate <style> elements when modifying CSS at runtime (e.g. using a library like styled-components which does this automatically) or you want to access the document.title directly. Everything else can likely be determined statically and added to your HTML before it is served to the browser. Helmet is also useful for dealing with meta tags used by social networks and search engine crawlers (i.e. SEO) but there's no guarantee those will reliably run the entire application before looking for these tags, so I wouldn't worry too much about this until you need server-side rendering.
Assuming you are using a <video> element rather than a third-party video player (which usually comes with its own APIs that they document) you probably want to track some of the events that element supports . Note that in React most events can be listened to using an on${eventName} prop, e.g. onEnded . Alternatively you can also use a ref to get access to the underlying DOM node and attach event listeners in your componentDidMount lifecycle method (make sure to remove them in componentWillUnmount to avoid memory leaks though). However in the case of watching a video it's difficult to say when a video has been "watched" because you first need to define what that means. If you define it as "the end of the video has been reached", then you can just skip to the end of the video and it will be tracked as "watched". So the usual metric is something like "has been playing for N consecutive seconds" (e.g. most social media platforms consider a video playing for 10 seconds as having been watched). Remember that this entirely depends on what is a good metric for your product. A good rule of thumb is something like "at least 80% of the duration of the video has been played in total" but note that this means viewers of a 100 second video can skip back and re-watch the same 10 second segment over and over again and still count as having "watched" that video if they do this 8 times although they've only viewed 10% of the entire video -- but these edge cases are usually not a real problem for most products.
if (cpfItems) { for ( const item of cpfItems) { ... } } Note that I'm using for-of because it's slightly explicit when you don't actually need the index itself and just want to iterate over the items. If you do want to do something with the indexes you should still use the for loop from your first example. As others have pointed out, for loops bail out if the array is empty, so there's no need to check for cpfItems.length to skip the loop. That said, in my own code I would probably extract whatever is going on here so I can just return early if cpfItems is undefined and avoid that layer of nesting.
If you have the money to spare (or your employer has a budget for this) I would recommend checking out Kent C Dodds' https://testingjavascript.com for a full course on testing React applications. The general idea is that while unit tests can be useful to nail down specifics, most of the time you want what would traditionally be considered integration or even end-to-end tests. Kent is the author of react-testing-library which the course also covers and makes it very easy to do high level testing of React apps. As a free resource on react-testing-library it might be worth looking at https://react-testing-examples.com.
Try upgrading create-react-app or using npx ( npx create-react-app ). If that doesn't help try nuking your npm cache ( npm cache clean ). The only relevant parts of the message you're seeing are the final two lines: npm has trouble finding @svgr/webpack in version 2.4.1 ( which definitely exists ). I would recommend checking the remainder of the output for any other mentions of that package. The other lines you pasted are just warnings because create-react-app uses dependencies that have fallen out of date and optional dependencies that are not supported by your platform. It also looks like you're using Windows. If you feel comfortable with Linux shells you might want to look into WSL. For beginners it can be a bit daunting but having spent a lot of time on Linux this was an eye-opener for me: https://daverupert.com/2018/04/developing-on-windows-with-wsl-and-visual-studio-code/
That's a pretty odd question. TypeScript is a superset of JavaScript. All valid JavaScript is syntactically valid TypeScript (though TypeScript may be stricter about type conversions). The goal of TypeScript is to add type semantics to JavaScript, aside from type-related features like interfaces and type aliases most syntax additions are either based on features recently introduced to JavaScript or features proposed to be added to the language (enums may be an exception to that though). The main use of CoffeeScript is to allow Ruby programmers to avoid JavaScript. The goal of CoffeeScript was to create an alternative syntax for JavaScript that is more familiar to Python and Ruby developers and that takes away some of the traps of JavaScript and add some syntactic sugar that didn't exist in JavaScript at the time. For most purposes, CoffeeScript has been superseded by modern JavaScript (which now includes features like classes and arrow functions), which has led to many people moving from CoffeeScript to plain JavaScript. TypeScript on the other hand continues to provide benefits on top of JavaScript even as some of the experimental syntax features implemented in TypeScript become part of JavaScript itself. JavaScript won't have a type system like TypeScript's for the foreseeable future, so TypeScript will continue to be beneficial to developers looking for a little more compile time type safety in their JS. As an alternative to TypeScript consider Flow, which defines itself as an addition to JS rather than an extension of it and has a slightly different philosophy to its type system but otherwise is very similar in purpose and use to TypeScript. As an alternative to CoffeeScript consider other alternative JS based languages like LiveScript.
Personally I really like Monokai Dark Soda: https://marketplace.visualstudio.com/items?itemName=AdamCaviness.theme-monokai-dark-soda I'm partially colorblind and have been told it's a bit garish but the contrasts just work great for me.
A lot of answers are pretty good but miss the core of the question: why did we end up with JS specifically? Originally there was only HTML. The arrival of JS even pre-dates that of CSS, to the extent that at some point there were actual plans to create a styling language based on JS (JSSS = JavaScript Style Sheets, not to be confused with JSS which is a recent styling library for JS). The history of JS has been explored in great detail elsewhere but the important takeaways are that back when "the web" was split between Netscape and Microsoft, Netscape wanted to create a scripting language for web pages around the same time Sun tried to establish Java as the universal language for writing real applications. At the time "build cross-platform applications" and "breathe life into web pages" were two different problem sets and the licensing deal that resulted in JS being marketed as "JavaScript" so Sun would let it live alongside the Java plugin for Netscape is an example of how deep the divide ran. Web pages are HTML documents, no sane person would try to create applications with that, right? At the time the primary use cases for JS were doing mouseover effects on images, creating popup windows and animating the status bar (before someone found a way to exploit that feature for nefarious purposes and browsers no longer supported it). But Java (and Shockwave/Flash) were inherently limited by living inside their opaque sandboxes where JS could access the entire page. Meddling with JS was also very easy because there was no need for compilation or expensive software. It was also "not a real programming language" so non-programmers had less barriers to dip their toes in or copy code snippets from their peers. Let's emphasise that: Java and Shockwave and Flash were not competitors to JS. "Real programmers" didn't like JS. It was just a "scripting language" for "scripting web pages" so designers could add some interactivity to their "pretty pictures". The only direct competitor was VBScript and VBScript was only supported by Microsoft (who also supported a reverse engineered clone of JavaScript called JScript). Ultimately standards are what helped JS survive and flourish. Standards helped nip the threat of fragmentation (e.g. via JScript) in the bud. But what gave JS the initial edge was simply the contempt "real programmers" had for "scripting languages" and the inclusive environment this created for beginners as well as the ability to instantly see the effect of your experiments.