Zwitterion: a web dev server that lets you import anything
github.com
github.com
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 thing running. I learned all I needed to learn about pip and virtualenv in under an hour. My C# editor just lets me edit code and hit play.
Is there any chance of getting to this state of nirvana for web development?
For most purposes I find that all these frameworks are simply unnecessary. As a bonus, all the debugging tools in Chrome work much better when there's no obfuscation or packing, and "recompiling" is just Ctrl-R.
Code size and load speed is also massively better than it would otherwise be. Pages load instantly. It's nirvana, I tell you.
Provided you really need so much bulk at your disposal. But that’s a different story.
JQuery / lodash: we’re slowly getting better about modern browser availability and needing these less, but it’s a long road.
- runtime plugins
React is great if you stay in the design constraints, which is to be expected. This covers the vast majority of web apps.
edit: [removed svg snippets] I think I was confused with WebComponents not supporting svg elements that don't include the root tag
Angular and to a lesser extent Vue give you more direction.
This is of course not inevitable in a React project, but it does take good technical leadership not to be hindered by analysis paralysis before you even set off.
0 - An exaggerated summary of what I gather on various forum and discussions.
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 preferrable to the angular world, where some things just can't done without digging through poorly documented internals (at least this was the case wirh v4 when I last used it)
And my experience tells me that fewer than 1 in 10 React devs can make those calls.
I'd argue that they're all bad choices.
Redux/Mobx are just causing you to use global state, which forces you into a single-page application anti-pattern. I've stopped using either and my code has become massively less complex.
Lodash/Underscore are massive libraries that you end up using only a few functions from. Many of these functions can be written in <10 lines of code yourself, and some are equivalent to ones that already exist in newer versions of vanilla JS. In the latter case I'll often use polyfills, and remove them as support for the new features gets good enough.
That said, I suppose the answer is just, "don't do that". I may have spoken out of ignorance of how people frequently use mobx, since my experience with mobx is very limited. I probably should have constrained my statement to only talk about Redux, since I have a lot more experience with that.
These days I use two libraries: Preact and Immer. And I only introduce Immer to a project if state management becomes a pain point in the project, so I often don't even use Immer. I import these in my project with:
<!-- in my base HTML template -->
<script src='path/to/immer.js'></script>
// in my JS
import { h, Component, render } from './path/to/preact.js';
import produce from immer;
Can you elaborate on what you run into?
I'm one of those people who is very, very suspicious of imports, and barely ever uses anything outside Vanilla JS, but even with that mentality I have to admit that some libraries have their place. These days I usually use Preact (basically a stripped-down React) and I've not really come across much that it can't handle.
The key for me has been to just write isolated components, and avoid the "full page application" anti-pattern that is so common in web applications today. React doesn't force the anti-pattern on you like other frameworks, so I've had pretty good luck with this. It results in fairly clean, reusable code, and users see positive benefits because it allows me to create consistent, predictable interfaces.
Parcel is probably the closest to zero-config that I've seen. Only drawbacks are when you want to do something "off the rails". I'm guessing this project will be the same.
Of course, if you're not worried about supporting IE11, you could waive any built step and be absolutely fine. Gzip is more important than minifying.
I work in Django, and have a love-hate relationship with it. The main selling point is the Django ORM, which keeps me coming back, but even that is just the best of a lot of bad options. And a lot of Django patterns (class-based views, template tags, middleware, signals) are just obfuscating features that are handled much more simply with raw Python features. They let you write 80% of your behavior with 20% of the effort, but drastically impede your progress on the other 20%, and create debugging nightmares.
Beware projects with impressive quickstart guides.
An example of that is when you want to mix things like Jquery or React elements in with Angular. It is (or at least was) far to easy to step outside of what react expects you to do. The end result is a break on minor updates. So, instead, you'll often end up with these janky half maintained library like "Jquery-ui-datepicker-angular" (made up) Or whatever that try to bridge the gap as best they can.
EDIT: Forgot to mention component template co-location, which is pretty great, too.
However, I also remember that the rapid breaking of reverse-compatibility was also a problem. The fact that Ember is very different over time is a bug, not a feature.
To Ember's credit, their documentation is superb, and that includes detailed migration plans with each release. All the problems I ran into over time were solvable with the "RTFM" strategy. But I would rather use tools that I can keep a fairly-accurate model of the tool in my head, rather than ones that require deep dives into documentation for updates and trivial changes.
Your criticism is totally fair, though. Part of the reason why I asked is because I'm going to be giving a talk at an Ember meetup I'll be hosting in a few weeks and part of it might be about why people are choosing not to use Ember and how we can make it better. So thanks for providing your perspective.
I suspect this happens when you fall behind their rapid release cycle, but I always kept my dependencies fairly current when I was using Ember. It's painful, but it's far less painful than falling behind and being forced to make updates all at once later (and with broken docs, apparently).
> Part of the reason why I asked is because I'm going to be giving a talk at an Ember meetup I'll be hosting in a few weeks and part of it might be about why people are choosing not to use Ember and how we can make it better.
My suggestion would be to find a way to make Ember more of a library and less of a framework, if that makes any sense.
I think what React does really well is that it's not weird or difficult to use a few React components in a completely non-React codebase, and it's not weird or difficult to use completely non-React code in a React-heavy codebase. React components are just that: components--there isn't a pervasive MVC structure that makes it difficult or weird to do stuff outside of it. If you have component A and component B, it's easy to have A on one page, B on another page, and A and B on a third page, or two A's, or two B's on the same page. Components are composable and isolated.
With Ember you have a few options to achieve this result: 1) duplicating code to allow the "components", 2) spinning up multiple MVCs in a page to isolate them from interactions, 3) writing some hairy conditional logic inside the "components", so that at least one of the components has to be concerned about the rest of the page.
2 isn't a bad option from a high level, but Ember assumes you'll only be running one MVC per page, and does a bunch of things which makes this nontrivial.
React Components aren't entirely unlike a little MVC, but the assumption from the beginning is that a React component may never have to interact with any other React component. Isolation is the assumption, rather than a single-page app full of entangled components.
But I completely realize that my suggestion is basically, "Make Ember more like React" and as someone with no investment in Ember at this point, there's not really a reason I'd choose Ember over React, which is supported and used by a bunch of much bigger and more mature codebases than Ember is, even if Ember were to switch to a more React-like model.
Want to build your react app? Just tell parcel where your index.js is and it will see your react and react dom imports and just build it. No config needed.
Want to do react in typescript? Just change your entrypoints to index.ts. Done. Even handled the yarn add commands for you.
This allowed me to easily have a few different react entrypoints as well as just a few random .ts files for use on pages that aren't built in react yet and then I just watch or build using a wildcard and it takes care of it all.
So far, I'm a big fan.
I have not needed to touch any of the config files and it “just works”. I got turned off by React and Vue where you need to learn a build tool and write your own config.
Which do you use?
Some examples: https://svelte.dev/examples
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.
But yeah, probably not a terrible way to go. If you are working with an http2 server today then this will work really well.
Not anymore.
That means that the module approach isn't faster than bundling, but with HTTP2, the module approach shouldn't be slower than bundling.
EDIT: not that trivial https://webpack.js.org/guides/tree-shaking/
That being said, I support the effort to make a simpler, superior bundler. My disagreement is more so with the marketing in the title. Though, those sort of claims are what drive clicks today.
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."
The submission title is provocative and personally I'd say misleading. As can be seen in other comments, it can lead to badly framed discussions and general dislike about the project. The project readme doesn't even mention Webpack, so why is the leading phrase "Webpack killer" in the title?
The repository readme is very long. As a dev, I'm looking to capture the core concepts of a project from the readme: what is this thing, is it relevant to me, and how does it compare to other things? Most of this information is covered, but there's a lot in addition. I'd recommend moving everything about specific languages to separate files and simply reference those in a list.
"Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience."
My hobby project uses web components with lit-html as frontend. I was frustrated with bundlers. They are probably neccessary in production, however I just wanted to have a smooth code-test loop! A few minutes with my newly created dev server and I soon figured out an old stupid little problem which was stumping me before just because I didn't have a quick code-test loop.
The lynchpin here is the import map. With the import map there's an alternative to bundlers. Instead of transpiling whole projects with all their dependencies, you just let fetch all modules. I know, this doesn't scale, but for quick experiments this is almost too simple to be true.
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.
I will most likely add those soon. I will also be exposing a plugin system (currently it's just internal) that allows for others to add functionality that Zwitterion core will not support.
1. This doesn’t bundle
2. This doesn’t support source maps
> Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience.
Zwitterion is not a bundler. I believe the world will move away from bundling, and that Zwitterion can replace Webpack eventually.
<script id="myGeeks" type="text/tsx">
// ... script here
</script>
In the case above, you would need to say type="module", because you are importing a module even if it is tsx. But, you should be able to set the MIME type for .tsx files with a custom header file
Webpack does more than just module importing though. Tree shaking, minification, uglifying, compiling SASS and a lot more.
That's unfortunate, and really limits the packages that can be used with this. Parcel does appear to support `require()`. Is this something you might add in the near future?
But there are a lot of commonjs modules out there, and many/most of them will never migrate to ES modules. It's such a significant downside compared to Parcel that I'm honestly not even inclined to try zwitterion out, let alone get involved with the project by making detailed feature requests.
Like, what made the good days go bad? What is this supposed to be better than?
In "the good old days", you would just import a script using a normal <script> tag, it would do stuff on the page, and you're done.
What a lot of people refer to as "modern" web front-end development, there is a whole toolchain needed to compile and prepare your site for deployment: babel, webpack, etc. While these front-end tools solve a host of problems, they also introduce a whole set of new ones, mainly around complexity and the fact that what is actually going on "under the covers" is a lot more opaque to the front-end developer.
I jest of course, but while frontend tooling has gotten quite complex, there's a good reason. Transpiling, minifying, and tree shaking are non trivial, and pretty much a requirement if you want to build a rich client (though not everyone needs one).
Seriously: it's like you're trying to nuke the moon. This is why people legitimately grief about "the ecosystem".
You must be new to JS then. Come revisit your reply when you try and work on any JS project no one has touched for a year.
My own personal theory is that because the barrier of entry is so low, people get a little too excited about being a contributor and solving a problem "differently" (sometimes before even understanding the problem space well enough). In short - lot of it is inexperience.
edit: Look at Blazor and Yew for example, these types of frameworks can and will replace the bulk of what we use JS for today.
It's funny tough, people are starting to pump giant runtimes over the air just to get C# running on the frontend, while people already complaining about JS bundle size smh.
Currently DOM libraries using WASM are implemented by importing JS wrapper functions.
The point of doing it is of course performance.
It is...
"To realize the high-level goals of (1) integrating well with the existing Web platform and (2) supporting languages other than C++, WebAssembly needs to be able to...reference DOM and other Web API objects directly from WebAssembly code...call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript..."
Currently WASM is a way worse in terms of shipping on the web. On top of wrapper JS scripts, .wasm files are treated as statice files like image files. You have extra burden with the path of every .wasm files.