23 ms·

State of JavaScript 2020

168 points by milkers 6y ago

Aldipower 6y ago
First paragraph reads as follows: Crappy last year, blah, TypeScript. Nothing interessting about JavaScript... Did not read further.
- brdd 6y ago
  Well you must be very fun in meetings.
  - Aldipower 6y ago
    At this point I already left the meeting.
    - Daho0n 6y ago
      More like got kicked out.
- typeengineering 6y ago
  yeah exactly, typescript is n1 enemy of javascript, but they praise it in the very first paragraph... this is the state... of javascript...
milkers 6y ago
Some takeaways of mine; - Typescript keeps strengthening its position as industry standard. - Svelte is hyped, but is it battle tested enough? - Testing Library is quite new in the town but already the runner up testing tool. - In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest. What are yours?
- Pfhreak 6y ago
  I've seen Svelte used in a number of high impact tools, including in AAA videogame UI. In my experience, I've seen engineers very happy working with it, and it meets the performance needs for a videogame it should be good enough for the web.
  - ha4fsd3fas 6y ago
    Do you have any info on that AAA game? I would be curious to read up on how/why they used svelte.
  - preommr 6y ago
    > including in AAA videogame UI elaborate, please, because this sounds so bizarre. Are they bundling an entire web view and then interfacing it with their game engine? Not only is the tech conceptually weird, I can't think of too many AAA games that have very complex UIs other than maybe the CK series.
    - turtlebits 6y ago
      A lot of games have storefronts for DLC. I've seen these used as webviews, especially payment forms.
    - Macha 6y ago
      It doesn't surprise me. 5 years ago the standard solution was Scaleform, which is pretty much the same thing but with Flash.
    - vbezhenar 6y ago
      It might be for main menu. I think that WC3 reforged used webview for its menu.
      - Pfhreak 6y ago
        Main menu but also in game UI. Ability timers, weapon reticles, health bars, etc.
    - 6y ago
- sevencolors 6y ago
  > - Svelte is hyped, but is it battle tested enough? Try asking the NYTimes how it's working out for them
  - milkers 6y ago
    First, I hate paywalled news sites. Second it sounds more like inbreed than a battle thanks to reddit friends. `The creator of Svelte, Rich Harris, actually works there!` `I think it was a passion project from a web dev at NYT` I would still like to hear more about it, will dig further, thanks.
- jtdev 6y ago
  > “In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest.” Not sure what you mean by “data management” here, but fetch/REST seem like to most predominant, simple, ubiquitous means of handling external data.
  - _nalply 6y ago
    When I read that I immediately thought about GraphQL subscriptions. I don't know whether this will a bottleneck, but perhaps it makes sense to route everything through GraphQL, this means: someone updates via GraphQL and everybody listening gets an event by subscriptions.
- williamdclt 6y ago
  > Testing Library is quite new in the town but already the runner up testing tool We've been using Enzyme for a few years at my company. Very recently a new guy introduced testing-library, and oh my god it is so much better. For one thing, it actually allows to render component on react-native (Enzyme's `mount` doesn't work for some reason) and that's reason enough for me to switch.
- davidwparker 6y ago
  Svelte is hard to get passed the hype until you build a reasonable size project with it. Personal anecdote/plug: I built https://www.listenaddict.com/ https://www.listenaddict.com/ last year with Svelte. It's medium-ish sized (majority of the app is the moderator and administrator pages). It's extremely fast to develop (and will only be faster with SvelteKit+Snowpack). It's trivial to implement components and stores make state management a breeze. Having done React for ~4 years, and some Vue projects, I won't be going back to those anytime soon. That said, it's not without its own issues, but anything I've had issues with I've been able to solve relatively quickly or have someone within the community help.
  - tjchear 6y ago
    Looking to jump into Svelte and would appreciate your opinion. What did Svelte do better than react and vue that you won't go back to them anytime soon?
systemvoltage 6y ago
Cliche rant coming up: as a backend engineer, recently started working on frontend. Is this how yall do things? Everything so far feels less mature, thinly pieced together, barely holding up, fast moving, unnecessarily bloated, and no care for longevity, robustness and discipline. Seems like every thing is on Youtube, no real good books (yeah, go ahead and search for "React JS" books on Amazon and see if you find something solid that is well praised). It's these 8 hour fucking Youtube videos that I need to watch and probably not remember anything. I watched one of those and its horrifying what kind of stuff these people are teaching. I am obviously generalizing, sure there are some really smart people involved in Frontend tech, but boy if you take a sweeping look from ten thousand feet, it ain't pretty. Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this? /rant
- dboreham 6y ago
  Moving fast and breaking stuff.
- kag0 6y ago
  As a backend engineer who has worked on frontend recently, yes, that's how they do things. There is some hope though, recent standards like web components and ES imports help a bit.
- factorialboy 6y ago
  I think it's about individual maturity than tech-stack. Frontenders are likely to be younger than backenders, and some of the traits you observed are a result of that.
  - cosmodisk 6y ago
    Maybe,but it's not the kids who sit at the top of the food chain in places like language committees, standard agencies, or even the CTOs of this world ( the real ones,not those of 5 person startups) where things get decided for years or even decades ahead.
bhauer 6y ago
As someone who is relatively outside of the JavaScript ecosystem, I had the following realization yesterday when I was reviewing this: JavaScript has what I would consider two distinct flavors of "back-end" frameworks. It has frameworks like Express and Koa, which I would consider traditional back-end frameworks. These are designed around handling HTTP requests and providing dynamic responses in myriad forms: rendered content as HTML, API responses as JSON or other forms, etc. And then there are what I would call back-ported front-end frameworks, or semi-static site hosts. These are Next.js and Nuxt. As far as I can tell, these can be used to build traditional server-side application logic but they seem intended to host "pages." For example, in looking over Next, I see it does have the ability to expose API routes, but this seems very much a second-class citizen. The Next documentation [1] says "Next.js has support for API Routes, which let you easily create an API endpoint as a Node.js serverless function." This seems to be provided as an escape hatch, but it doesn't appear to be the core focus of the framework. Is this distinction real or am I sadly misinformed of the, ahem, state of JavaScript? [1] https://nextjs.org/learn/basics/api-routes https://nextjs.org/learn/basics/api-routes
- Eric_WVGG 6y ago
  Yeah, that's about right. I was also surprised to see Gatsby and Next.js listed in backend, but it makes a weird kind of sense. I think "static site generators" would be a better umbrella, but it's a shady distinction for sure. And your summary of Next.js API Routes is correct as well. As an example, I have a site built in Next that needs to be able to query data off of a SQLite database. Back in the old days I would have set up a simple PHP server of some kind… today I might have knocked something crappy together in Node… but in Next, you just point at a route, grab the SQLite database out of the filesystem, and look over your query parameters. It's really neat.
- robin21 6y ago
  Next.js is mostly about server side rendering. If you look at something like nest.js it offers a more familiar backend with more structure. Because you can write your backend these days as serverless functions which just make api calls to other hosted services - the traditional backend framework (orm + routing) becomes less relevant.
