Javascript is becoming the next c++, what a mess. I can now write a function in about 10 different ways.. In all their efforts to fix it, it only becomes worse. Loads of fancy new features (mostly copied from Coffeescript), but the basic type system is still not fixed!
I miss the simplicity, readability and power of Coffeescript. -> function without context binding, => function with binding. That's it! does?.this?.prop?.exist, nope still not possible in JS. Ah well, the community hates CS and loves all the amazing new features of ES+. Until you look at a random codebase out there of some outstanding JS dev's utilising all the latest features. One big mess of conflicting strategies, unreadable code, poorly documented, bloated, etc.. etc.. But hey, we're using promises, reducers and spread operators everywhere, we're super smart!
When will the JS community start improving on the quality of the code instead of adding new language features, tooling, frameworks and so on? Try to think of better names for your identifiers to start with, using an intuitive naming system throughout a large codebase so it becomes actually readable. No, will not happen, too boring I guess.
I'm writing Typescript now to pay the bills. Adding even more complexity, it scales so well, mainly because you can use the 'any' type. Said enough?
Honestly, I think the only thing that sticks out to me is that JavaScript treats addition and catenation as the same thing, and, humbly, I don't think they are. Maybe some folks here more intimately familiar with good type handling can give their two cents.
But, I've enjoyed dynamic typing in languages where values had types and variables didn't, and because there wasn't any consolidation of addition and catenation, everything was fine. Also type coercion seems to be a pain point in JavaScript for some, whereas explicit type conversion through function calls in other languages seems to remove these issues, in my experience.
And TypeScript seems to bring a lot of powerful concepts to developers who enjoy the benefits of strict typing, which is great.
But, languages that continually expand their grammar complexity and usage conventions feel harder to master to me. Now and again I come back to Lua's reference manual and learn something new that I don't see other developers in that space recognize, and that's the simplest practical scripting language I know. It's complex syntax in Backus-Naur form is one section of the reference manual.
ECMAScript literally has multiple chapters to explain its grammar. I just don't understand how you can truly master that. At least, you certainly would not know all of the edge cases with the language.
Svelte is the best JavaScript UI framework I've seen in many years, better than React, Vue, etc. I'm using it for real work. I would love to see Svelte on this list.
Hmm I briefly looked at it and I am certainly intrigued. I really like the simplicity of await blocks, but I have some reservations about the template syntax, namely that it reminds me a lot of angular.js. Syntax like
{#each cats as cat}
reminds me of ng-repeat, and of course there are other similarities.
I'm not necessarily saying that that's bad, but as a matter of personal preference I tend to prefer the html-into-JS approach of JSX / React over what is essentially implementing a subset of javascript as part of the template syntax.
I don't like that you have to ask what parts of javascript you are allowed to use within a template.
I like emphasis on performance by keeping things light on the browser. I feel many of the popular frameworks focus too much on abstraction rather than providing the best user experience for the end user (primarily load times and disregard for accessibility).
Mock me if you want but I found this survey confusing to take. The titles/subject areas are disjointed from the questions, then the first question is just the word "Reason." No explanation, just one word, "Reason." Took me longer than it should have to realize what was going on.
Just some feedback to share here for thoughts (I shared it in the survey): most of the time I didn't really care enough to give specific reasons why I did or didn't like something, and felt like it was a retention pain point in the survey.
If I like or dislike something, that should be enough. I know people want to know where things can improve, but honestly, a lot of the time the answer is "the whole damn thing is worthless to me, and there's too many cons to correct and not enough pros to validate its existence to me."
I realize that's not constructive, but if something is fundamentally unappealing, no amount of steering is going to fix that in my eyes.
The option of complexity really spoke to me. If you’re building a small one-off website, then you want something short of a framework like React, but something more modern than Jquery (manage state, reactive style programming). What can you use?
I feel modern client side JavaScript assumes you’re working on a large, long lived site that you plan to maintain. There’s no equivalent of “I just want to create something quickly for use by about 100-1000 people for a few weeks”
This is how I coach my team through this: use the right tools for the job.
Now what does that mean? Just displaying some data and accepting some input, or requirements are unclear? No js required. Now they want some interaction, like a hover effect? Use vanilla js, jQuery, or plain css. Requirements keep changing and you have more the 25 lines of js? Maybe start thinking about vuejs to enhance the page and using a simple script tag. Starting to have several hundred lines of js and you can't remember where in the file that function is, or you are required to minify? Start thinking of vuejs plus a build tool.
Do you need js everywhere? The answer is almost certainly no. Do you need to enhance a page with js? That's about a 50/50.
Obviously this is just my advice, but was born from working on small teams, at startups where requirements are often unknown, change frequently, and time to market matters.
Plenty who will disagree and say they do want JS everywhere. I can build my dom much more cleanly using nice declarative js than html with all its silly and inconsistent rules, and letting react do the rest. I'm happier writing my style rules as objects, then having emotion apply it to style elements. Much happier using JS for everything than some old html+CSS that uses JS to add a few bells and whistles.
I gave you an up vote, because that's the great thing about this industry -- there are many valid opinions and options for each problem. Its more about balancing tradeoffs then anything else.
Mine stems from working in the industry for nearly a decade, and shipping 100% js projects in a variety of frameworks (angular, react, vue and backbone to name a few). Most of the time, but not all of the time, I see iteration and maintenance costs far exceed simpler js enhanced pages.
If js everywhere works for you and your team better, then that's what you should do.
Oh I've been around a long time too, and I've definitely had that experience in the past. Presentation logic was the really _big_ one years ago. Few devs seemed at all bothered if their views were extremely complex, contained heavily nested conditionals, poorly componentised, etc. Presentation wasn't seen as "serious" code, because real devs did backends. As a result, so much of our available tools, libraries, docs, blog posts, etc. were valued based on how quickly you can churn out something that matches some mockup at one point in time, and that's it. You'd never make any significant updates, only create new pages to replace it. In this world, a completely separate dev (or designer) would throw together the HTML/CSS and the ecma dev would link up some events to the buttons.
I've really seen it flip after React matured, and everyone started transpiling w/ bundlers. I don't have some `colors.scss` with a bunch of constants, and then redefine those same constants in my .js anywhere -- I have a .js file with my palette. I don't embed logic into the template with a bunch of `<div ng-if` stuff anymore, I can use the same `if` I use everywhere else. All my static analysis for unreachable code detection, style guides, etc. runs the same everywhere.
I'd argue that those "simpler js enhanced pages" aren't so much simpler, as they are merely more familiar. 1 consistent approach in one language, that is equally (or more) suited for declarative code, is simpler than 3 languages with 3 approaches. One module that says `export default css({ p: { fontSize: '16px' } });` then importing it into another file is simpler than some scss `.MyBigClassName { p { font-size: 16px; } }` then remembering that classname in your HTML. `h('p', { onClick }, 'Hello!')` (or `<p onClick={onClick}>Hello</p>` in jsx) isn't more complicated than `<p class="foobar">Hello</p>` and some js elsewhere that says `$('.foobar').click(` or whatever.
I've taken this approach with my very intern/jr heavy team, and they all take to it really fast. It tends to be the older devs who are more resistant, because it requires changing old habits.
> I don't have some `colors.scss` with a bunch of constants, and then redefine those same constants in my .js anywhere -- I have a .js file with my palette.
Thank you for your reply. Do you have an example repo of using this pattern? I'm afraid I'm not terribly familiar with _not_ having any css files and instead defining it in a js file. create-react-app maintained by facebook doesn't seem to follow this pattern (unless I'm misunderstanding).
[emotion](https://github.com/emotion-js/emotion) is the main lib doing it now -- it's pretty popular among the React crowd, and sits at 5k stars right now. It's a nice, gradual transition, since it mostly follows scss-like syntax, and the docs all use tagged templates. e.g. `const className = css\`p { font-size: 16px; }\`;`, but `const className = css({ p: { fontSize: '16px' } });` works fine too.
What's cool is you can use the same obj conventions for the CSS as a React component's `style` prop, or a regular Node's style. e.g. if I have `const headerColor = { color: '#ff0000', backgroundColor: '#00ff00' };`, I can say `<div style={headerColor}>`, or `Object.assign(document.querySelector('p').style, headerColor)` too.
JS used purely as a declarative language is actually remarkably consistent. And if you have inconsistencies, I'd rather have the same inconsistencies than have 3 different languages to worry about.
If you're building a content-based site, use a static site generator. If you're building an application that genuinely needs front-end interactivity, then Vue is quick and easy. (See also nuxt and vuepress.)
Thanks for the suggestion. These sites are usually for quick and dirty prototypes within my company and won’t live very long. They usually have a little client side functionality because that’s what users expect.
100-1000 people a week seems like a lot. I’m mostly into ”something to impress my friends and forget about in a month” which—in my utopia—would account for the majority of all websites.
But when I was most active in having fun building websites for fun and showoff, about 3 years ago, I would use [microjs](http://microjs.com/#) quite a bit. I don’t know if that is relevant anymore though
EDIT: Vanilla JS is also a good option and has been getting exponentially better over the years.
Web Components are really a great option here. You don't need any library to use them, because they're built-in, or if you choose a library, they're very small.
What's funny about the JavaScript world is that there are basically two activities that happen: create yet another SPA framework and create yet another "script" suffixed language in which to code and transpile. Nothing is done to JavaScript itself at structural and semantic level. Even the standards seem to focus too much on peripheral aspects such as spread, arrow function etc which are no doubt useful but don't improve the language itself. The language is still as flawed and imperfect as it has always been.
Why don't anyone think of incorporating at least the low hanging fruits for which developers have to migrate to a different language and transpile? What they do add is halfa$$ed, like const. It boggles my mind. I created an experimental framework called JEEP to remedy the sort of things I am ranting about. Jeep has been happening in several iterations since 2015 and before every iteration I checked if the latest standards would make the framework redundant but sadly the need for Jeep only intensified. Finally I posted the 2018 version here on Show and elsewhere and the response was staggering, in that nobody gave a f.ck. I am not bitter, no, really, but just amazed as to what people find interesting and flock to and what they ignore happily. Admittedly, the framework is quite unconventional and needs some reading and experimenting to be done in order to be fully appreciated, leave alone adopt, and it may even be advocating the sort of things that an average JavaScript developer is not interested in, but the sheer lack of even "what the f.ck is this $hit" was astounding. Some stats: collectively there has been over 3500 views but only 2 comments and a handful of likes, stars, upvotes etc. I am sure it will get attention eventually, hopefully sooner rather than later, its been just 10 days yet, but the initial response is something that has made me recaliberate the priority of an average JavaScript developer.
Does anyone else get the feeling this survey is designed/run (or at least "sponsored") by the Facebook engineering team...?
It's heavily biased towards React, GraphQL & co. with a token mention of Vue.js and Angular so as to be less obvious.
Of course "the state of JS" is going to say "everyone is using React" if the questions are designed to collect that biased data...
@Keyframe React/Relay/GraphQL/etc, are Fb's "re-interpretation" of several Open Source technologies that already existed in the community e.g: Elm & RethinkDB.
Facebook gains each time a developer uses their "stack" because they extend the Fb ecosystem and widen the "talent pool" of potential engineers who can work on Fb's data-harvesting and Ad machines.
So when a "survey" is designed to promote the Fb tools by people who use Fb tools (scroll to the bottom of https://stateofjs.com ...) I cannot help but be a little "skeptical".
Facebook are trying to OWN the JS dev ecosystem just like try to OWN everyone's personal data! And they are "getting away with it" because no other (major) Tech company is doing anything to challenge them. :-(
Makes sense when you put it like that. Question here is why no other major tech company is doing anything to challenge that. Microsoft might be the one to step in, considering their JS involvement now.
I was surprised to see no mention of rxjs at all, considering observables (and pipelines) are phase 2. Somehow ramda is there, though.
I'm hoping the results show a lot of passion behind koa! I love that approach in general, especially since I find express pretty clunky for reporting errors from async operations. It still seems like the public hasn't really taken to koa yet, unfortunately.
It has improved in some ways but it's still incredibly fragmented, maybe more so with CSS-in-JS, TS, Flow, etc. Especially with the potential of languages like Elm, Rust, Go and others via WASM, it's going to be very hard to justify JS IMO—unless you understand the tradeoffs and still just prefer JS as a language then that's cool, the others aren't perfect either.
Odd how ClojureScript is in the survey, but Clojure is not listed in the possible “other languages” section. Oh, well. We Clojurians are used to being overlooked.
I added it myself. Another problem was in server-side support: I'd wager that most people who use ClojureScript have their backend written in Clojure, to leverage shared code.
ClosureScript is trying to replace JS for areas where you have to compile to JS such as front end and and Node.js, just as all other languages in that category.
Also I'm curious what kind of nefarious "bullshit" you think one can do with browser statistics. Market special weight loss pills uniquely targeted to Safari users?
Are you crazy? People buy data sets with browser statistics and location all the time, to augment other data sets that attempt cross-device user tracking. The more instances of browser fingerprints I have, the better I can tie you between different devices. I used to work for a company whose whole business model was essentially to buy data sets like this and normalize, join and aggregate them into much larger data products sold to third parties or queried in mobile SDKs.
There are whole companies that exist just to collect and aggregate disparate data sets like this to make cross-device advertising measurement more possible. If you can only match 0.01% of the users in some ad campaign, then being able to even just double that fraction by also finding the same users on other devices is hugely valuable. The signature of your browser stats, location, and choice of what to browse absolutely can enable this matching, and a host of other techniques (like matching to similar users if no exact match is found, and using machine learning on huge sets of traffic data to learn how to perform the matching).
It sounds like your lack of imagination is putting people at risk in a disturbing way to me.
I miss the simplicity, readability and power of Coffeescript. -> function without context binding, => function with binding. That's it! does?.this?.prop?.exist, nope still not possible in JS. Ah well, the community hates CS and loves all the amazing new features of ES+. Until you look at a random codebase out there of some outstanding JS dev's utilising all the latest features. One big mess of conflicting strategies, unreadable code, poorly documented, bloated, etc.. etc.. But hey, we're using promises, reducers and spread operators everywhere, we're super smart!
When will the JS community start improving on the quality of the code instead of adding new language features, tooling, frameworks and so on? Try to think of better names for your identifiers to start with, using an intuitive naming system throughout a large codebase so it becomes actually readable. No, will not happen, too boring I guess.
I'm writing Typescript now to pay the bills. Adding even more complexity, it scales so well, mainly because you can use the 'any' type. Said enough?