Although I would eventually recommend learning how to utilize Babel & Webpack yourself because knowing why and how it works is useful.
If it's some other objection to complexity, I'd recommend learning modern web dev using https://mithril.js.org/ which can use JSX, but in documentation the non-JSX form is primary.
I started working on making the JSX docs a little better but got stalled... hopefully I will have some time later this month.
Theres pages of content that can be sorted and filtered, so I mainly want to use it to dynamically update the elements, with the data coming from ajax calls.
React:
const Welcome = (props) => <h1>Hello, {props.name}</h1>;
ReactDOM.render(<Welcome name="Taylor" />, document.getElementById('react-welcome'));
const welcome = (name) => html`<h1>Hello, ${name}</h1>`;
render(welcome('lit-html'), document.getElementById('lit-welcome'));I recommand Vue to any Javascript beginner that want to add interactivity to their page without having to handle the DOM manipulation themselves.
After that I tried InfernoJS which uses JSX because I needed the performance for a project and now I've turned around on JSX.
Personally I couldn't go back to template based frameworks like Vue or Svelte because they usually put you into this one component per file mindset. I much prefer being able to create micro-components in the same file like say buttons or table rows.
The thing that annoyed the most with JSX was that writing conditionals and loops inline was ugly or a pita. Then I discovered this Babel plugin and I love it:
In pretty much every case, where the README shows the "before transformation" and "after transformation" comparison, the "after" part is what you should be writing to begin with. This feels like adding an extra layer of abstraction just for the purpose of not learning to do some simple things in JavaScript itself.
I would be pretty annoyed if I started working on an existing React project and it had that sprinkled across all the components.
I'm guessing this is mostly a nicety to paper over the fact that 'if' is not an expression in JS, so you have to do things like
var foo;
if (something) {
foo = <SomeComponent.../>;
} else {
foo = <OtherComponent .../>;
}
<Container>
{foo}
</Container>
<Container>
{
if (something) {
<SomeComponent.../>;
} else {
<OtherComponent .../>;
}
}
</Container>
Dart also has spread operators and for-expressions to make writing "UI with code" much easier. It's fresh to see how language design choices are being made more by pragmatic ones (for Dart it's the fact that it's primarily being used for Flutter to make UIs) instead of ideological ones (One might claim that "if" should be a pure expression following the tradition from functional languages like ML, but that also has its own set of problems in a language designer's perspective)
https://medium.com/dartlang/making-dart-a-better-language-fo...
(I know absolutely nothing about Dart, but it does sound a bit weird that the expression-ness of an if is contextual. Is there a good underlying reason for the exceptionalism here?)
I guess my bigger complaint is that its all 'possible', but not recommended for production, its going to slow down your site in some way, etc. There are always drawbacks to not using the recommended way. Its like eating soup with a spork. Yeah you can do it, but its going to take you a lot longer than with the proper tool.
I love the fuck out of Vue.js/NUXT though.
I think the design really nails it: just enough architecture, tagged template literal rendering, functional DOM tree composition with an optional component system.
I prefer to avoid stateful components in favor of pure rendering functions, as much as possible.
Choo's renderer is based on morphdom, which is interesting because it diffs against the real DOM rather than maintaining a virtual one.
I use monoapp, which is a fork of Choo allowing you to bring your own renderer (such as lit-html).
Local "file://"? That isn't even trusted, current browsers outright block simple functionality like loading other files with XmlHttpRequest by default. You either have to completely disable various security settings or spin up a simple http server. At least I think that http is still enough for localhost, with the push for https you might want to set up a LetsEncrypt cert before you even think about starting a JS Hello World.
> loading other files with XmlHttpRequest
simple functionality? To me that actually does sound kind of like an 'advanced' thing to even think of from a beginner's perspective... i.e. someone who's just trying to learn to make a web page with perhaps a little bit of interaction.
(But then, maybe my idea of a beginner's level of ambition is hopelessly old-fashioned, I don't know.)
I do think that it would be great if there were a way to tell a web browser through its Dev-thingy to actually serve a folder to itself as if it were served by a bona-fide web server with HTTPS. I mean, it's not that hard to start a python-http-module-server, or install the npm module 'http-server' (or whatever it's called), but y'know...
EDIT: I don't necessarily disagree with you, but I think it may be a matter of degree.
I'd like to plug Beaker Browser as an amazing tool for getting started with barebones HTML, CSS, and JS. I would say Beaker marvelously fulfills this wish for a browser to serve a folder to itself.
Because it is built around the peer-to-peer dat:// protocol, it also ends up being "local-first" regarding web pages that you write with it (as well as sites that you decide to seed).
@staltz has an interesting presentation on the utility of Beaker Browser: https://staltz.com/beaker-frontend-dev-dream-browser/#0
On the other hand, I don't know enough to speak to Beaker's capabilities with XmlHttpRequest.
today, for now, it's still mostly workable, with some fiddling, and yes, setting up a local web server.
And indeed, with a batteries included kind of solution like PHP/MySQL, one can build a basic Facebook like in a week long workshop or so. You won’t understand everything that’s going on under the hood of course, but the fact remains that it’s way more accessible than the webpack/Babel/react.js/etc stacks that web devs push these days (waiting for the inevitable “oh no one uses webpack anymore, it’s all about ChirpChirp.js these days!” :)