19 ms·

Zwitterion: a web dev server that lets you import anything

103 points by lastmjs 7y ago

peteforde 7y ago
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 7y ago
  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.
  - karlshea 7y ago
    > Strange comment IMO. 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.
    - hising 7y ago
      Nah, been doing it professionally since 1997.
  - scient 7y ago
    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.
    - zebogen 7y ago
      You might be right, but "serious" tools have to start somewhere. We shouldn't be trying to shut out new ideas and approaches because we feel that there are too many different tools available. Any project should be judged on its merits. And any ecosystem needs new projects to move forward. If you don't like it, don't use it.
    - chrshawkes 7y ago
      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 7y ago
        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.
Ezku 7y ago
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 7y ago
  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.
  - oefrha 7y ago
    I'm confused by both of your comments. Latest commit is an hour ago, and all ten releases on the releases page are within two weeks. Where's "the box GitHub puts on the repo front page saying the last release was a year ago"? I've never seen a box like that on any repo front page.
  - Ezku 7y ago
    Thanks for pointing that out! I wonder why that is :S
    - m4r35n357 7y ago
      It just looks at tags, I think.
  - avip 7y ago
    Which "box" are we talking about?
    - lastmjs 7y ago
      Yeah I've been seeing that too. I've definitely been working on it recently, I just stopped using semantic release which was doing GitHub releases, and I've switched to just using tags...which apparently aren't releases. I'll need to sort that out. Definitely under active development!
styfle 7y ago
A couple things I noticed when comparing to webpack: 1. This doesn’t bundle 2. This doesn’t support source maps
- AbraKdabra 7y ago
  Come on, it clearly says it's not a bundler. > Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience.
  - zebogen 7y ago
    It does, but the title of the HN post says "Webpack killer." That seems misleading.
    - lastmjs 7y ago
      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.
GiorgioG 7y ago
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 7y ago
  I'm not sure where this idea has come from, but WASM is designed to run alongside Javascript. It isn't replacing it.
  - k__ 7y ago
    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 7y ago
      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 7y ago
        Blazor (WASM) has not been released yet - they're working on optimizing payload size.
        enlyth 7y ago
        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 7y ago
        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.
andybak 7y ago
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?
- Filligree 7y ago
  Vanilla JS? 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.
  - krapp 7y ago
    The funny thing is, all of these frameworks are designed for teams building professional sites at scale. They shouldn't be the standard for all javascript development. Not every javascript application needs NPM, a frontend framework and recompilation.
  - gherkinnn 7y ago
    In my experience that results in the team building an inferior, untested, undocumented, and buggy version of React|Vue|jQuery|lodash. Now you need to train new peeps to handle that mess. And you haven’t even started solving actual problems. Provided you really need so much bulk at your disposal. But that’s a different story.
    - tl 7y ago
      My experiences with React / Vue / Angular: server side rendering plus a reasonable refresh interface (LiveView, PJAX, Turbolinks, etc...) wins until you reach the point where native code is a better solution anyway. JQuery / lodash: we’re slowly getting better about modern browser availability and needing these less, but it’s a long road.
flankstaek 7y ago
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 7y ago
  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 7y ago
    Exactly. Zwitterion relies on ES modules in production and development, so bundling is not strictly necessary. See the README for information on performance implications.
leonardopriori 7y ago
But again what is the advantage over parcel?
- lastmjs 7y ago
  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 7y ago
    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.
chrshawkes 7y ago
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.
reaperducer 7y ago
"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 7y ago
  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 7y ago
    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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
- lastmjs 7y ago
  Great feedback on the README, thank you
tyingq 7y ago
"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 7y ago
  nor common.js
  - lastmjs 7y ago
    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.
joduplessis 7y ago
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 7y ago
  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
JMTQp8lwXL 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
aylmao 7y ago
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 7y ago
  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 7y ago
    Awesome! thanks for the heads up!
tylerl 7y ago
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 7y ago
  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 7y ago
    Exactly
- netghost 7y ago
  You know, when you had to support ie6 and php was cutting edge, the good old days! 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).
