
Zwitterion: a web dev server that lets you import anything - lastmjs
https://github.com/lastmjs/zwitterion
======
andybak
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 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?

~~~
mumphster
Parcel ([https://parceljs.org/](https://parceljs.org/)) fits this bill nicely
and I use it for all my personal frontend development needs (node and browser
targeted). You just add a script tag that points to a
js/typescript/rust/(whatever else the author eventually adds) file and run
parcel on said html file and you get hot reloading, decent error reporting,
bundling, and asset loading via `import` without having to configure a single
thing (other than npm installing sass and react and whatever other libraries
you want to use))

~~~
jjeaff
This is what I was going to suggest. I am working on moving towards react and
some other better practices for our current jQuery/spaghetti code front end
and I needed to be able to handle multiple entrypoints and types. I messed
around with webpack and create react app and gulp and several other things for
days before coming across parcel. It just works.

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.

------
JMTQp8lwXL
It doesn't appear to support CSS files (or other flavors like SCSS), so
calling it a "webpack killer" seems extra. Also, a lot of people need
polyfills for node modules written for NodeJS that are used in browser; for
example, Buffer. Webpack takes care of all of those nuances for you. I
wouldn't call this a killer for my workflows, where I need Webpack features
such as aliasing, etc.

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.

~~~
lastmjs
Hmm...excellent feedback! Thank you. I hope I wasn't dishonest with the title.
I do believe Zwitterion has the potential to rival and replace Webpack
eventually.

~~~
JMTQp8lwXL
Zwitterion already would have application today; for example, you just want a
simple dev server without writing a config, but maybe you want to use
typescript, too. My apologies if the original comment seemed too critical. For
my colleagues, Webpack has been a thorn in their side; I've accepted it and
learned to wield it well. There is definitely demand out there for something
simpler.

~~~
lastmjs
No you're good! I just want to come through this with my integrity intact.
Also, the browser-compatible Node.js libraries you spoke of above, those can
be added to Zwitterion as well. I had something similar done in a previous
version, but I removed it. All of these comments are going to be Zwitterion's
roadmap, so thanks again.

------
Ezku
Appears to have goals similar to
[https://parceljs.org/](https://parceljs.org/), except parcel is under active
maintenance and development whereas the latest release on this one is from a
year ago. Am I missing something important? :)

~~~
onion2k
This project is very clearly under active dev. The box Github puts on the repo
front page saying the last release was a year ago is misleading.

~~~
Ezku
Thanks for pointing that out! I wonder why that is :S

~~~
m4r35n357
It just looks at tags, I think.

------
reaperducer
"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."

~~~
mavsman
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.

~~~
lastmjs
Exactly. You don't need any of that if you don't want it. You can write
everything in your HTML file if you want, put your script in a script element
(though there will be no compilation of the script element, if you want that
it needs to be in its own file).

------
Etheryte
A couple of meta suggestions:

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.

~~~
tyingq
Agree on the title. I'd have had a different reaction to this if the HN title
hadn't claimed it was supposed to be a _" webpack killer"_.

~~~
lastmjs
Alright, I'm feeling bad about have a misleading title and I'd like to fix it.
I can't change the title now without removing this post and reposting it. Do
you have a suggestion for what I should do?

~~~
tyingq
An editor might notice your comment and fix it. That said, your comments
weren't here when I first saw this. Now they are, so there's lots more
context. It's probably not an issue now.

------
flankstaek
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?

~~~
genezeta
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.

~~~
lastmjs
Exactly. Zwitterion relies on ES modules in production and development, so
bundling is not strictly necessary. See the README for information on
performance implications.

------
_nalply
Tonight I just got my own small dev server running without a bundler. It is
simpler than Zwitterion because it has a narrower scope: only ES modules, an
import map generator and a simple hot reload watcher (with Koajs and a
websocket).

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.

------
tyingq
_" 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.

~~~
NHQ
nor common.js

~~~
lastmjs
I don't plan on supporting common.js. See this issue for CSS and images:
[https://github.com/lastmjs/zwitterion/issues/265](https://github.com/lastmjs/zwitterion/issues/265)

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.

------
leonardopriori
But again what is the advantage over parcel?

~~~
lastmjs
I think it's simpler. No bundling. You don't have to include a bundle file,
you just include files directly as you would have without a bundler. That may
seem like a trivial difference, and it could be, but it leads to simpler code
and less of a delta between what you think is happening with your modules and
what actually happens at runtime.

~~~
Tajnymag
But Parcel does exactly that. You point parcel at your index.html and it
transpiles everything to a dist/ directory including rewritten index.html with
imports pointing towards the transpiled files.

------
styfle
A couple things I noticed when comparing to webpack:

1\. This doesn’t bundle

2\. This doesn’t support source maps

~~~
AbraKdabra
Come on, it clearly says it's not a bundler.

> Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler
> experience.

~~~
zebogen
It does, but the title of the HN post says "Webpack killer." That seems
misleading.

~~~
lastmjs
Thanks for the feedback, seems like sourcemaps will be needed, shouldn't be a
problem:
[https://github.com/lastmjs/zwitterion/issues/266](https://github.com/lastmjs/zwitterion/issues/266)

Zwitterion is not a bundler. I believe the world will move away from bundling,
and that Zwitterion can replace Webpack eventually.

------
aylmao
This looks like fun! I've been meaning to experiment with some WASM, but none
of my ideas warrant investing time setting things up just yet, so I haven't.
This will come in handy. @lastmjs: does it support defining the script MIME?
I'm thinking something like:

    
    
        <script id="myGeeks" type="text/tsx">
          // ... script here
        </script>
    

This really would be a great addition if not, and help drive the narrative
that this brings simplicity back to that of "the old days" of web development
(:

~~~
lastmjs
You should be able to set the MIME type:
[https://github.com/lastmjs/zwitterion#headers-
file](https://github.com/lastmjs/zwitterion#headers-file)

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

~~~
aylmao
Awesome! thanks for the heads up!

------
chrshawkes
I'll definitely check this out. One of the issues I ran into with ES6 module
importing was the dependencies of dependencies which didn't have ES6 importing
options. So, I found myself editing source code for dependencies which
couldn't be imported. Web development should be moving into this direction in
my opinion. I hope the project works.

Webpack does more than just module importing though. Tree shaking,
minification, uglifying, compiling SASS and a lot more.

------
joduplessis
Good old days of web development didn’t ever disappear - you can still include
normal JS code directly through the <script> tag if you want.

~~~
lastmjs
True, but you lose the enormous benefits of things like TypeScript and the
latest JS features. We need the good old days of our dev process combined with
the good new days of language features

------
pinum
>CommonJS (the require syntax) [...] are not supported

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?

~~~
lastmjs
If you really want it you can open and issue and try to be convincing...but
I'm pretty set on moving forward with just ES modules. I attempted this in the
past and compiling CommonJS to ES modules was pretty complicated at the time.
I'm not sure it would be worth doing, but perhaps it would be. I want
Zwitterion to be forward-facing

~~~
pinum
I can absolutely sympathise with wanting to avoid to avoid adding support for
an outdated system that would be a headache to implement and (I assume) a
significant maintenance burden.

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.

------
tylerl
I'm confused by the tagline: _”Zwitterion lets you get back to the good old
days of web development. "_

Like, what made the good days go bad? What is this supposed to be better than?

~~~
hn_throwaway_99
My 2c about what this is referring to:

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.

~~~
lastmjs
Exactly

------
peteforde
I wonder if someone quantified the millions of hours wasted by OCD
bikeshedders moving their projects over to the latest, not-necessarily better
new thing offering vague utility improvements over the thing that was just
starting to feel comfortable... if the JS community would stop churning their
north star toolset every 18-24 months.

Seriously: it's like you're trying to nuke the moon. This is why people
legitimately grief about "the ecosystem".

~~~
hising
Awesome with new ideas and approaches to things. Just because someone have
taken time to solve things differently does not automagically imply that this
is something that forces someone to throw old stuff out. Strange comment IMO.

~~~
scient
I think he is pretty spot on. JS community is infamous for the constant
replacement of tools with the next shiny thing, which are all built on a house
of cards (one-line npm packages). I would rather see some more serious tools
being put out and matured instead of this constant running around.

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.

~~~
chrshawkes
Correct. In no way is this tool a webpack killer. Webpack solves a lot of
problems that clearly this author of this post is not familiar with based on
the clickbaity title.

~~~
lastmjs
I believe most if not all of the missing features can be addressed and
eventually Zwitterion could replace Webpack. I believe that non-bundlers will
replace bundlers. Also, not all of the features Webpack provides I believe are
necessary (like bundling) in forward-facing applications.

------
GiorgioG
I can’t wait for WASM to kill off JS for mainstream web front end app dev. It
can’t come soon enough.

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.

~~~
SquareWheel
I'm not sure where this idea has come from, but WASM is designed to run
alongside Javascript. It isn't replacing it.

~~~
k__
This.

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.

~~~
enlyth
Indeed, I tried Blazor and a simple Hello World page loaded about 7 megabytes
of DLLs in the browser just to show some text.

~~~
GiorgioG
Blazor (WASM) has not been released yet - they're working on optimizing
payload size.

~~~
enlyth
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.

~~~
GiorgioG
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.

