Blazor (WASM) has not been released yet - they're working on optimizing payload size.
I didn't know this, I was just trying out the project because it seemed interesting. If they can get the bundle sizes down it looks like it could be a great developer experience.
As of the latest preview of Blazor, the boilerplate template (Release build) app loads a total 4.92mb, of which ~4.5mb is the runtime. It's not ideal, but if they can manage to get that to below 3mb it's "good enough" for my purposes. As an Angular developer, at work our app bundles are no smaller than 3mb these days.
"Zwitterion lets you get back to the good old days of web development." I'm OK with people pining for simpler times. There's a lot of projects that are overcomplicated these days. But the good old days of web development didn't require three files for "Hello, World."
It seems like that was just a way of showing how you can use import statements and other things in that setup without needing to set it up.
React Router used to be a mess. And should I use Redux? I thought it’s not cool anymore. If I do, do I store everything in a global state? Maybe I’ll use Context and Hooks. Or was it HoCs? And what about mobX? I heard it’s like Vue. I like Vue. And I absolutely need something to handle requests. Saga? Maybe some GraphQL? Now that I have my views, my state, and my data, how do I test this? Jest or something else? But…
Everyone worries about these choices in react, but you don't need to, for most apps, they're all good choices: use redux or mobx, doesn't really matter. Use lodash or underscore, doesn't really matter. There are minor advantages to some of the tools, and the nice thing about the react ecosystem is that it lets you pick if you really need to, but for getting started, just pick one and move on. IMO this is highly prefe…
I agree. And since much of that is often superfluous, you end up with a “minimal” setup. Though this does require at least one experienced dev to make those choices.
And my experience tells me that fewer than 1 in 10 React devs can make those calls.
I’ve been doing React for years and haven’t experienced this. What kinds of apps are you building?
React Router used to be a mess. And should I use Redux? I thought it’s not cool anymore. If I do, do I store everything in a global state? Maybe I’ll use Context and Hooks. Or was it HoCs? And what about mobX? I heard it’s like Vue. I like Vue. And I absolutely need something to handle requests. Saga? Maybe some GraphQL? Now that I have my views, my state, and my data, how do I test this? Jest or something else? But…
i think this is what happens when you do a lot of reading about web dev instead of just building and trying things out
But then you're forced to use React...and as soon as you need to do anything outside of what it provides it all falls apart which happens pretty quickly in my experience with it.
You don't have to use React. The template gives it to you, but if you delete all the code and never import React, you're never using it. I use CRA nowadays for either simple vanilla JS/SCSS brochure-ware sites, or for simple TypeScript sites
"lets you import anything" It doesn't seem to support importing css or image files. I don't use them, but the webpack css-loader and image imports seem popular.
Can anyone point me to a workflow where the cognitive load is similar to how it was in the good old days? i.e. some thing that does everything for me apart from the bit where I write application and presentation code? That mostly just works and doesn't require me to understand the whole stack. Because when I switch to other languages/environments I can most remain blissfully unaware of the plumbing that keeps the thi…
If you don't need to support older browsers, just write raw JS and use module imports. This means that you're pulling down a lot of different files instead of one big blob, but a lot of those files will already be cached in the user's browser from CDNs anyway.
Yes, you don't get JSX this way, but I've always seen people's obsession with syntactic sugar as bikeshedding. Typing out code isn't the bottleneck for development, it's just one of the easiest things to optimize, so people obsess over optimizing syntax while much more significant problems like debugging and traceability are largely ignored because people don't understand them as well. Worrying about losing the benefits of JSX when you're writing a language that still fails silently when you reference a mis-spelled property on an object is like worrying about your haircut while you bleed out from an arterial wound.
Can anyone point me to a workflow where the cognitive load is similar to how it was in the good old days? i.e. some thing that does everything for me apart from the bit where I write application and presentation code? That mostly just works and doesn't require me to understand the whole stack. Because when I switch to other languages/environments I can most remain blissfully unaware of the plumbing that keeps the thi…
Ember.js is very much batteries-included although learning the framework definitely requires a time investment.
Ember.js is the highest-cognitive-load framework I've ever used. Not only do you have to understand all the bundling of JS, but you have to understand Ember's naming conventions and project structure, which has a lot of corners and edge cases. The basic problem is that they give you a bunch of configuration points and if you don't know what configuration point to insert your code at, you're either going to be writing a terrible hack, or you're just plain unable to do what you need to do. There are similar issues with React, Angular, Django, etc., but Ember is the worst one I've ever used. It's been a while so maybe the situation has improved, but I'm simply not willing to go back to something that has burned me that badly.
Cool project. "Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience." I get that, run locally, it's not bundling, but how is it not a bundler when running static builds for production?
It seems like for production it just compiles the stuff (the things that need it) and puts everything into a /dist folder but it does not indeed bundle it. The author advises relying on HTTP2 to serve the files.