[throwaway8879]

The last time I did a bit of frontend for a side project was in 2004. Then I took a long break from dev and computers in general. Earlier this year I'd decided to brush up on the whole frontend/JS ecosystem. It was weird initially and there was a lot of friction, as I was especially fixated with a "why can't I stick this in a <script> tag, what even is NPM..." mindset.

I have the say, after getting the hang of typescript, react, Vue and the tooling in general, I don't exactly hate it as much as I was led to believe I would. Also, typescript is very nice.

[nexuist]

I continue to believe that the loudest perpetrators of JavaScript hate are those who overcomplicate simple things or follow other people's advice to overcomplicate simple things. Things like using SPAs for five page sites, throwing Redux into every CRA installation, npm installing useless packages like is-odd or leftpad (lol), etc.

You don't need to use <new framework on reddit>! You don't need JSX! You don't need <CSS alternative>! Surely you still don't need to support <version of IE released in 1997>!? Vanilla JS is fine! Most modern browsers have rich enough feature sets that you don't even need transpilers like babel or dozens of polyfills (or Webpack, which almost nobody needs unless you're averaging 10M+ views a month...)

Or maybe you do, or think you do. Maybe your bosses made these choices in the past. Maybe you had to compromise in a team. In which case, I get it. You call the shots or you're working for someone who does.

But don't blame the language, the frameworks, or the ecosystem. JavaScript stepped up to the plate because nobody else did. Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications. Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations. And there's so much stuff on NPM because everyone who works in this space for a few years always gets a brilliant idea for some abstraction that could fix everyone's lives. Many people who make packages on NPM have only a few months experience programming in general, which is why (1) we have so many dumb problems that "professional" software organizations avoid and (2) there are so many new frameworks all the damn time.

And that's a good thing! The whole point of our field has been to make computers more helpful to humans. A dumb little language like JavaScript (or Python if that's your cup of tea) is the perfect candidate to take any normal person and get them working on critical business problems, whether those require web dev skills or data science or anything in between.

For most of computer history, the role of today's pioneers has always been to offer up their shoulders for the pioneers of tomorrow to stand on. I'm sure bare metal logic electricians made fun of COBOL developers when it first came out, and COBOL developers made fun of C developers, and C developers made fun of Java developers, and Java developers made fun of Python developers...JavaScript is neatly filling the need for a "stepping stone" language that gives everyone the power to build their own applications, as opposed to using someone else's application which previously cemented the wall between "users" and "developers."

I'm excited to unleash a world where everyone has the power and know-how to develop their own applications, social networks, data processing services, etc. It sure beats a world where only an elite few have the power to manipulate society and capitalism to such a large degree.

-

Full disclosure: I'm currently writing a web service back end for my small business in Racket, so I'm not just a JS developer. However, I have 4+ years of Node experience professionally and recreationally, having built Express/React/Mongo web apps, Electron desktop apps, and React Native mobile apps, so I've experienced most of the ecosystem at this point I think. It's really not that bad.

[krapp]

>JavaScript stepped up to the plate because nobody else did.

Javascript didn't "step up" to any plate. Browser vendors simply refused to support other languages.

> Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications.

Electron is there because software developers wanted to create apps with cheap labor and there were plenty of javascript web devs around.

> Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations.

Node is there because of SV hype and money, and no company should (or would) have the same employee handling "literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations," nor does knowing Javascript qualify a single person for all of these roles.

That's not a use case, it's a power fantasy.

I agree with most of your comment, although it seems as if you believe there was no open source development or public development of software before javascript came along, and the line you're drawing between "javascript" and "elitists manipulating society and capitalism" is specious, but none of what's good about javascript excuses what's bad about the ecosystem, culture and the increasing centralization and control over both by corporate interests.

[corebit]

But seriously why can’t I just do modern webdev with a <script src=“”>?

[dbetteridge]

You can, no-one is going to leap out of the bushes and mug you for doing so.