deleted 6y ago
[deleted]
ehutch79 6y ago
Vue is the 3rd in framework ranks... and like the 16th ranked? "Testing Library" is the top testing library apparently? Had to check that this was an actual library, I'm sure many people just left it as a 'whatever' choice. Someones data is dirty dirty dirty
- sevencolors 6y ago
  Testing Library is an excellent library from Kent Dodds, it's also one of the testing tools recommended by the React team https://reactjs.org/docs/testing.html https://reactjs.org/docs/testing.html
- jtdev 6y ago
  > “Someones data is dirty dirty dirty” Par for the JavaScript community course.
- notapenny 6y ago
  I don't think it would be a "whatever" choice personally. I didn't take the survey this year, but other years you had to explicitly specify what your level of interest/satisfaction with a particular technology was. Personally I'm not surprised that testing-library came out so high in satisfaction; its an incredibly useful layer over Jest and and incredibly popular in React-land.
  - ehutch79 6y ago
    I mean, if you don't know it's a library, you may think this is the 'other' choice.
tus88 6y ago
I thought it had been renamed Typescript?
cosmodisk 6y ago
If the healthcare sector would apply the same ideas and principles of the front-end industry, it'd look like this: oh,look, it's a pen! Why don't we combine it with a scalpel and an angle grinder for our next surgery? Front-end is an absolute shit show with all the html/css/js mixture.
- Aldipower 6y ago
  You mean _Web_ Front-End. Do not forget Web is delivering to a lot of platforms. Try the same with desktop apps or mobile apps. Good luck.
  - cosmotic 6y ago
    The trend seems to be using HTML/CSS/JS for "native" app frontends as well, see Electron an the countless apps that use it.
  - cosmodisk 6y ago
    I get it, there's mobile, desktop, even fridges,or doorbells that require front-end interfaces. I also understand it's not easy.im fact it's hard.very hard. But currently it's a shit show nonetheless, because everyone is going their own director with no plan to somehow unify or at least standardise the whole thing. And it's getting more and more absurd every day.
- tashoecraft 6y ago
  Your opinion is unoriginal and unhelpful. Show me another platform with the reach and usability as the web.
- jakelazaroff 6y ago
  And yet, there’s no other platform where you can go from an idea to something easily accessible by anyone in the world — in a span of minutes.
typeengineering 6y ago
1. Optional Chaining and Nullish Coalescing is everything that they could come up with in the last 5 years. Private fields in javascript. God please what is wrong with these people. 2. If you look at resources, you have css-tricks as n1. Clearly there's very little number of Software Engineers / Computer Scientists in the JS world which doesn't have to be because if you're skilled you can take massive advantage of the cool prototypal programming language like JS. yet I bet 95% of the JS "community" hasn't even got a clue what a prototype is. 3. Additionally, you can see how the tools are skewed towards react/webpack but server-side JS can be just as powerful, yet there isn't much innovation in there. So that confirms the previous 2 points that the "state" of javascript, is just a homogeneous webpack/typescript bunch of people who think the exactly same. There are so many real engineers who work with proper programming languages, and they get terrified when they see the "state" of javascript and curse it. I've worked with JS for the past 5 years and I don't blame them. There hasn't been a professional approach to software development in the JS world, everyone's obsessed with their tools instead of applying skill. But I'll change it this year. If you're a back-end engineer looking for a simple, yet very powerful solution to build your js/widgets, you'll get it soon. not free thank you.
- erikpukinskis 6y ago
  This seems unnecessarily mean and dismissive. I have a software engineering degree, have been doing professional software engineering for 20 years and I love JavaScript. There are lots of things I dislike that are written in JavaScript or for JavaScript developers but I like the language. What are you trying to get out of insulting people like me? Are you trying to get us to come seek you out as a teacher? Do you want us to feel ashamed of out careers and realize we need to go back to school?
