It's a huge complex house of cards that nobody really wants to have to deal with. Compare it to writing a Qt app, or even something like a Flutter app. You pretty much just install an SDK and go file -> new project.
Now I would tend to agree that classic ASP / PHP was conceptually simple and probably simpler than the current client side landscape, but they where beasts at scale.
I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities into the mix that you circumvent with desktop where you are delivering from the run-time up. For better or worse, the browser, the webserver and the middleware stack all dictate how we get to go about building applications for the web.
Is this even true in most cases? You almost always have some state that needs to be in both places. The more you choose strategies to optimize for client-side development and treat the backend as just a store for "blobs" of data, the more problems you have given enough scale, requirements, or just the passage of time.
What you state is correct for a subset of applications, but it's not universally applicable. With enough time and experience you'll likely understand the limitations. I'm not going to keep arguing with you because your subset can get you very far, and it's probably the right thing to do for your needs.
> I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities
Can you elaborate on the complexities? The desktop (as in Win32, Qt, etc.) and the web are on different ends of a spectrum. With JavaScript frameworks we have an in-between. In many ways you can put native mobile development in the desktop bucket because they are effectively have similar constraints, although some of the ideas/tools are a more modern implementation.
When you try and build abstractions to make the web feel more and more like desktop you expose the limitations of web development. The web will support more and more application features, but progress is naturally going to be slow around the maturation of these features than if you had gone with full desktop. What's interesting is that the web keeps pace enough that it never gets eliminated from the race. This is very important part of web and why people keep betting on it.
If you're writing something really horrendously complicated, yes, some sort of framework will help. If it's a little throwaway tool for internal or casual use, it's usually perfectly feasible to do the whole thing in one or two hundred lines of HTML+CSS+script. No tooling, no dependencies. It's so much quicker and so much less painful, and yet bizarrely people look at you like you're a wizard because the whole thing is 5k uncompressed and doesn't even need a webserver.
Both of these stacks are themselves deprecated and replaced by better solutions in the same ecosystem. "We're only as bad as 10-15 year old stacks" is hardly a compelling argument.
The state of the art in web is React which is an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Win32's UI loop.
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:
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?)
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 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).
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.
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 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.
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.
I love the fuck out of Vue.js/NUXT though.
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!” :)
Luckily, whatever people could do in the pas, they can still do today, because the web is largely backwards compatible. Then at some point they'll run into some things that seem harder than they need to be, at which point they can start looking at the tooling that was designed to solve those exact problems.
For this same reason, I’m disappointed that mobile browsers such as iOS Safari have yet to enable DevTools, e.g. a page inspector, network inspector, and JavaScript console. Especially for younger generations, there are many whose first computer will be a mobile device.
However, iOS more so than Android, has plenty of mature interactive code environments.
This exactly is the challenge. If your first computer is a mobile device, you would not have that “bigger brother” available.
iOS does have Swift Playgrounds [1] and Android has the excellent Termux [2] but access to the built-in JavaScript engine would open a whole new set of possibilities.
[1]: https://www.apple.com/swift/playgrounds/
[2]: https://termux.com/
I was introduced to programming on a dinky little graphing calculator. My hope is that other “first computers” could offer similar opportunities for tinkering.
On iOS you also have Pythonista, Continuous, Shaderific, Codea, all much better than learning FX-4500p, FX-850P Basic.
Sadly on Android, most of the alternatives are quite lacking versus the iOS variants in capabilities and quality.
The biggest hurdle to ripping off the bandaids (as with so many things in software development) is the rough edges of the long tail of legacy code. The biggest example being that there's still so much code written for CommonJS (or AMD) that needs shims to play well in ES2015 module worlds. (Because no one wants to stop the Node world and rewrite everything all at once.)
I understand the attraction, and I've had to build my fair share of them, but I don't like it at all.
As someone else who cut their teeth on an 8-bit micro back in the day, I agree with this 100%.
And I think it's a large part of the reason I'm so suspicious of the stampede in webdev toward very heavyweight toolchains over the past 5+ years; while they may have had the best of intentions, I think they do end up putting gatekeeper-ey accessibility barriers around the web's original rough democracy. It's not that the underlying technology has gone away, more that when someone starts looking around the mainstream web to see how things are put together, that's not what they're going to find.