That said, you lose some of the advantages that come with modern tooling and frameworks such as easily breaking things down into components, using the latest language features before browsers ship them (I'm looking at you mobile safari) and handling things like minification, tree-shaking etc.

BUT that is OK, if you are happy with the tradeoff.

[krapp]

You absolutely can, and should if you want to, just be prepared for people to look at you like you drive to work in an automobile made of logs and animal skins by pushing your feet against the road.

[recursive]

Wait, is there some other way to load scripts now? Asking for a friend...

[arethuza]

I suspect what corebit means is loading a script that has been manually created rather than a file that contains resources bundled by webpack or similar.

[WA]

You can, but have you tried it?

The biggest difference is: Before React/Vue, you usually told the UI how to change based on some action. Which is fine, but gets complex really quickly. Take something simple like a login form. Assume for a moment that there is a REST API for logging you in, so there’s no server-side rendered version of your login form. Now you want to make things a bit nicer for the user:

Obviously, the login form needs to be send via AJAX, because the REST API response delivers JSON and you don’t want to display raw JSON to the user.

There are two error states: no account with that email, wrong password. Assuming you take advantage of browser capabilities such as <input type="email" required> so you don't have to check this stuff in JS (although you might for styling reasons).

Your login form has 2 labels, 2 input boxes and a submit button.

Of course, while your send your login request via AJAX, you want to disable the login button, show a loading spinner, change the color of the button to the "disabled state". If there was an error, you want to re-enable the button, change its color and hide the loading spinner. Depending on the login error, you want to update the label text, the label color, the input border color. If the user enters something, you might want to update these three again so that it doesn't look like the new input still has an error. If the user entered the correct email, but a wrong password, you now need to: update all three to its original non-error state: the email label color, email label text, email input border color. You also want to update all three of the password field.

Futhermore, later you might introduce a toggle "show password", because people on mobile make mistakes when they enter their password. This turns the <input type="password"> into an <input type="text"> (or reverts it). If you click the toggle button, you also want to change the icon or the text of the button. Futhermore, if you submit the form, you might want to hide the password again. Whatever.

See, all of this can be done traditionally with server-side rendering. Some parts would be just fine, other parts are simply less convenient for the user. Sometimes, you don't get to decide to do it on the server, so you have to do it on the client in JS.

Now, do you want to tell the UI which part needs to update depending on what state you have? That is the traditional jQuery-style DOM manipulation way of writing UI code. In this very simple case of a login form, you usually have to update 6-8 elements for a very simple change in the state. This gets messy very fast.

What React/Vue/etc. solve is that you don't tell the UI how to update the DOM elements. You just say: newState = { emailError: 'Account does not exist', 'passwordError': null, formIsSubmitting: false } and write your UI so that it reacts to the state change.

Can you write this reactive code without a framework? Yes, you could, but honestly, give it a try. The fundamental question would be: Do you "hook" your code to the existing DOM or do you create all DOM elements on the fly in JS? Assuming the latter, you now have to write a lot of "document.createElement" calls. But do you want to re-create all elements when the state updates? You might lose stuff like the caret position in an input field. You might have to re-assign event listeners or whatever.

Thing is: Writing UI code that offers a great experience to the end user was never super easy to begin with.

[zubspace]

Thank you. Of all things I've ever read about react, your post is the first one who clearly explains WHY we need something like react and what fundamental problem it solves.

A frontend designer's job is to manage the state of the visible UI controls. There are lots of requirements which evolve and change during the lifetime of the project. You need to encode the application state and transition the controls according to the state. Before react, you mostly kept some variables around somewhere, added some ifs and elses which update controls, handle some events, update the state and you extend and extend and extend... and finally you have a bowl of spaghetti with some state sprinkled all around.

React separates the state from the UI update phase. Simple and elegant.

[grayed-down]

Amen brother!

[reificator]

> Surely you still don't need to support <version of IE released in 1997>!?

We exist. I'm still forced into document mode 5 by the top level frame.

[uxcolumbo]

What were your reasons for choosing Racket? Why not Clojure / ClojureScript?

[chocolatkey]

Even though I use quite a bit of modern JS, it's not the idea of react, vue or whatever frameworks and modern utilities that makes me dislike JS, it's what the author of the article mentioned under "stuff i’m still working through with react" that applies more generally to the community. Some examples:

- `I’m no fortune teller, but I have a hunch a lot of teams are going to spend the next few years untangling a constellation of former “new hotnesses”`: I have seen this multiple times now, where a medium article (I was in fact able to find the exact article based on the stack used and the year in question) inspired someone to create a site with what was (at the time) the trendiest framework. Fast forward 2 years, and things are a complete mess. Patching of the node_modules folder, overloaded MongoDB instances on overpowered servers (just..create an index..), and dependencies so out of date the npm warnings/errors fill your entire screen when you npm install. I tried so hard to "update" the application, but it was hopeless. Spent hours migrating react versions, alpha version of material ui, spaghetti code etc, and eventually gave up. I had never before completely given up on a codebase like this, but updating/migrating things every single month is stressful and takes actual time away from improving the functionality and features of your own code, which brings me to the second quote

- `Every team I work with tells me how hard they’re trying to keep up with the Joneses.`: I love the new possibilities JS has unlocked for creating cool programs that run in the browser. WASM, service workers, etc. are cool innovations, as well the frameworks and packages made by people far more talented than I could ever be. But the way this new ecosystem works, I am constantly pressured by peers to uses the latest, trendiest, best ever tools. I'm fighting to maintain projects less than a year old without the "no one uses sass anymore, use postcss!" "no one uses webpack anymore, use rollup!". For personal projects, I have free reign, but I have lost the battle for stability in the workplace where the majority are more concerned with migrating to a new build tool, framework, or paradigm rather than maintaining existing code. Not to mention the utter disregard of semantic versioning both in workplaces and by package maintainers, causes me to wince in fear when I type `yarn upgrade` because things are almost guaranteed to break if it has been over a month since the last time I did so. By the time I have fixed up things to work again (looked at every github/website for discussion of migration or figuring it out manually) I am exhausted and have ran out of time for working on the codebase iteself.

- `Not super into the quasi-religious vibe of it all` I already said this in the previous bullet point, but people swear by their tools, and want to convert you to their tool of choice. Instead of "that's a nice project, but here's criticism of such and such" you get "that's a nice project, but why didn't you use Framework X for it??" (because framework x didn't even exist a year ago). I do enjoy certain benefits of modern JS, but I don't enjoy being forced to go along with the flow when I don't want to.

- `Trying to figure out what’s a real trend vs a flavor of the month` This one you have to spend a few months on when you start off in the world of modern JS. Once you've found your personal favorite, stick to it! A great thing about the massive size of the JS community is there is some framework/toolset somewhere that will fit you.

[rainygold]

I guess a question for you would be why should someone choose a Node / full JS stack over Java Spring, or Django etc?

[jinglebells]

I've not found anything in JavaScript that replaces Django in terms of ecosystem and reliability. There's lots of attempts but Django and Rest Framework nail building out APIs.

Java executes faster than Node but is more verbose.

Choose the right tool for the job. I've put Node as a reverse proxy in front of Django, but now you can do JS in Nginx so I might not choose that pattern again.