somehnrdr14726 6y ago
If I were trying to compare technologies I might focus on metrics like release strategy, documentation quality, scale of existing products using it, and maintainer activity. This survey comes out every year and tells me who is winning the social media popularity contest. Technologies labeled as "Avoid" have over 50% respondents saying they don't even use the technology. Avoid it why? Because I won't be trendy at the javascript meetup? Does anyone actually use this data to drive decisions?
preommr 6y ago
It seems like the overall trend is that people are getting more and more unsatisfied with the current landscape now that a little bit of the sugar high from first wave of shiny new tech is starting to fade away. The jump from "whatever js was in 2014" -> angularjs junk -> react/vue/angular was pretty big. But now the glamour is gone and we're moving into the phase of actually having to maintain some of the things we built and the wear from bad decisions is starting to show. ----- Svelte also seems like the cool new kid on the block. Svelte surprises me in how much people fawn over it. I really don't understand the hype since I don't think it's a huge jump forward, and there's also a lot of "misunderstandings" about it in comparison to other frameworks. Like one thing I've seen a lot is people mention how it requires less code, but it's not that much smaller. It just looks smaller for small test cases where there are like 8 lines of code or because svelte makes stylistic choices that have tradeoffs that aren't immediately obvious. If you take a loot at react/vue, they're not that much bigger for realistic component size. Anyways, front-end framework discussion is long and muddled and confusing. I wanted to make a point of how svelte people often confuse the engineering/implementation vs the philosophical approach in frameworks. Things like svelte's bundle size being smaller is because other frameworks don't put as much emphasis on it. I was going to say that react is bloated and that preact is much smaller, but looking it up it seems like somehow react is 2.6kb, preact is 4kb, and svelte is 1.5kb. Angular is 62kb. Which proves two points, react/vue can be smaller if it wants, the approach it takes doesn't limit it and that things move so fast that somehow preact makes bigger bundles than react.
- turtlebits 6y ago
  Svelte is a a breath of fresh air because of its simplicity, not because it's bundle size (which is a bonus). It's especially easy to get up and running and the documentation is great. React/Vue/Angular you have to learn the build system as well as the ins and outs of the framework, and there are too many opinionated ways of getting started.
  - preommr 6y ago
    How is this complicated: ``` <script src="https://cdn.jsdelivr.net/npm/vue@2.6.12/dist/vue.js"></script> https://cdn.jsdelivr.net/npm/vue@2.6.12/dist/vue.js"></scrip... var app = new Vue({ el: '#app', template: "{{message}}" data: { message: 'Hello Vue!' } }) ``` A lot of the build problems with react/vue also exist with svelte. In fact it's even worst with svelte because it's compiled only (which is it's unique selling point) whereas vue can be used in a much more progressive manner. React is a little bit harder because of jsx, but it's still not that much more complicated. Build-wise, parcel supports jsx/vue files out of the box. Plus React/vue both have cli tools that I don't like and wouldn't recommend, but are super easy to get started with. And this all comes with the giant caveat that react/vue make progress which can lead to confusing versions. Svelte is a lot younger (kind of, it came out a few years back, so idk) so it hasn't had to cross that bridge yet. And even then, there was the confusion with Sapper. I highly doubt that svelte is going to be immune from the fast-paced nature of these frameworks.
wildermuthn 6y ago
I’ve been doing web FE in various capacities for about a decade. First jQuery, then backbone, then Angular, then ClojureScript with React, now React and Apollo. While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes. Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React addressed state complexity, and GraphQL finally forced backend engineering to coordinate with frontend engineering (i.e., making full-stack engineering efficient). People don’t switch tooling and frameworks for fun (well, not primarily), but because the pain of learning something new is worth the benefit of reducing unnecessary complexity. What I don’t think non-FE engineers often appreciate is just how essentially complex user-dictated mutable state is. Even with immutable data structures (which I love), you can’t get around the fact that a web-app is, by its very nature, a canvas that changes according to human activity. The difference between FE and BE is the difference between painting with fingers and flipping a switch with fingers. Updating a user’s role on the BE is a single SQL operation, but for the FE, it might mean countless changes to the user experience. It’s the difference between storing data and using data. And if there’s anything to conclude from the overwhelming amount of work done on FE tooling, it’s not that people love to try new things (although we do), it’s that the struggle is real. Side-note: BE gets a taste of FE complexity when dealing with syncing live mutable data among multiple clients. That’s a beast, and the point where everyone realizes that full-stack is the only sensible way to work.
- viraptor 6y ago
  > GraphQL finally forced backend engineering to coordinate with frontend engineering I'm curious what do you mean here? The way I see it is the exact opposite - front-end making new kind of queries without having to coordinate with backend. With positive effects (faster results) and negative ones (so this new query takes a minute to resolve and it's in production - fix it now!)
  - wildermuthn 6y ago
    My view on this may be idiosyncratic and wrong, as I haven’t read about other teams doing this intentionally. Having said that... The most powerful but underused feature of GraphQL is that it abstracts away the details about the BE database model, which is for the FE (i.e., the product and user experience) an unnecessary implementation detail. A poorly designed GraphQL schema (and my teams did a lot of this at first) often look like denormalized REST endpoints. This is particularly true in Relay (do people still use Relay?) In such a case, you’re right that FE-BE coordination doesn’t change much. Additionally, FE stores like Redux are still central to managing derived data necessary for component rendering. However, a well-designed GraphQL schema looks like the shape of data required for component rendering, i.e., for the user experience. Example: having top-level queries for “users” vs. “profiles”. The first has all the data about a user, the second has all the data required to render a user profile page, which almost always includes more data. Let’s say there is a profile photo. A denormalized scheme just defines a "user.profileImage" as an Image type and returns data from a DB relationship of a similar sort (knex and other tools make this easy). While this might seem fine, it is the start of the same old story — BE being blissfully unaware of the use of its data in the context of the user experience. Perhaps when a user has no profile photo a default one should be shown based on their “organization” profile photo. No problem, just pull “user.organization.profilePhoto”? Well, okay, but maybe that is missing too, and we... go down a FE rabbit hole when all we really want is a stupid URL to an image! The alternative I’m suggesting, one that forces FE and BE (ideally one team) to talk about the user experience, is to have a “profile.photo” schema that is resolved on the server. The result of this pattern is a GraphQL schema that accurately describes the user experience. I took the dumbest example possible, but in short, this pushes a lot of complexity to the server where it truly belongs. The FE should be as light, dumb, and functional as possible. The BE should understand comprehensively how their data is going to be used in order to design data models that are efficient. Moving from a denormalized GraphQL schema to a UX GraphQL schema is a liberating experience for everyone involved. The BE cares about the product as much as the FE. This gets them that much closer to the user, where they ought to be. And to your point, this enables the BE to identify potential resolver bottlenecks (and to design for them rather than hacking around them) before such problems ever appear.
turtlebits 6y ago
Every time Javascript is discussed, the discussion turns negative. Fact of life is that the browser is THE cross platform app, and people have differing opinions on how things should be done.
- jtdev 6y ago
  Many are just exhausted with WordPress turned React devs writing piles of spaghetti code rife with unnecessary (and often poorly maintained) dependencies.
- erikpukinskis 6y ago
  It’s because the majority of jobs are front end web jobs, which is annoying you don’t do that kind of work. And you kind of wish people on the FE would just do things that backend way so you could have access to that job pool.
kemitchell 6y ago
So many date libraries.
trylist 6y ago
Am I missing something about graphql being in the same metric as redux? They're not remotely in the same domain, are they?
- hamandcheese 6y ago
  It makes a little more sense when you consider the wider graphql ecosystem, like Apollo or Relay, which normalize all data received and keep your UI up to date automatically. In that light, graphql-the-ecosystem has solved a big part of frontend state management. With graphql and react hooks, I have found no need for redux anymore for typical CRUD needs.
  - trylist 6y ago
    That's what I was kind of thinking, but Apollo is also in the same graph. Seems a bit odd to me.
habosa 6y ago
It's pretty clear that we're in a period of relative stability. React and TypeScript have been the tools of choice for 2-3 years now. Webpack is the clear choice in bundler. Most people seem to be using the modern language features. You can see that the number of extremely satisfied or dissatisfied people has gone down, people have moved towards the middle as the big tools have matured. It's nice. I feel like I actually get the JS landscape right now (I'm a Vue person but still). I'm sure in 2 more years everything will blow up again though!
- Silhouette 6y ago
  I would like to think that the next big change will be the slow but steady replacement of JS/TS by one or more much better languages. Even with the current relative calm in front end web development, JS is still a terrible language for almost everything that matters. TS is a noble effort to put lipstick on a pig that achieves some useful benefits, but only at the expense of adding even more complexity, a sometimes clumsy syntax because of the JS legacy, and an illusion of being safer than it actually is again because the decision to favour JS compatibility means you can break the type system. Momentum is a huge factor in programming language popularity, which unfortunately tends to hold back real progress, sometimes for decades. That's why we still write front end code in JS, and why we still write systems code in C. But with the progress of WASM, I think there is a genuine opportunity to create something so much better than JS (or anything that compiles to JS) that it might eventually take over, even if it takes more like 2 decades than 2 years to achieve success.
  - franklyt 6y ago
    JS isn’t going anywhere.
    - Silhouette 6y ago
      Not any time soon, certainly. But it really should do. It's a language that was designed hastily and without a solid foundation. That was no big deal at the time, but it causes a horrible loss of quality and productivity now that it has become one of the most-used programming languages in the world. JavaScript has a quirky and highly dynamic type system, with lots of edge cases that can cause surprises. See the famous "WAT?" presentation for some examples, though that was only a few minutes long and so could only scratch the surface. JavaScript has awkward syntax, which makes it unnecessarily difficult to write tools and libraries to support it, as well as creating unusual complications like ASI. Modern JavaScript is trying to be half-imperative, half-OO and half-functional programming, and there isn't enough sensible grammar to go around. This makes various idioms you'd often use in each style in other programming languages awkward in JS, while at the same time not providing some of the best features found in languages more specialised for each style. JavaScript has a tiny standard library, and what it does have has plenty of inconsistencies and quirks. This, more than anything else, has led to a catastrophically complicated landscape of large JS programs importing on hundreds of relatively small libraries via transitive dependencies, in a tangled mess that probably no-one has ever even looked through on most projects. That's how you get the left-pad fiasco, but more generally, it's a staggering hit on productivity because everyone has to jump through hoops to do even quite simple tasks and often people choose to jump through slightly different sets of hoops that get a similar end result, so now you have multiple ways of doing the same things in your code and extra bloat in your build. It's also a legal and security nightmare just waiting to happen. TypeScript inherits almost all of the above. It does improve on the type checking, obviously, but even there its type system is actually unsound because its developers made the choice to prefer JS compatibility rather than a completely foolproof type checker. I think that was a reasonable choice, but it doesn't change the fact that the one big feature TS brings to the table is actually flawed because of its JS legacy. None of this should be surprising to anyone who programs JS/TS regularly, but since my previous comment got heavily downvoted I feel the need to defend it with more concrete and objective criticisms. Given the importance of web development in the modern software landscape, I truly believe that adopting much better languages -- languages designed carefully, built on solid theoretical foundations, learning the lessons from decades with JS and other programming experience since JS was created, equipped with a good standard library and essential tools -- could bring a qualitative improvement in many important respects, particularly productivity and reliability, across what is now a vast part of the software industry. I'm not crazy and have no illusions that this will just magically happen tomorrow, but with the advent of WASM, there is at least a chance that with a big backer or two behind it, something new might have a shot at becoming established and, in time, attracting enough support to take over.