pinum 7y ago
>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 7y ago
  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 7y ago
    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.
_nalply 7y ago
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.

103 points by lastmjs 7y ago

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 7y ago
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.
- karlshea 7y ago
  > Strange comment IMO. 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.
  - hising 7y ago
    Nah, been doing it professionally since 1997.
- scient 7y ago
  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.
  - zebogen 7y ago
    You might be right, but "serious" tools have to start somewhere. We shouldn't be trying to shut out new ideas and approaches because we feel that there are too many different tools available. Any project should be judged on its merits. And any ecosystem needs new projects to move forward. If you don't like it, don't use it.
  - chrshawkes 7y ago
    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 7y ago
      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.

Ezku 7y ago

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 7y ago
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.
- oefrha 7y ago
  I'm confused by both of your comments. Latest commit is an hour ago, and all ten releases on the releases page are within two weeks. Where's "the box GitHub puts on the repo front page saying the last release was a year ago"? I've never seen a box like that on any repo front page.
- Ezku 7y ago
  Thanks for pointing that out! I wonder why that is :S
  - m4r35n357 7y ago
    It just looks at tags, I think.
- avip 7y ago
  Which "box" are we talking about?
  - lastmjs 7y ago
    Yeah I've been seeing that too. I've definitely been working on it recently, I just stopped using semantic release which was doing GitHub releases, and I've switched to just using tags...which apparently aren't releases. I'll need to sort that out. Definitely under active development!

styfle 7y ago

A couple things I noticed when comparing to webpack: 1. This doesn’t bundle 2. This doesn’t support source maps

AbraKdabra 7y ago
Come on, it clearly says it's not a bundler. > Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience.
- zebogen 7y ago
  It does, but the title of the HN post says "Webpack killer." That seems misleading.
  - lastmjs 7y ago
    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.

GiorgioG 7y ago

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 7y ago
I'm not sure where this idea has come from, but WASM is designed to run alongside Javascript. It isn't replacing it.
- k__ 7y ago
  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 7y ago
    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 7y ago
      Blazor (WASM) has not been released yet - they're working on optimizing payload size.
      - enlyth 7y ago
        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 7y ago
        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.

andybak 7y ago

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?

Filligree 7y ago
Vanilla JS? 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.
- krapp 7y ago
  The funny thing is, all of these frameworks are designed for teams building professional sites at scale. They shouldn't be the standard for all javascript development. Not every javascript application needs NPM, a frontend framework and recompilation.
- gherkinnn 7y ago
  In my experience that results in the team building an inferior, untested, undocumented, and buggy version of React|Vue|jQuery|lodash. Now you need to train new peeps to handle that mess. And you haven’t even started solving actual problems. Provided you really need so much bulk at your disposal. But that’s a different story.
  - tl 7y ago
    My experiences with React / Vue / Angular: server side rendering plus a reasonable refresh interface (LiveView, PJAX, Turbolinks, etc...) wins until you reach the point where native code is a better solution anyway. JQuery / lodash: we’re slowly getting better about modern browser availability and needing these less, but it’s a long road.

flankstaek 7y ago

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 7y ago
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 7y ago
  Exactly. Zwitterion relies on ES modules in production and development, so bundling is not strictly necessary. See the README for information on performance implications.

leonardopriori 7y ago

But again what is the advantage over parcel?

lastmjs 7y ago
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 7y ago
  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.

chrshawkes 7y ago

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.

reaperducer 7y ago

"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 7y ago
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 7y ago
  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 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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.
lastmjs 7y ago
Great feedback on the README, thank you

tyingq 7y ago

"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 7y ago
nor common.js
- lastmjs 7y ago
  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.

joduplessis 7y ago

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 7y ago
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

JMTQp8lwXL 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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.

aylmao 7y ago

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 7y ago
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 7y ago
  Awesome! thanks for the heads up!

tylerl 7y ago

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 7y ago
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 7y ago
  Exactly
netghost 7y ago
You know, when you had to support ie6 and php was cutting edge, the good old days! 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).

pinum 7y ago

>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 7y ago
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 7y ago
  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.

_nalply 7y ago

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.