I'm not sure about React's capability with this, but Vue can very easily run with no build stage. You can load Vue from a CDN and use a couple lines of JS to point it at a DOM element in your app. Then you can write a plain JS Vue object (what goes inside the <script> tags in a .vue file), and all this logic will apply inside the element you pointed it at. You can also write components, although that gets a little clunky without a build stage.

This has allowed me to do things like create Vue-based tools in a locked-down corporate environment where I was not able to install Nodejs on my machine.

React can be run from a single file from a CDN, and used without a build stage. Only catch is you don't get JSX. While by today's standard some people might consider that unacceptable, it was a fairly common way to use it when it was new (because relatively fewer teams used builds for JS back then, and JSX was far from being widely accepted).

My first year of React development was without JSX even though we DID have a build step (I was categorically against it at the time. Things changed, haha).

React has been able to use jsx without build forever, here is a modern take: [1]

The babel script is huge but it might be an option to get the ball rolling on a big upgrade.

1. https://medium.com/@to_pe/how-to-add-react-to-a-simple-html-...

I mean, using Babel in the browser is essentially a build step. Your code isn't executed as is and has to be preprocessed. It's huge and slow. Not particularly viable. If your goal is just to play around, sure, but the point the Vue folks are making is that they can do the same in a way that is production friendly (maybe not scalable, but still production viable). This isn't.

I find it amusing that you are allowed to run arbitrary Javascript but can't run NodeJS on your machine. Sometimes corporate security can be a theatre.

Frontend JavaScript is sandboxed and you can't really disable it without crippling 90% of websites.

node.js code can cripple your system way more. So this does not really seem surprising.

I wish we couldn't run NodeJS, then the front end devs wouldn't run this monstrosity that takes ages to start, downloads GBs of dependencies, consumes 12 cores for minutes at a time, etc.

I exaggerate, but only slightly.

I find this attitude towards front-end developers unamuzing. If you have a beef with subset of developers in your workplace that happen to to work on the front-end, you should not take your frustration or generalize their behavior over an entire industry.

I don't know what it is about the Node.js ecosystem which leads to the dysfunction, but there's definitely dysfunction, and it's definitely endemic.

Compiling our front end assets takes longer and more CPU than our entire back end with many multiples the amount of source code.

I think it's that JS has no standard library, so dependency graphs are an endless fan-out instead of fanning back in after a while. That's how you end up with 900 dependencies after importing a single Node module, because every author of every upstream lib chose a different way of doing the same thing.

To add to this the Node ecosystem seems somehow to encourage outsourcing extremely simple pieces of functionality (leftpad anyone?) so you end up including a bunch of crap that you don't really need, all because someone didn't feel like using 10 lines to reimplement something simple.

Javascript has a standard library... intended for the language's actual use case, which is lightweight scripting and DOM manipulation within the browser. It's not a deficit of the language that some startup decided to pretend JS was the new C++ and that an insane and byzantine ecosystem developed around the attempt to force Javascript to be something it was never intended to be, and make it seem more "enterprise."

Endless dependency graphs and single-function modules and left-pads weren't a problem back in the days of JQuery and sane libraries. None of this madness is necessary. No, not even for front-end frameworks. It's unnecessary in the vast majority of cases.

I mean, you gotta trust someone at some point.

If they don't trust Google, Microsoft, and Apple to keep Javascript in the browser sandbox-jail then they're gonna be re-inventing an awful lot of wheels ;).

React can, but less ergonomically than most developers are used to.

Could you comment more on how it's done?

Modern React uses JSX which is then transformed at build time into function calls.

You can write those function calls yourself, but it would be a tremendous PITA.

In this case, you could use `htm`: https://github.com/developit/htm#usage

That's cool- but unless you're targeting greenfield browsers only you aren't going to use the syntax in that documentation without a build step or using the babel transpiler directly in the browser which, while cool from a POC standpoint, isn't a good solution. At that point you might as well just add build tools and use JSX or whatever the framework you're trying to use intended or otherwise is well documented.