geonic 6y ago
Svelte is pretty cool. I‘ve only used it for a small app so far but it was very easy and quick to work with. I don‘t know how well it will scale for larger and more complex apps though.
nathias 6y ago
I hate TypeScript so much. It feels so antithetical to the web, produces so much redundant bloat to solve a problem that maybe appears for some of the apps with huge codebases, and fails horribly with its obscure error messages.
- AltruisticGapHN 6y ago
  Many many moons ago I wrote C and C++, typed languages right? I don’t remember typing my code being so abstract and complicated. Take php 7+, has good typing features and is way, way easier to understand. All I want is native js interfaces, namespaces and basic types, then F### typescript :) Seriously somtimes as nerds we like something because its complicated and presses our dopamine buttons when we figure it out, but then what is the practical outcome? Problem is there seems to be no middle point? I can’t write vanilla js now on new project, typing structures like json messages is bare minimum. The problem with Ts is even if you don’t want to use it "like an expert" there is no beginner use, you will very quickly run into complicated abstractions and all kind of typescript errors due to fluidity of js language. So I think native js typings is our only hope but when you see how crappy some vanilla js syntax is, what they did with classes, I’m not holding my hopes up.
  - nathias 6y ago
    For me it would make sense for it to be a plugin for your IDE, not a language, and now its something in-between. This trend also goes against the development and adoption of writing with languages that have actual types and their ecosystems.
  - machiaweliczny 6y ago
    There's middle ground with TS. Just allow implicit any and use JSDoc.
    - AltruisticGapHN 6y ago
      I tried JSDoc. I liked it at first but soon it became unusable. Even putting aside how verbose it is, the problem is the IDE support was not working. Trying to document eg. Vue props with JSDoc, there was no completion. Seems to me JSDoc in VSCode was working great for vanilla JS, but as soon as you use Vue, there are so many completions that were not recognised that it defeats the purpose. I mean, the IDE autocomplete where the IDE knows what members are in a given object, makes the work of typing the code all worth it. If it works only half the time, then it becomes pointless. TypeScript is ok, but as soon as you have to do like DOM manipulation, then you get into the rabbit hole :) Figuring out all the ways those DOM apis are dclared, why they have many signatures sometimes for the same function... Then again I suppose that's how you really learn TS. Like if you wanted to declare an array with a default value in a Vue prop with JSDoc: props: { items: { /\* @type {{ new(): string[] }} \*/ type: Array, default: function() { return [] } It took some time to figure out how to do it with JSDoc (eg. above you can't use arrow function to declare the default value. Then you need to figure all kind of shenanigans with Vetur/eslint... just wasn't worth the hassle, may as well use TS.
antihero 6y ago
5% of JS programmers are women? How the fuck did it go so wrong?
- agumonkey 6y ago
  Why should it be any different ? methinks the 95% others are too busy writing ada95
- rk06 6y ago
  5% of people who took the survey are women. the survey didn't reach all of the js programmers for sure.
rhacker 6y ago
A large mistake in React's history is definitely it's history with redux and any API like it. You can see that it's very quickly being shed away from React in these charts which I'm very happy about. Redux is like a global variable and it's painful and clumsy.
- Silhouette 6y ago
  The big problem with traditional global variables is the way any code can change them arbitrarily, making it near impossible to understand the state management in a large program. I would argue that a library like Redux on the front end is more like a database, in that while it can be accessed from anywhere, in reality there is a structure to interacting with it and there has to be an explicit intention to modify the current state, which can been found via tools or even just a grep of the source code.
- williamdclt 6y ago
  > Redux is like a global variable This meme needs to die. You can argue that it's painful and clumsy, but not that it's "like a global variable". The _whole_ point of redux is to offer global state without the problems of global variables. Interacting with the global state through actions, selectors and subscribers prevents the problems of global variables. Is it clumsy/verbose/confusing/whatever? There's definitely arguments for it. But people stop thinking when they see the word "global" and make terrible arguments against Redux.
theshadowknows 6y ago
Every year I see these reports come out and every year I'm more jealous of JavaScript/front end developers. I know the landscape is complicated and hard to keep up with, but damn it's just so cool the possibilities you guys have. I am comfortable with c/c++/python/sql/java in an enterprise context. Might some folks help me get back into the JS world? Do I need to sit down with a JavaScript 1.0 book and go from there?
- kristiandupont 6y ago
  JS is now old enough to have evolved significantly from its origins. So just like you should be cautious with learning c++ "from scratch", so should you be with JS. Other than that, given your skillset it should be fairly trivial to get the language basics down. Diving into the libraries and frameworks will probably be where you will spend your time :-)
- notapenny 6y ago
  There's a lot out there for sure but a lot of it is also fairly established. I agree with Kristian here that with your set of languages it shouldn't be hard to get into, personally I found "You (still) don't know JS" a great introduction, even if you read just the first few volumes and if typed JS is your thing the TS docs should get you going. I you're keen to stay server-side, NestJS could be interesting, its picking up a lot of steam, otherwise the ReactJS docs are as good as anything to get going in the front-end. Honestly just play around and try not to let the size of the landscape get to you. Unlike some JS devs seem to believe, you don't need to know everything about everything to get going.
miohtama 6y ago
I really love the wrist friendliness of Svelte. Are there yet any good UI frameworks/libraries to use with it?
mcdoker18 6y ago
As BE, I was surprised how many FE developers use PWA. I need to take a look at this technology. By the way, I am happy that the usage of typescript increases over time.

