As I've gotten more experienced in my career I've become more aware of what I don't know as opposed to what I do know.
It's funny that "Advanced" is mastering animations and transitions whereas "Expert" is being able to develop a full-front end consistently. I know many people that can build a front end, myself included but are nowhere near mastering anything, especially animations and css transitions.
I write this in jest of course. As we all know, self-assessment is about as reliable as...
The vast majority of the participants are not up to the task. They are paid professionnals, but they consistently overestimate they level, skills and needs. They often are not very good, and of course, they don't know what they don't know.
So I always check for that first, and rewrite my course on the fly to include the untold pre-requisites I identify. I don't tell them I do this to avoid making them feel bad. Nobody wants to hear "dude, you wanna learn react and you never used an arrow function, wtf ?" even if being comfy with JS is a listed requirement on the site.
Bottom line: most devs are not experts, and don't have the ability to assess that. But more importantly, it's enough for them to be productive and most industries don't need more.
You can get kinda far without really understanding what's going on, but if you stop and have to learn something really fundamental the "good" kids just seems to manage. Once things pick up they can excel because the have truly moved on. the previously "good" ones are still copy/pasting from past work or tutorials and get brackets wrong whereas the "slow" ones are now perfectly happy writing from scratch and thinking for themselves.
At least in the early days, using React was the first time most people would be exposed to webpack/babel, so it was also their first exposure to the newer JS features.
I miss being able to focus for just 2 hours on a task that would then give me a clear view on how well I knew the important mental models of a topic.
"Expert: Being able to style an entire front-end from scratch following a consistent methodology"
Meanwhile, "Advanced: Mastering animations, interactions, transitions, etc."
I can certainly "style an entire front-end from scratch" without "mastering animations".
CSS architecture (for a lack of a better term) is completely different from its more playful aspects. Stacking on on top of the other is just silly.
Knowing how to actually build things from scratch in a way that survives the beating of time is something else. It’s much harder to quantify though. Also, these days you have the css in js solutions, which means you can build the app by dropping in the css where you need it, so you get to tick that box, but if you tried to do it the “traditional” way you might not even know where to start.
EDIT two of my more common phrases at work are “you could just use css for that” and “you don’t need to use flex box to do that”. I’ve found that there’s a lot more using css to style things in isolation without understanding the power and performance it brings to the table. I spend more time trying to stop react renders from happening because css should have just been used than I do on the micro detail of ordering things a certain way to avoid repaints.
As others have mentioned, getting people to assess themselves accurately is very difficult. We always seem to skew towards the overly-confident side - not least because this what is usually rewarded in the job market.
Although it might be worth considering a simpler heuristic in the future as the distinction between Advanced and Expert is somewhat vague and perhaps ultimately not very informative.
At that time I was leading a small Node.js dev team and I would maybe rate myself 3/5 in Node. We didn't end up hiring them.
So 4 - 5 stars in an area just means "this is what I'm most comfortable working with and/or have the most experience with", not "if you rank yourself a 3 then I'm better than you at this" or "I'm a world-renowned expert at this". Otherwise, I'm not sure what you would expect from a fresh graduate who'd decided to use this format; 1 star for everything, or fractions of a star?
At first I was put off, but now I interpret it as their own personal scale, with 5 being what they the best at, and not as "I know everything about this".
But even then, the best candidates are usually the ones who rated themselves the lowest.
"You have selectors and styles, and I can just can look them up, so I guess I know all there is to know about it."
The "expert" category would rather be "having a deep understanding of what the browser does with styles and how the concepts of display etc actually work" for me.
But it's really hard to draw a line, css allows for awful hacky solutions that end up looking like they work, and many people "able to write a full frontend project" will produce rather bad CSS irl.
I think the best CSS compatibility across the board was during the time of ACID series tests, and has declined since.
But I know what you're saying. I also noticed a few percentage points of people saying they have 20+ years or React experience at this point.
Wikipedia puts it well:
> It's a cognitive bias in which people assess their cognitive ability as greater than it is. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability. Without the self-awareness of metacognition, people cannot objectively evaluate their competence or incompetence.
React, on the other hand, is a very intuitive library instead of an all-encompassing framework. You can easily setup a React application in a few seconds and get started, adding whatever you want as you go.
The JSX syntax is infinitely more intuitive compared to the Angular way of doing things. Which also gets me to the point of Angular having a specific way of doing things, "the Angular way".
With React there's less thinking required to get things done. The learning curve is steep (as in: you pick up the knowledge quicker) because the amount of information to take in is relatively low.
Angular takes months to master. It's very opinionated. And it requires typescript.
I for one hate typescript with the passion of a thousand suns. I know it very well because I have to if I want to keep my job, but it's so freaking unnecessary...
I recently had to read up on how Angular applies changes to the DOM. It was extremely difficult to get this information at all.
For me, React with TypeScript is king. It trumps Angular in three IMHO very critical points:
* Typed “templates” (a tremendous help with IntelliSense, too)
* No change detection magic (I firmly believe Zone.js is insane)
* Build time
* Agreed, this is an awful default and I don't understand why the Angular team hasn't already deprecated it. I suppose a slightly simpler "Hello World" makes Angular look a bit more approachable, but it just encourages accumulating unnecessary tech debt. The proper way to use Angular is to disable the magic (`OnPush` change detection) and use observables.
* Prod builds take a while and use a lot of memory, but local development is fine. (I haven't observed that prod builds are necessarily "slow" relative to what they accomplish.)
I like both Angular and React, but generally prefer Angular. The structure and universal consistency imposed by the framework and CLI are convenient (particularly when moving between projects or adding devs to an existing project), and the limitations imposed by Angular-HTML vs JS(X) are great for readability.
To some degree, I feel there are a varying set of reasons why people have settled on React - some were never fans of AngularJS/Angular and some disliked how Google handled the migration story from AngularJS to Angular are probably the strongest reasons. TypeScript also not being terribly FP friendly is also a huge negative to some, whereas React enables more functional patterns overall. Some also dislike separate HTML templates vs. HTML in JS templating, some prefer to cobble together a bunch of small modules together, even if the modules are weaker on average.
Ultimately, I think Google fell short on DX with the change over to Angular 2+ and the damage has lived on since, which is a shame because as a framework it was built really solid.
My real problem with Angular is it's not great for either beginners or experts. There's so much boilerplate and Angular concepts a beginner needs to learn to use the framework well and for experienced developers that stuff tends to get in your way.
-No dynamic directives -Nothing dynamic works with @ContentChildren, making anything that uses it the “last stop” for abstraction. -DI system makes inheritance/mixins nearly impossible, and without dynamic directives there are situations where the only solution is a massive copy paste job.
I work in the framework every day and spend countless hours shaking my head at cryptic docs any time I try to do any type of abstraction.
Angular, on the other hand...
You are confusing your imagination with reality (or the history of your own experience).
For the exact same reasons you stated -- Angular is opinionated and has everything. React is just a framework - you get to make your own opinions and are not handed the whole ball of wax, so you can make your own choices.
There's some general ways to set things up, but it's nice to have a general approach to each project you encounter.
And the biggest thing is Angular wasn't designed to be used by a solo developer working on a side project. It's evolved to allow that, but it was designed with companies in mind. Multiple developers, multiple teams of developers, maybe with little communication to work together on single projects whilst allowing guide rails to keep things headed on the same track, but allowing many ways to move the track in a way that fits your style.
The idea that react is just a "library" (think you mixed up your words there) is absurd when you look at the majority of react in the wild. Using create-react-app, react router, forms library, animations, etc etc, and now look, you just pieced together a bunch of different libraries to form....Angular.
Same goes with RxJs, dependency injection, unit testing, and modules.
Also, this isn't a scientific random sample survey, it's people who self-selected to take it. And I think that Angular specifically suffers due to that because it is more likely to be used at enterprise or large companies where devs often tend not to follow Twitter/surveys/etc at least, not in the same numbers as some other groups. Just my opinion.
That all changed with the advent of hooks [React and Vue],
which handle state in a very different fashion. Many
frameworks started experimenting with their own
implementations of hooks, but we quickly concluded it
wasn't a direction we wanted to go in
...
We can just use the language. Updating some count value — and
all the things that depend on it — should be as simple as
this:
count += 1;
Svelte does have an irritating wart IMO, citing their tutorial:
Because Svelte's reactivity is triggered by assignments, using array
methods like push and splice won't automatically cause updates.
numbers.push(numbers.length + 1);
numbers = numbers;
numbers = [...numbers, numbers.length + 1];
numbers = this.state.numbers;
numbers.push(numbers.length + 1);
this.setState({ numbers: numbers });
Similar docs for redux: https://redux.js.org/recipes/structuring-reducers/immutable-...
There's no good way around it without doing deep equality checks everywhere which is not reasonable.
numbers = numbers.push(numbers.length + 1);
Maybe it's just a coincidence, but Svelte seems awfully congruent with the pure FP way of doing things.
If you know React, look at the "Ten minute introduction to MobX and React" to see if it's for you. https://mobx.js.org/getting-started.html
- Simpler. You change values with `=` not some method call.
- Faster, as the svelte compiler dynamically creates bindings at build time, vs a virtual DOM that has to dynamically track binding at run time
- Smaller, since Svelte's output doesn't include Svelte.
Then there's the missing Typescript support...
That's what happens when you create your own template syntax...again.
I'll continue to use React so I can simply use Typescript for my components, not some random syntax.
My styles are typed, my components are typed, my state is typed. Why would I ever go back?
Preact diffs against the real dom and is faster than Svelte in benchmarks while the library is only around 3.5kb (the minified code fits easily on a single screen). I'd note that authors from most of the frameworks represented have submitted their own optimizations, so performance isn't strictly based on the author's familiarity.
InfernoJS is massively faster than Svelte or Preact (the benchmark author had to do some rather convoluted re-writes of vanillaJS over the years to keep ahead) and it uses a virtual DOM, but has a few optimizations that React doesn't have or can't use due to its external API.
stdweb is the real thing to keep your eye on as it seems to show that WASM can be every fast. They still haven't gotten the vanilla benchmark up to the same speed.
https://stefankrause.net/js-frameworks-benchmark8/table.html
React's Fibers do some cool batching behind the scenes which means that large updates (especially constant ones like animations) don't have large negative impacts on user interaction. I doubt this would be possible without a vdom or something very similar to track all changes before deciding batches and update priority.
Also, remember that vdoms have gotten a lot more efficient too. Newer ones can do things like re-use existing sub-trees or recycle vdom objects (they can also recycle the associated real DOM nodes too). Preventing all that extra garbage goes a huge way toward keeping those vdoms efficient.
As to svelte in particular, you aren't "just using an equals". It actually compiles behind the scenes into a completely different set of reactive code. This gets at my biggest issue with such frameworks. Their abstractions aren't free. I have to learn their proprietary syntax and markup. I then have to learn how their compiler works behind the scenes when its time to debug the code I wrote. When I compile a React-style component into ES7 and run it in the brower, I have to deal with webpack for imports and I have to understand that JSX is really just JS functions. Otherwise, what I wrote is what I'll see.
https://cdnjs.cloudflare.com/ajax/libs/preact/8.5.2/preact.m...
https://github.com/batiste/blop-language
Not sure why they claim proxies are complicated... I found it was a piece of cake to implement a working library for state management using a Proxy.
I suspect one factor in this is that if you know enough to apply Redux's patterns well, you probably also know enough to implement them yourself without bringing in a third-party NPM package. (Of course, not everyone will choose to do this --- maybe you like the Redux debugger UI or something --- but I think enough people do that it lowers the perceived average quality of codebases that do use Redux.) The library just doesn't do anything difficult in the way that, say, React's virtual-DOM diffing and reconciliation algorithms are difficult.
I quickly learned the previous devs had no idea what they were doing. They used the libraries but appeared to have no conception of what the actual pattern was, and so were getting essentially zero of the benefits.
I tried to make some piecemeal refactors, but I gave up on that approach. Everything was too tangled together, too reliant on other portions of the system, that I had no choice but to completely rewrite all aspects of the state management system.
It took me over a month, and I came away with a diminished opinion of NgRx. I think without context, it's good (but oh my, the boilerplate; I used to pooh-pooh people who complained about it but after thousands and thousands of lines of it, I have now joined their ranks). The problem is that ... (a) it is likely significantly different than anything a standard team has used before, and highly complex; (b) it provides ample footguns -- following the pattern is just as important as using the libraries, and this requires self-control that some don't have (not to mention actual knowledge of the pattern), (c) therefore there seems to be a high likelihood of inexperienced teams building complex state management systems that don't provide any of the guarantees you want from NgRx and which become impossible to maintain.
I'm a data point of one, but that's been my experience with the Redux pattern/NgRx at work.
Things can still get tangled up once you start using "ofActionDispatched" lifecycle handlers, but overall I found them to be far more manageable over time than NGXS.
The event system is basically synchronous, and just changes data which will be displayed in the UI. Why use the event abstraction and all the boilerplate that entails for synchronous code which doesn't really benefit from events? It feels like a cargo cult.
What it boils down to is any function which will at some point change the UI needs to be written weird, so that it takes the "dispatch" function and calls "dispatch(nextFunctionEvent)" instead of "nextFunction()".
Lots of developers always implemented their own half-ass systems to eliminate some boilerplate by automatically defining events from handlers and state or vice versa or some other combination of the above.
React hooks have basically eliminated it's niche, and none to soon!
Redux offers a ton of tooling and developer comfort if you get it right. And getting it right means having proper pull request reviews.
There's a lot of developer tooling (debugging tools), too, and a lot of middleware available to plug and play and GO.
If you're just using Hooks and the Reducer and Context APIs you're setting yourself up for a lot of headaches down the road.
Redux already makes use of those technologies, but wraps it in something easy to consume with a LARGE community for support.
Not using Redux is setting yourself up for failure, in my opinion. I've seen it happen too many times in the past year...
Thunks are our recommended standard way to write async logic in Redux apps [0], and our new official Redux Toolkit package [1] automatically sets up thunks by default as part of the store configuration.
Sagas are incredibly powerful, but most apps don't need them [2]. They're most useful when you need complex "background thread"-like behavior.
And no, Redux is definitely _not_ eliminated or replaced by hooks [3] [4].
[0] https://redux.js.org/style-guide/style-guide#use-thunks-for-...
[1] https://redux-toolkit.js.org
[2] https://redux.js.org/faq/actions#what-async-middleware-shoul...
[3] https://blog.isquaredsoftware.com/2019/03/presentation-state...
[4] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
There's been a lot of reasons for a shift in opinions over the last few years:
- Redux is well past the initial burst of enthusiasm in the "hype cycle"
- As you mentioned, there are a number of common concerns expressed by a lot of folks, most of which revolve around "boilerplate"
- There are now a wider variety of other options that overlap with ways you'd use Redux: React's Context and Hooks APIs, MobX, GraphQL / Apollo Client, etc. These don't completely replace Redux, but they do overlap enough that there's not as much _need_ to choose Redux for everything.
- And, frankly, Redux _has_ been overused in a number of cases. Folks assume you _have_ to use Redux with React, sometimes because a senior dev told them so, because they saw yet another tutorial that pairs them together, or because it was asked for in a job listing.
Now, Redux is definitely not dead or dying. My own estimates are that around 50% of React apps are using Redux, and the overall total download trends are still increasing. But, it's also true that the market share will continue to spread out a bit over time.
I talked about these aspects in my Reactathon 2019 talk on "The State of Redux" [0] and my post "Redux - Not Dead Yet!" [1].
Besides all that, we're doing a lot of work to make it easier for folks to learn and use Redux.
- We have a new official Redux Toolkit package [2] [3]. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. It's now our recommended approach for writing Redux logic, and the feedback from folks who have adopted it has been amazingly positive.
- We are currently working on a major rewrite of the Redux core docs [4]. As part of that, we've already added a new "Style Guide" page [5] with our recommended best practices and guidelines for writing good Redux code, like structuring files as "feature folders" or "ducks", modeling actions as "events" instead of "setters", and so on. We're also going to completely redo all the tutorials and examples to show easier patterns to work with, drop outdated references to concepts and terms like "Flux" and "container components", and emphasize use of Redux Toolkit as the standard way to write Redux apps.
- Our new React-Redux hooks API [6] makes it a lot easier to work with Redux data in React components compared to the standard `connect` API, especially if you're using TypeScript.
So yeah, there are some repeated waves of annoyance with Redux that pop up on social media every so often, but there's also a ton of folks still using and learning Redux. My goal is to continue to make it easier for Redux users of all levels to use Redux.
[0] https://blog.isquaredsoftware.com/2019/03/presentation-state...
[1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
[2] https://redux-toolkit.js.org
[3] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...
[4] https://github.com/reduxjs/redux/issues/3592
Also surprised to see ClojureScript's satisfaction rate at 60%. In the past year or two it's become much easier to use NPM packages, which was IMO the last remaining huge missing piece. It's now a great language for web development, providing what JS couldn't: a rich standard library with, ahem, consistent API's, a strong FP flair with excellent immutable data structures built in, and maybe most critically of all, a somewhat constrained macro system that allows users to write and distribute third-party libraries for syntax that in other languages would have required an extension of the language standard.
All of that is (I think) desirable by anyone unless you're hardcore anti-FP (with the one exception, I guess, that macros can be and are abused, though I haven't seen it very often in the CLJS ecosystem). So why hasn't ClojureScript seen more adoption? It's the age-old curse of Lisp, I guess: those dang old parentheses which decades of CS curricula taught in ALGOL descendents have rendered foreign and horrifying.
BTW Sacha, thanks so much for Discover Meteor, it was what I cut my web dev teeth on! Somehow I hadn't heard about Vulcan until now. It looks really interesting and I'll be looking into it more.
It's a missed opportunity, but the mistake was the Meteor Development Group's in betting on the JS community being satisfied with an "opinionated curation of the stack". The JS community has the attention span of rabid squirrel, and this was obvious back in the 0.8 days. They were never going to love a single bundle of choices for long.
How many other JS build tools & frameworks from 2014 can say the same?
HBS = restrictive for nonsense reasons. The separations of Model, View, and Control really don't make sense anymore. It's outdated.
I've worked with it for years and I consider myself familiar with it up until 3 years ago, but I would never go back to EmberJS. And that's why the salaries are higher for Ember developers: they're rare.
Personally I prefer anything that is restrictive, I would take the price of less flexibility for the ability to stop people doing stupid things.
What ? why ? care to elaborate please ? and what do you use instead ? MVVM ?
https://emberjs.com/editions/octane
https://octane-guides-preview.emberjs.com/release/getting-st...
People ditch Cordova heavily, but also React Native and native apps. Electron rises to the top, although you can't build mobile apps with it that are distributed through the various stores.
So, what's filling the void for app development, if everything just went down?
I've been hiring Java and Swift devs for my shop after a really poor experience with React Native. Hoping that changes soon, but it seems unlikely given how infantile Electron is still.
While there is a sharp downtick of people who think that JavaScript is moving in the right directin, most agree that the overall situation in terms of complexity and velocity is getting better.
I don't have any explanation for this, but would agree: Developing in JavaScript feels easier to me than just a few years ago.
It seems like there was one specific winner of all of the UI frameworks. React.
There is now pretty much one specific winner to package managers. Yarn.
There is one specific winner for language front-end: Typescript.
There are basically two front-end build tools left: Webpack and CRA (of which is basically a Webpack wrapper with babel and a million other things)
All of the latest npm packages are either coming with ES6 modules or, more interestingly either are completely written in Typescript or at least have @types now. And all that stuff helps people writing JS too.
Seems like within React, Redux/Apollo/plain is splitting the data layer again too
But the yarn/npm is a tiny difference and data layer is much more application specific
I have seen some horrible stuff as an enterprise dev, from poorly constructed jQuery projects, to old frameworks like Struts/Stripes that just get out of hand. No real way to test, full of side-effects and bad choices, TONS of dependencies (outdated/unmaintained UI libraries etc). I often wonder if people complaining about JS and Frameworks have any experience developing or maintaining legacy web applications from the days of yore. Back when the web was young, there just wasn't a good blueprint for how complex web applications should be designed. We've come a long way, and for better or worse, the JS community has made improvements to the language, frameworks, etc, all of which make our jobs SO much easier.
I failed in my task. With these frameworks, given enough time, there ends up being a lot of "deprecated boilerplate" code, either directly or via dependencies. E.g. Vue is closely coupled to Webpack, and Webpack deprecated so many things between versions 2 and 4, that there's essentially no mechanical way to migrate the code. One must figure out every detail of the auto-generated Webpack config from version 2 and figure out how to do the same thing in version 4. (I'm looking at you, CommonsChunk and splitchunks!)
Legacy applications from the days of yore didn't "bit-rot" like this.
But I totally agree. Things like the various cli tools, widely available documentation and good IDE support for frameworks has made JS a lot better in recent years.
For actual metrics, the NPM stats of TS vs Flow downloads [0] show TS usage skyrocketing up to >33M DL/month, while Flow has never gotten past 2.5M.
Purely anecdotally, I see numerous articles talking about projects migrating away from Flow, and absolutely nothing about actually adopting Flow at this point. Even projects like Jest, which started inside Facebook, have switched to TS to get more outside contributions. At this point, the only major project I can immediately think of that's written in Flow is (ironically) React itself.
FWIW, I wrote a blog post recently about my own experience learning and using TS as both an app dev and a Redux maintainer [1].
[0] https://npm-stat.com/charts.html?package=typescript&package=...
[1] https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...
I was very active, learned a lot of the intricacies and a lot of advanced typing with Flow, did lots and lots of experimenting to cover edges. I also was very active in the "issues" section of the Github-Flow repo, reading, answering and also posting issues.
I kept track of where TypeScript was though, occasionally posting issues there too. When it looked like they had feature and strictness parity, especially the latter, I switched over though. Reasons:
- Flow was on a downward path, TS on an upward path. Already nr. of developers and the ecosystem was far greater for TS.
- The Flow team was almost completely absent in the Github repo. There were some Facebook people but some of the active ones were not even from the Flow team. In contrast, the 2nd issue I wrote for TypeScript had a response from Anders Hejlsberg (TS inventor) himself, and his responses to issues can be found all over the place. Also, the Flow team's focus seemed to be almost completely supporting the internal use of Flow. It actually was a valid "open source" use case: "We write something for ourselves, here is the source in case you find it valuable.". Keyword being "ourselves", they did not care too much what other people wanted/needed unless it fit into their existing plans. TS was the complete opposite, it was written for others right from the start.
- We have a team with quite a lot of new (out of university) developers, most of them in another country (Eastern Europe) and not our own employees. Everybody but me was very reluctant to go with Flow (I had added it to the core library, they wrote apps using it, so they did not have to use it). TypeScript adoption was much easier, also for those who don't see themselves working on our projects "forever", because it clearly is a much more valuable skill then Flow in the JS-developer market.
- Strictness still was a bit more in Flow but the difference was insignificant by then.
- On the other hand, I actually removed lots of (inline) type annotations, concentrating on the types only in the function headers and when TypeScript could not auto-detect it (e.g. "new Map()" - what is the key type, what is the value type?). I followed what seemed to be the preferred TS style for type annotations. I hardly gave anything up in terms of strictness, but had far less "type stuff" in the code. Okay, this is not so much "Flow vs TS" but my own choices. In TS it's actually better to have less inline types (when auto-detection works), because while Flow - after I had filed an issue that was implemented - raises an error every time there is a discrepancy between an auto-detected type and a type annotation TS silently uses the type annotation in some contexts and does not complain when it is different from the auto-detected type. That sounds worse but if there is no type annotation it's fine, so I decided to go with it and not file an issue to ask for a change.
- Probably one of the most well-known TS advantages: Far better support, via the DefinitelyTyped repo, for types for all kinds of external libraries.
- When converting some very complicated "dynamic" types from Flow to TS the TS version was FAR easier to write. Especially conditional types help a lot. Don't know if Flow has something like that by now, it didn't when I made the switch.
As for "why types at all" raised here:
I happily wrote JS code without them since JS was invented (even though I wasn't what today would be a full-time JS developer, that happened only the last five years, and also used all kinds of other languages). Especially the last ten years a number of large corporate projects too.
I switched to types because, as somebody wrote here, types are there anyway, whether I annotate them or not. All input and all return values have a type even if I write plain JS.
---- Just an aside: I chose Flow at first because of - at the time - greater strictness, but mostly because it was plain JS plus JS types. TypeScript sounded like it was its own language. IT IS NOT! It took a while until I actually checked what it really is - the self-marketing is really bad in this respect. Unfortunately they bundle the "Babel" ("compilation", code transformation) aspect and the types, even though they are completely orthogonal. Apart from (unnecessary) namespaces and enums, both old features for which different pure JS (or TS-type) options exist now, TypeScript actually is 100% pure ESnext. If you strip all the type annotations and don't rewrite anything you are left with pure ECMAScript. Until they added namespace support the Babel plugin for TypeScript was very small and all it did was the same as the Babel Flow plugin: Just strip all the type stuff. No code rewriting took place. That's why until recently namespaces and enums where not supported by the Babel plugin, but those are features one can easily live without (Note: pure TS type namespaces in declaration files and as part of the types, and not of the JS code, can of course be used; I'm talking about the namespaces that are in "JS code space"). ----
The great benefits of TS (first of Flow) for us:
- IDE live coding help and support. If I see some function, and I encounter this a lot in 3rd party code, I often have to go to the source code to see what it#s actually doing with those parameters to understand what I have to pass in.
- "Tracks" for other developers that reign in their fantasy and creativity. The types force them to stay on track with how they use some API functions of the library. That's even more important with new people. Of course, if the project is not too big and the same people have been working on it since the beginning, and very few team changes, then it matters less.
- Greatly helps refactoring and rewrites.
Although perhaps I'd agree, actually. I'm not sure. It's at least not a huge deterrent.
Perhaps the biggest is the overlap with web dev tech, team skill makeup, and the hiring market for web devs being incredibly vibrant. Vast majority of teams have struggled to go native and build/hire those teams, and are instead excited about using the web devs they already have or taking advantage of that hiring market.
One trend that is really interesting is that many teams have decided they need to be prepared for a PWA future and can't afford to have two separate efforts to accomplish that (i.e. app store apps and PWA). They see Ionic as a way to do both and be ready for the expansion of PWA adoption which is early but happening fairly organically, and has some key enterprise benefits that make it attractive for those teams.
Sorry you had a bad experience on our github issues. We're a small team relative to the size of the community and have had to resort to automation and tooling to figure out signal from noise. It's been a constant process of iteration on that front.
Neither RN nor Flutter fulfill the promise of, "write once, run everywhere", whereas Ionic, warts and all, does today.
Maybe Flutter web will work out though, we'll see. If Dart evolves then Flutter becomes a pretty compelling stack.
The other thing happening with Ionic is that our enterprise business has been doing very well. We’ve added hundreds of enterprise customers in the last two years and have really built a solid offering for medium to large businesses. We’ve also seen more and more huge apps built on the platform.
I’m guessing our focus on enterprise has also cost us a bit in this survey. Been a learning experience how to balance that and convey to folks we are both an OSS and enterprise co
And seeing angular in the “analyze” category makes me think the sample of folks responding to this survey are in a certain bubble that does not map to the broader dev ecosystem we see every day, so there’s that.
Right now I'm trying no framework approach to make a web app with intension on using Cordova or Capacitor to hook into native Tensorflow.
• Go 2018 — https://blog.golang.org/survey2018-results
• Go 2017 — https://blog.golang.org/survey2017-results
• Go 2016 — https://blog.golang.org/survey2016-results
• Rust 2018 — https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
• Rust 2017 — https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul...
• C++ Global Insights 2019 — https://isocpp.org/files/papers/CppDevSurvey-2019-04-summary...
• C++ Global Insights 2018 — https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary...
• StackOverflow Insights 2019 — https://insights.stackoverflow.com/survey/2019
• StackOverflow Insights 2018 — https://insights.stackoverflow.com/survey/2018
• StackOverflow Insights 2017 — https://insights.stackoverflow.com/survey/2017
• StackOverflow Insights 2016 — https://insights.stackoverflow.com/survey/2016
• StackOverflow Insights 2015 — https://insights.stackoverflow.com/survey/2015
• IntelliJ, Dev Ecosystem (All) — https://www.jetbrains.com/lp/devecosystem-2019/
• IntelliJ, Dev Ecosystem (Java) — https://www.jetbrains.com/lp/devecosystem-2019/java/
• IntelliJ, Dev Ecosystem (C) — https://www.jetbrains.com/lp/devecosystem-2019/c/
• IntelliJ, Dev Ecosystem (C++) — https://www.jetbrains.com/lp/devecosystem-2019/cpp/
• IntelliJ, Dev Ecosystem (C#) — https://www.jetbrains.com/lp/devecosystem-2019/csharp/
• IntelliJ, Dev Ecosystem (Go) — https://www.jetbrains.com/lp/devecosystem-2019/go/
• IntelliJ, Dev Ecosystem (Javascript) — https://www.jetbrains.com/lp/devecosystem-2019/javascript/
• IntelliJ, Dev Ecosystem (Kotlin) — https://www.jetbrains.com/lp/devecosystem-2019/kotlin/
• IntelliJ, Dev Ecosystem (PHP) — https://www.jetbrains.com/lp/devecosystem-2019/php/
• IntelliJ, Dev Ecosystem (Python) — https://www.jetbrains.com/lp/devecosystem-2019/python/
• IntelliJ, Dev Ecosystem (Ruby) — https://www.jetbrains.com/lp/devecosystem-2019/ruby/
• IntelliJ, Dev Ecosystem (Rust) — https://www.jetbrains.com/lp/devecosystem-2019/rust/
• IntelliJ, Dev Ecosystem (Scala) — https://www.jetbrains.com/lp/devecosystem-2019/scala/
• IntelliJ, Dev Ecosystem (Swift & Objective-C) — https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/
On the contrary, I constantly think "why..."
I feel strong typing JS is just a result of backend developers not questioning their upbringings and failing to use proper naming conventions, progressive enhancement in the form of JSDOC comments, proper unit tests, and proper peer reviewing processes.
Honestly, I don't get it. In all my 20 years as a professional web developer (full stack and specialising in the frontend for the past 12 years) I have never needed it...
I really don't understand the charm of it.
- "proper" naming conventions
- JSDOC comments
- unit tests
- peer review
Using plain vim with typescript makes no sense.
It gives me plenty of useful checks using TS. Lack of members, wrong types returned, missing return in switch statement etc.
Saying JS works for you fine sounds like "I have (or waste) good amount of brain memory on my program, so I don't need any further checking.", which can't be the case on code other people wrote.
We are primarily English speaking (myself being European and working in the USA now) and they struggle with English immensely, in general.
Many projects from Japan that I see have faulty English grammar in variable names and is documented only in Japanese characters.
It seems to me they mostly targeted English speaking countries, which would explain why Japan (and Asia in general) has such low response.
EDIT - They don't. They have 10+ years using JavaScript
TypeScript was released in 2012, sure there are early adopters and beta users, but I seriously doubt that nearly 22% of the people using TypeScript prior to it being released.
It could also be some prick who converts 80 hour weeks into years of experience x2.
I long for a test runner that does as little magic as possible, doesn't try to be a build system and module loader, doesn't inject random libraries into the environment, it just loads URLs and reports back test results.
Test runners and assert libraries can massively slim down too if they because simple importable modules and don't modify the global environment or create plug-in systems or complex test lifecycles. Tests are async functions that resolve or reject, that's it.
It’s simple enough, fast, and I have yet to run head-first in to some problem.
Strongly agree: 7.3%
Agree: 16.9%
How?
I have noticed in the big corporate space many people writing this code are formally educated to write code in a very specific way that isn't quite JS-friendly and they need the extra boilerplate to make JS behave.
It might be Javascript itself. It could also be the endless permutations of environments(browsers, resolutions, devices, etc) that we have to cater to.
Front End Web Development is hard.
1. The first graph shows "Rankings". I strongly doubt rankings are more importants than values. When Clojurescript goes from 67% to 72%, this increase is shown as a ranking decrease because Reason was introduced at a higher ranking.
2. The meaning of the data is unclear, since the exact questions and proposed answers are not shown.
3. Some measures have varying populations, so ranking them is absurd. Supposing that 2% of people use A and 80% use B, what does ranking satisfaction with A above satisfaction with B mean? Since the uncertainty is huge on the A measure, the "real" ranking is not known.
4. Having to click in order to switch the measure shown is strange. The three measures should be display on three consecutive graphs.
5. The Categories graph is unreadable for a slightly color-blind like me.
6. The Categories segments aggregate data over 2 levels which makes them unreadable. First levels: Used, Heard, Unheard. Second levels should be computed relatively to their containers. Who cares if 1.8 % of users would not use Elm again? What is important is that ~28% (1.8/(4.7+1.8)) of those who used Elm would prefer not to do so again.
Seeing the trajectory of each piece of tech gives a lot of insight on overall trends. For example, I was thinking of learning a bit of the more recent Angular (last time I used it was Angular 1.x, before React was a thing), but now I think I'll look more into Vue.js, as its trajectory looks much better.
Hard to get over the initial assumption that dark red means negative, and bright happy blue means positive.
Good to also see Typescript making a foothold - it's a great alternative to pure JS.
Having API documentation that is guaranteed not to go out of date with your code. Having a shared standard for describing your endpoints in a machine-consumable way. Being able to automatically generate typescript types from any schema (correct me if I'm wrong but I don't think there's any tooling that would do the same for arbitrary REST APIs). Being able to get autocompletion when writing queries for free ^ Those were all things I didn't know I needed until I started using them, and like Typescript, it feels painful to go back to not having them
I'm not sure why I should care what everyone else wants to learn. I guess it's worth finding out if there is a new popular framework this year. Sigh.
I’m aware they have no scale, are simplified etc, but chart format has very specific meaning and I believe that visualisations could be chosen in a better way.
Thanks for all the memories, Atom! <3
We see React go 93/93/91/89, but the 89 circle is higher than 91 and at the same level as 93?
We see Vue go 87/91/91/87, but the second 91 is at a higher level than the first and the 87 is way below the first 87.
It seems like the React line should be straight, then dip down a little bit, then dip down a little bit more.
The vue line should go up a bit, then be straight, then dip back down to the original position.
- GraphQL
- Jest
Not much useful there for someone who just, you know, plods along with mere vanilla javascript.
And when I flipped to 'inverse' (because of the blinding white) ... there went the color scheme.