Yeah totally. Or even use Preact by the same author which is smaller and faster than React.

I suppose it could, but there are annoyances with JSX defaults.

For instance, Vue provides a method to explicitly declare your template variable delimiter syntax. Last time I looked this was requested of React, but not implemented, someone correct me if I'm wrong on that and it has come along in the last year or two. So.. lets say you wanna put some modern Javascript in some Django templates to make them look spiffy. With Vue you can just declare your delimiter to be `[[` instead of `{{`, (because `{{` conflicts with Django's template variable syntax) with a one-liner setting.

I'm sure you could do this in React with a custom parser function (or maybe there's a third party library?) but it's a lot easier when the framework just gives such things to you out of the box.

If I do this all over the place and some other guy comes along years from now with no documentation on what he's getting into, he doesn't need to know too much to figure out what's going on and work on it. Right away he'll see "delimiter = [[" at the top of the script block in a template and can grep double brackets in the whole project to get an overview of what's being done.

React doesn't have templates, so that's a non-issue. JSX is sugar on JavaScript, but it's not a string. So template delimiters don't matter (that is, if you didn't use a build step, then it would be straight javascript functions calls)

That’s the whole point of the discussion: Vue makes it easier to have Django spit out <tr @click=doThing>My data here</tr> and then Vue notices and adds the event listeners. In React, it is very difficult if React has to start with foreign template output because it wants to own the (V)DOM.

For sure! I was just pointing out that discussing how easy Vue made it to change the delimiter ala Mustache isn't exactly a benefit vs React, since the whole concept doesn't reall exist there at all.

React and Vue can both be used directly with script tags, however the biggest difference is that React uses JSX while Vue uses HTML templates (but also supports JSX).

99% of the time, HTML is easier and faster to write, with the built-in directives providing all the functionality you need. More importantly though, HTML can be generated by every single server-side framework, and this makes it very easy to have server-side code from any language stack that becomes interactive using a Vue client-side layer.

That's exactly right and this is a much underrated capability and I think it's the point being missed by those saying "well if you do XXX you can include React with a script tag too!"

Please someone correct me if I'm wrong. It seems like you can only implement React using the full "modern JS stack", i.e. Node/Webpack/...

So if you want to use it on one page, it's a hard sell to set up all that infrastructure (and document it for the team)

On some sites I've used Vue.js by simply adding a <script> tag with vue.min.js.

On sites already using Gulp or similar, it's pretty simple to incorporate the Vue bundle and use it on one or a few pages.

React can be added to a page with just a script tag in the same way as Vue:

https://reactjs.org/docs/add-react-to-a-website.html

Having said that, React is normally used with JSX syntax, which requires a compile step.

You _can_ use it with "raw" `React.createElement()` calls, but that's generally unwieldy and almost no one does that.

However, there's a very neat library called https://github.com/developit/htm , which is an almost-JSX-compatible syntax that uses JS template literal strings, and requires no compile step.

React can also be used with just script tags. It uses a compiler to turn JSX into a render function (the same as Vue which accepts JSX or HTML) and these compilers are written in JS and can run in the browser. Also modern browsers are much better at supporting JS modules which makes it easier to include other libraries.

This looks like the perfect place to mention my project template used to create Vue 3 apps without the need for Webpack or any other build tool:

https://github.com/arijs/vue-next-example

I already integrated vue-router, and am currently on the process of fully integrating Vue server renderer. I already have a basic usage implemented, where the home page is compiled to a html string, but I still need to make it easy to compile all pages and to implement client-side component hydration.

Apparently this is possible:

https://shinglyu.com/web/2018/02/08/minimal-react-js-without...

There is no need to run NodeJS in production with React. In fact, React doesn’t even require a fancy build system (though for anything more than a toy app you’re tempting fate.)