168 points by milkers 6y ago

First paragraph reads as follows: Crappy last year, blah, TypeScript. Nothing interessting about JavaScript... Did not read further.

brdd 6y ago
Well you must be very fun in meetings.
- Aldipower 6y ago
  At this point I already left the meeting.
  - Daho0n 6y ago
    More like got kicked out.
typeengineering 6y ago
yeah exactly, typescript is n1 enemy of javascript, but they praise it in the very first paragraph... this is the state... of javascript...

milkers 6y ago

Some takeaways of mine; - Typescript keeps strengthening its position as industry standard. - Svelte is hyped, but is it battle tested enough? - Testing Library is quite new in the town but already the runner up testing tool. - In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest. What are yours?

Pfhreak 6y ago
I've seen Svelte used in a number of high impact tools, including in AAA videogame UI. In my experience, I've seen engineers very happy working with it, and it meets the performance needs for a videogame it should be good enough for the web.
- ha4fsd3fas 6y ago
  Do you have any info on that AAA game? I would be curious to read up on how/why they used svelte.
- preommr 6y ago
  > including in AAA videogame UI elaborate, please, because this sounds so bizarre. Are they bundling an entire web view and then interfacing it with their game engine? Not only is the tech conceptually weird, I can't think of too many AAA games that have very complex UIs other than maybe the CK series.
  - turtlebits 6y ago
    A lot of games have storefronts for DLC. I've seen these used as webviews, especially payment forms.
  - Macha 6y ago
    It doesn't surprise me. 5 years ago the standard solution was Scaleform, which is pretty much the same thing but with Flash.
  - vbezhenar 6y ago
    It might be for main menu. I think that WC3 reforged used webview for its menu.
    - Pfhreak 6y ago
      Main menu but also in game UI. Ability timers, weapon reticles, health bars, etc.
  - 6y ago
sevencolors 6y ago
> - Svelte is hyped, but is it battle tested enough? Try asking the NYTimes how it's working out for them
- milkers 6y ago
  First, I hate paywalled news sites. Second it sounds more like inbreed than a battle thanks to reddit friends. `The creator of Svelte, Rich Harris, actually works there!` `I think it was a passion project from a web dev at NYT` I would still like to hear more about it, will dig further, thanks.
jtdev 6y ago
> “In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest.” Not sure what you mean by “data management” here, but fetch/REST seem like to most predominant, simple, ubiquitous means of handling external data.
- _nalply 6y ago
  When I read that I immediately thought about GraphQL subscriptions. I don't know whether this will a bottleneck, but perhaps it makes sense to route everything through GraphQL, this means: someone updates via GraphQL and everybody listening gets an event by subscriptions.
williamdclt 6y ago
> Testing Library is quite new in the town but already the runner up testing tool We've been using Enzyme for a few years at my company. Very recently a new guy introduced testing-library, and oh my god it is so much better. For one thing, it actually allows to render component on react-native (Enzyme's `mount` doesn't work for some reason) and that's reason enough for me to switch.
davidwparker 6y ago
Svelte is hard to get passed the hype until you build a reasonable size project with it. Personal anecdote/plug: I built https://www.listenaddict.com/ https://www.listenaddict.com/ last year with Svelte. It's medium-ish sized (majority of the app is the moderator and administrator pages). It's extremely fast to develop (and will only be faster with SvelteKit+Snowpack). It's trivial to implement components and stores make state management a breeze. Having done React for ~4 years, and some Vue projects, I won't be going back to those anytime soon. That said, it's not without its own issues, but anything I've had issues with I've been able to solve relatively quickly or have someone within the community help.
- tjchear 6y ago
  Looking to jump into Svelte and would appreciate your opinion. What did Svelte do better than react and vue that you won't go back to them anytime soon?

systemvoltage 6y ago

Cliche rant coming up: as a backend engineer, recently started working on frontend. Is this how yall do things? Everything so far feels less mature, thinly pieced together, barely holding up, fast moving, unnecessarily bloated, and no care for longevity, robustness and discipline. Seems like every thing is on Youtube, no real good books (yeah, go ahead and search for "React JS" books on Amazon and see if you find something solid that is well praised). It's these 8 hour fucking Youtube videos that I need to watch and probably not remember anything. I watched one of those and its horrifying what kind of stuff these people are teaching. I am obviously generalizing, sure there are some really smart people involved in Frontend tech, but boy if you take a sweeping look from ten thousand feet, it ain't pretty. Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this? /rant

dboreham 6y ago
Moving fast and breaking stuff.
kag0 6y ago
As a backend engineer who has worked on frontend recently, yes, that's how they do things. There is some hope though, recent standards like web components and ES imports help a bit.
factorialboy 6y ago
I think it's about individual maturity than tech-stack. Frontenders are likely to be younger than backenders, and some of the traits you observed are a result of that.
- cosmodisk 6y ago
  Maybe,but it's not the kids who sit at the top of the food chain in places like language committees, standard agencies, or even the CTOs of this world ( the real ones,not those of 5 person startups) where things get decided for years or even decades ahead.

bhauer 6y ago

As someone who is relatively outside of the JavaScript ecosystem, I had the following realization yesterday when I was reviewing this: JavaScript has what I would consider two distinct flavors of "back-end" frameworks. It has frameworks like Express and Koa, which I would consider traditional back-end frameworks. These are designed around handling HTTP requests and providing dynamic responses in myriad forms: rendered content as HTML, API responses as JSON or other forms, etc. And then there are what I would call back-ported front-end frameworks, or semi-static site hosts. These are Next.js and Nuxt. As far as I can tell, these can be used to build traditional server-side application logic but they seem intended to host "pages." For example, in looking over Next, I see it does have the ability to expose API routes, but this seems very much a second-class citizen. The Next documentation [1] says "Next.js has support for API Routes, which let you easily create an API endpoint as a Node.js serverless function." This seems to be provided as an escape hatch, but it doesn't appear to be the core focus of the framework. Is this distinction real or am I sadly misinformed of the, ahem, state of JavaScript? [1] https://nextjs.org/learn/basics/api-routes https://nextjs.org/learn/basics/api-routes

Eric_WVGG 6y ago
Yeah, that's about right. I was also surprised to see Gatsby and Next.js listed in backend, but it makes a weird kind of sense. I think "static site generators" would be a better umbrella, but it's a shady distinction for sure. And your summary of Next.js API Routes is correct as well. As an example, I have a site built in Next that needs to be able to query data off of a SQLite database. Back in the old days I would have set up a simple PHP server of some kind… today I might have knocked something crappy together in Node… but in Next, you just point at a route, grab the SQLite database out of the filesystem, and look over your query parameters. It's really neat.
robin21 6y ago
Next.js is mostly about server side rendering. If you look at something like nest.js it offers a more familiar backend with more structure. Because you can write your backend these days as serverless functions which just make api calls to other hosted services - the traditional backend framework (orm + routing) becomes less relevant.

