Hacker News Reader

Comment by pricecomstock | Hacker News Reader

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.

View on HN

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.

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 ;).

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.

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

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

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.

Reply on news.ycombinator.com