deleted 6y ago

[deleted]

ehutch79 6y ago

Vue is the 3rd in framework ranks... and like the 16th ranked? "Testing Library" is the top testing library apparently? Had to check that this was an actual library, I'm sure many people just left it as a 'whatever' choice. Someones data is dirty dirty dirty

sevencolors 6y ago
Testing Library is an excellent library from Kent Dodds, it's also one of the testing tools recommended by the React team https://reactjs.org/docs/testing.html https://reactjs.org/docs/testing.html
jtdev 6y ago
> “Someones data is dirty dirty dirty” Par for the JavaScript community course.
notapenny 6y ago
I don't think it would be a "whatever" choice personally. I didn't take the survey this year, but other years you had to explicitly specify what your level of interest/satisfaction with a particular technology was. Personally I'm not surprised that testing-library came out so high in satisfaction; its an incredibly useful layer over Jest and and incredibly popular in React-land.
- ehutch79 6y ago
  I mean, if you don't know it's a library, you may think this is the 'other' choice.

tus88 6y ago

I thought it had been renamed Typescript?

cosmodisk 6y ago

If the healthcare sector would apply the same ideas and principles of the front-end industry, it'd look like this: oh,look, it's a pen! Why don't we combine it with a scalpel and an angle grinder for our next surgery? Front-end is an absolute shit show with all the html/css/js mixture.

Aldipower 6y ago
You mean _Web_ Front-End. Do not forget Web is delivering to a lot of platforms. Try the same with desktop apps or mobile apps. Good luck.
- cosmotic 6y ago
  The trend seems to be using HTML/CSS/JS for "native" app frontends as well, see Electron an the countless apps that use it.
- cosmodisk 6y ago
  I get it, there's mobile, desktop, even fridges,or doorbells that require front-end interfaces. I also understand it's not easy.im fact it's hard.very hard. But currently it's a shit show nonetheless, because everyone is going their own director with no plan to somehow unify or at least standardise the whole thing. And it's getting more and more absurd every day.
tashoecraft 6y ago
Your opinion is unoriginal and unhelpful. Show me another platform with the reach and usability as the web.
jakelazaroff 6y ago
And yet, there’s no other platform where you can go from an idea to something easily accessible by anyone in the world — in a span of minutes.

typeengineering 6y ago

1. Optional Chaining and Nullish Coalescing is everything that they could come up with in the last 5 years. Private fields in javascript. God please what is wrong with these people. 2. If you look at resources, you have css-tricks as n1. Clearly there's very little number of Software Engineers / Computer Scientists in the JS world which doesn't have to be because if you're skilled you can take massive advantage of the cool prototypal programming language like JS. yet I bet 95% of the JS "community" hasn't even got a clue what a prototype is. 3. Additionally, you can see how the tools are skewed towards react/webpack but server-side JS can be just as powerful, yet there isn't much innovation in there. So that confirms the previous 2 points that the "state" of javascript, is just a homogeneous webpack/typescript bunch of people who think the exactly same. There are so many real engineers who work with proper programming languages, and they get terrified when they see the "state" of javascript and curse it. I've worked with JS for the past 5 years and I don't blame them. There hasn't been a professional approach to software development in the JS world, everyone's obsessed with their tools instead of applying skill. But I'll change it this year. If you're a back-end engineer looking for a simple, yet very powerful solution to build your js/widgets, you'll get it soon. not free thank you.

erikpukinskis 6y ago
This seems unnecessarily mean and dismissive. I have a software engineering degree, have been doing professional software engineering for 20 years and I love JavaScript. There are lots of things I dislike that are written in JavaScript or for JavaScript developers but I like the language. What are you trying to get out of insulting people like me? Are you trying to get us to come seek you out as a teacher? Do you want us to feel ashamed of out careers and realize we need to go back to school?

somehnrdr14726 6y ago

If I were trying to compare technologies I might focus on metrics like release strategy, documentation quality, scale of existing products using it, and maintainer activity. This survey comes out every year and tells me who is winning the social media popularity contest. Technologies labeled as "Avoid" have over 50% respondents saying they don't even use the technology. Avoid it why? Because I won't be trendy at the javascript meetup? Does anyone actually use this data to drive decisions?

preommr 6y ago

It seems like the overall trend is that people are getting more and more unsatisfied with the current landscape now that a little bit of the sugar high from first wave of shiny new tech is starting to fade away. The jump from "whatever js was in 2014" -> angularjs junk -> react/vue/angular was pretty big. But now the glamour is gone and we're moving into the phase of actually having to maintain some of the things we built and the wear from bad decisions is starting to show. ----- Svelte also seems like the cool new kid on the block. Svelte surprises me in how much people fawn over it. I really don't understand the hype since I don't think it's a huge jump forward, and there's also a lot of "misunderstandings" about it in comparison to other frameworks. Like one thing I've seen a lot is people mention how it requires less code, but it's not that much smaller. It just looks smaller for small test cases where there are like 8 lines of code or because svelte makes stylistic choices that have tradeoffs that aren't immediately obvious. If you take a loot at react/vue, they're not that much bigger for realistic component size. Anyways, front-end framework discussion is long and muddled and confusing. I wanted to make a point of how svelte people often confuse the engineering/implementation vs the philosophical approach in frameworks. Things like svelte's bundle size being smaller is because other frameworks don't put as much emphasis on it. I was going to say that react is bloated and that preact is much smaller, but looking it up it seems like somehow react is 2.6kb, preact is 4kb, and svelte is 1.5kb. Angular is 62kb. Which proves two points, react/vue can be smaller if it wants, the approach it takes doesn't limit it and that things move so fast that somehow preact makes bigger bundles than react.

turtlebits 6y ago
Svelte is a a breath of fresh air because of its simplicity, not because it's bundle size (which is a bonus). It's especially easy to get up and running and the documentation is great. React/Vue/Angular you have to learn the build system as well as the ins and outs of the framework, and there are too many opinionated ways of getting started.
- preommr 6y ago
  How is this complicated: ``` <script src="https://cdn.jsdelivr.net/npm/vue@2.6.12/dist/vue.js"></script> https://cdn.jsdelivr.net/npm/vue@2.6.12/dist/vue.js"></scrip... var app = new Vue({ el: '#app', template: "{{message}}" data: { message: 'Hello Vue!' } }) ``` A lot of the build problems with react/vue also exist with svelte. In fact it's even worst with svelte because it's compiled only (which is it's unique selling point) whereas vue can be used in a much more progressive manner. React is a little bit harder because of jsx, but it's still not that much more complicated. Build-wise, parcel supports jsx/vue files out of the box. Plus React/vue both have cli tools that I don't like and wouldn't recommend, but are super easy to get started with. And this all comes with the giant caveat that react/vue make progress which can lead to confusing versions. Svelte is a lot younger (kind of, it came out a few years back, so idk) so it hasn't had to cross that bridge yet. And even then, there was the confusion with Sapper. I highly doubt that svelte is going to be immune from the fast-paced nature of these frameworks.

wildermuthn 6y ago

I’ve been doing web FE in various capacities for about a decade. First jQuery, then backbone, then Angular, then ClojureScript with React, now React and Apollo. While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes. Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React addressed state complexity, and GraphQL finally forced backend engineering to coordinate with frontend engineering (i.e., making full-stack engineering efficient). People don’t switch tooling and frameworks for fun (well, not primarily), but because the pain of learning something new is worth the benefit of reducing unnecessary complexity. What I don’t think non-FE engineers often appreciate is just how essentially complex user-dictated mutable state is. Even with immutable data structures (which I love), you can’t get around the fact that a web-app is, by its very nature, a canvas that changes according to human activity. The difference between FE and BE is the difference between painting with fingers and flipping a switch with fingers. Updating a user’s role on the BE is a single SQL operation, but for the FE, it might mean countless changes to the user experience. It’s the difference between storing data and using data. And if there’s anything to conclude from the overwhelming amount of work done on FE tooling, it’s not that people love to try new things (although we do), it’s that the struggle is real. Side-note: BE gets a taste of FE complexity when dealing with syncing live mutable data among multiple clients. That’s a beast, and the point where everyone realizes that full-stack is the only sensible way to work.

viraptor 6y ago
> GraphQL finally forced backend engineering to coordinate with frontend engineering I'm curious what do you mean here? The way I see it is the exact opposite - front-end making new kind of queries without having to coordinate with backend. With positive effects (faster results) and negative ones (so this new query takes a minute to resolve and it's in production - fix it now!)
- wildermuthn 6y ago
  My view on this may be idiosyncratic and wrong, as I haven’t read about other teams doing this intentionally. Having said that... The most powerful but underused feature of GraphQL is that it abstracts away the details about the BE database model, which is for the FE (i.e., the product and user experience) an unnecessary implementation detail. A poorly designed GraphQL schema (and my teams did a lot of this at first) often look like denormalized REST endpoints. This is particularly true in Relay (do people still use Relay?) In such a case, you’re right that FE-BE coordination doesn’t change much. Additionally, FE stores like Redux are still central to managing derived data necessary for component rendering. However, a well-designed GraphQL schema looks like the shape of data required for component rendering, i.e., for the user experience. Example: having top-level queries for “users” vs. “profiles”. The first has all the data about a user, the second has all the data required to render a user profile page, which almost always includes more data. Let’s say there is a profile photo. A denormalized scheme just defines a "user.profileImage" as an Image type and returns data from a DB relationship of a similar sort (knex and other tools make this easy). While this might seem fine, it is the start of the same old story — BE being blissfully unaware of the use of its data in the context of the user experience. Perhaps when a user has no profile photo a default one should be shown based on their “organization” profile photo. No problem, just pull “user.organization.profilePhoto”? Well, okay, but maybe that is missing too, and we... go down a FE rabbit hole when all we really want is a stupid URL to an image! The alternative I’m suggesting, one that forces FE and BE (ideally one team) to talk about the user experience, is to have a “profile.photo” schema that is resolved on the server. The result of this pattern is a GraphQL schema that accurately describes the user experience. I took the dumbest example possible, but in short, this pushes a lot of complexity to the server where it truly belongs. The FE should be as light, dumb, and functional as possible. The BE should understand comprehensively how their data is going to be used in order to design data models that are efficient. Moving from a denormalized GraphQL schema to a UX GraphQL schema is a liberating experience for everyone involved. The BE cares about the product as much as the FE. This gets them that much closer to the user, where they ought to be. And to your point, this enables the BE to identify potential resolver bottlenecks (and to design for them rather than hacking around them) before such problems ever appear.

turtlebits 6y ago

Every time Javascript is discussed, the discussion turns negative. Fact of life is that the browser is THE cross platform app, and people have differing opinions on how things should be done.

jtdev 6y ago
Many are just exhausted with WordPress turned React devs writing piles of spaghetti code rife with unnecessary (and often poorly maintained) dependencies.
erikpukinskis 6y ago
It’s because the majority of jobs are front end web jobs, which is annoying you don’t do that kind of work. And you kind of wish people on the FE would just do things that backend way so you could have access to that job pool.

kemitchell 6y ago

So many date libraries.

trylist 6y ago

Am I missing something about graphql being in the same metric as redux? They're not remotely in the same domain, are they?

hamandcheese 6y ago
It makes a little more sense when you consider the wider graphql ecosystem, like Apollo or Relay, which normalize all data received and keep your UI up to date automatically. In that light, graphql-the-ecosystem has solved a big part of frontend state management. With graphql and react hooks, I have found no need for redux anymore for typical CRUD needs.
- trylist 6y ago
  That's what I was kind of thinking, but Apollo is also in the same graph. Seems a bit odd to me.

habosa 6y ago

It's pretty clear that we're in a period of relative stability. React and TypeScript have been the tools of choice for 2-3 years now. Webpack is the clear choice in bundler. Most people seem to be using the modern language features. You can see that the number of extremely satisfied or dissatisfied people has gone down, people have moved towards the middle as the big tools have matured. It's nice. I feel like I actually get the JS landscape right now (I'm a Vue person but still). I'm sure in 2 more years everything will blow up again though!

Silhouette 6y ago
I would like to think that the next big change will be the slow but steady replacement of JS/TS by one or more much better languages. Even with the current relative calm in front end web development, JS is still a terrible language for almost everything that matters. TS is a noble effort to put lipstick on a pig that achieves some useful benefits, but only at the expense of adding even more complexity, a sometimes clumsy syntax because of the JS legacy, and an illusion of being safer than it actually is again because the decision to favour JS compatibility means you can break the type system. Momentum is a huge factor in programming language popularity, which unfortunately tends to hold back real progress, sometimes for decades. That's why we still write front end code in JS, and why we still write systems code in C. But with the progress of WASM, I think there is a genuine opportunity to create something so much better than JS (or anything that compiles to JS) that it might eventually take over, even if it takes more like 2 decades than 2 years to achieve success.
- franklyt 6y ago
  JS isn’t going anywhere.
  - Silhouette 6y ago
    Not any time soon, certainly. But it really should do. It's a language that was designed hastily and without a solid foundation. That was no big deal at the time, but it causes a horrible loss of quality and productivity now that it has become one of the most-used programming languages in the world. JavaScript has a quirky and highly dynamic type system, with lots of edge cases that can cause surprises. See the famous "WAT?" presentation for some examples, though that was only a few minutes long and so could only scratch the surface. JavaScript has awkward syntax, which makes it unnecessarily difficult to write tools and libraries to support it, as well as creating unusual complications like ASI. Modern JavaScript is trying to be half-imperative, half-OO and half-functional programming, and there isn't enough sensible grammar to go around. This makes various idioms you'd often use in each style in other programming languages awkward in JS, while at the same time not providing some of the best features found in languages more specialised for each style. JavaScript has a tiny standard library, and what it does have has plenty of inconsistencies and quirks. This, more than anything else, has led to a catastrophically complicated landscape of large JS programs importing on hundreds of relatively small libraries via transitive dependencies, in a tangled mess that probably no-one has ever even looked through on most projects. That's how you get the left-pad fiasco, but more generally, it's a staggering hit on productivity because everyone has to jump through hoops to do even quite simple tasks and often people choose to jump through slightly different sets of hoops that get a similar end result, so now you have multiple ways of doing the same things in your code and extra bloat in your build. It's also a legal and security nightmare just waiting to happen. TypeScript inherits almost all of the above. It does improve on the type checking, obviously, but even there its type system is actually unsound because its developers made the choice to prefer JS compatibility rather than a completely foolproof type checker. I think that was a reasonable choice, but it doesn't change the fact that the one big feature TS brings to the table is actually flawed because of its JS legacy. None of this should be surprising to anyone who programs JS/TS regularly, but since my previous comment got heavily downvoted I feel the need to defend it with more concrete and objective criticisms. Given the importance of web development in the modern software landscape, I truly believe that adopting much better languages -- languages designed carefully, built on solid theoretical foundations, learning the lessons from decades with JS and other programming experience since JS was created, equipped with a good standard library and essential tools -- could bring a qualitative improvement in many important respects, particularly productivity and reliability, across what is now a vast part of the software industry. I'm not crazy and have no illusions that this will just magically happen tomorrow, but with the advent of WASM, there is at least a chance that with a big backer or two behind it, something new might have a shot at becoming established and, in time, attracting enough support to take over.

geonic 6y ago

Svelte is pretty cool. I‘ve only used it for a small app so far but it was very easy and quick to work with. I don‘t know how well it will scale for larger and more complex apps though.

nathias 6y ago

I hate TypeScript so much. It feels so antithetical to the web, produces so much redundant bloat to solve a problem that maybe appears for some of the apps with huge codebases, and fails horribly with its obscure error messages.

AltruisticGapHN 6y ago
Many many moons ago I wrote C and C++, typed languages right? I don’t remember typing my code being so abstract and complicated. Take php 7+, has good typing features and is way, way easier to understand. All I want is native js interfaces, namespaces and basic types, then F### typescript :) Seriously somtimes as nerds we like something because its complicated and presses our dopamine buttons when we figure it out, but then what is the practical outcome? Problem is there seems to be no middle point? I can’t write vanilla js now on new project, typing structures like json messages is bare minimum. The problem with Ts is even if you don’t want to use it "like an expert" there is no beginner use, you will very quickly run into complicated abstractions and all kind of typescript errors due to fluidity of js language. So I think native js typings is our only hope but when you see how crappy some vanilla js syntax is, what they did with classes, I’m not holding my hopes up.
- nathias 6y ago
  For me it would make sense for it to be a plugin for your IDE, not a language, and now its something in-between. This trend also goes against the development and adoption of writing with languages that have actual types and their ecosystems.
- machiaweliczny 6y ago
  There's middle ground with TS. Just allow implicit any and use JSDoc.
  - AltruisticGapHN 6y ago
    I tried JSDoc. I liked it at first but soon it became unusable. Even putting aside how verbose it is, the problem is the IDE support was not working. Trying to document eg. Vue props with JSDoc, there was no completion. Seems to me JSDoc in VSCode was working great for vanilla JS, but as soon as you use Vue, there are so many completions that were not recognised that it defeats the purpose. I mean, the IDE autocomplete where the IDE knows what members are in a given object, makes the work of typing the code all worth it. If it works only half the time, then it becomes pointless. TypeScript is ok, but as soon as you have to do like DOM manipulation, then you get into the rabbit hole :) Figuring out all the ways those DOM apis are dclared, why they have many signatures sometimes for the same function... Then again I suppose that's how you really learn TS. Like if you wanted to declare an array with a default value in a Vue prop with JSDoc: props: { items: { /\* @type {{ new(): string[] }} \*/ type: Array, default: function() { return [] } It took some time to figure out how to do it with JSDoc (eg. above you can't use arrow function to declare the default value. Then you need to figure all kind of shenanigans with Vetur/eslint... just wasn't worth the hassle, may as well use TS.

antihero 6y ago

5% of JS programmers are women? How the fuck did it go so wrong?

agumonkey 6y ago
Why should it be any different ? methinks the 95% others are too busy writing ada95
rk06 6y ago
5% of people who took the survey are women. the survey didn't reach all of the js programmers for sure.

rhacker 6y ago

A large mistake in React's history is definitely it's history with redux and any API like it. You can see that it's very quickly being shed away from React in these charts which I'm very happy about. Redux is like a global variable and it's painful and clumsy.

Silhouette 6y ago
The big problem with traditional global variables is the way any code can change them arbitrarily, making it near impossible to understand the state management in a large program. I would argue that a library like Redux on the front end is more like a database, in that while it can be accessed from anywhere, in reality there is a structure to interacting with it and there has to be an explicit intention to modify the current state, which can been found via tools or even just a grep of the source code.
williamdclt 6y ago
> Redux is like a global variable This meme needs to die. You can argue that it's painful and clumsy, but not that it's "like a global variable". The _whole_ point of redux is to offer global state without the problems of global variables. Interacting with the global state through actions, selectors and subscribers prevents the problems of global variables. Is it clumsy/verbose/confusing/whatever? There's definitely arguments for it. But people stop thinking when they see the word "global" and make terrible arguments against Redux.

theshadowknows 6y ago

Every year I see these reports come out and every year I'm more jealous of JavaScript/front end developers. I know the landscape is complicated and hard to keep up with, but damn it's just so cool the possibilities you guys have. I am comfortable with c/c++/python/sql/java in an enterprise context. Might some folks help me get back into the JS world? Do I need to sit down with a JavaScript 1.0 book and go from there?

kristiandupont 6y ago
JS is now old enough to have evolved significantly from its origins. So just like you should be cautious with learning c++ "from scratch", so should you be with JS. Other than that, given your skillset it should be fairly trivial to get the language basics down. Diving into the libraries and frameworks will probably be where you will spend your time :-)
notapenny 6y ago
There's a lot out there for sure but a lot of it is also fairly established. I agree with Kristian here that with your set of languages it shouldn't be hard to get into, personally I found "You (still) don't know JS" a great introduction, even if you read just the first few volumes and if typed JS is your thing the TS docs should get you going. I you're keen to stay server-side, NestJS could be interesting, its picking up a lot of steam, otherwise the ReactJS docs are as good as anything to get going in the front-end. Honestly just play around and try not to let the size of the landscape get to you. Unlike some JS devs seem to believe, you don't need to know everything about everything to get going.

miohtama 6y ago

I really love the wrist friendliness of Svelte. Are there yet any good UI frameworks/libraries to use with it?

mcdoker18 6y ago

As BE, I was surprised how many FE developers use PWA. I need to take a look at this technology. By the way, I am happy that the usage of typescript increases over time.