Zwitterion: a web dev server that lets you import anything(github.com)
github.com
Zwitterion: a web dev server that lets you import anything
https://github.com/lastmjs/zwitterion
126 comments
Parcel (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))
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.
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.
Yep, tried this recently after being out of JS land for a while, and Parcel just worked. So +1
It's also significantly faster the webpack, at least in my experience.
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.
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.
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.
Provided you really need so much bulk at your disposal. But that’s a different story.
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.
JQuery / lodash: we’re slowly getting better about modern browser availability and needing these less, but it’s a long road.
Despite working mainly with TS and React, I almost agree with the first part. There are all to many cases where a minimal setup works just fine. My hope is that such a restrained setup inherently suppresses stupid features nobody asked for. And yet here we are.
Perhaps that's the case. I'm assuming small-scale/personal sites, where there's no team and one person does all the work.
Frameworks are managers pipe dream. Vanilla never gets old.
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.
Deploying JS (or anything) over the web usually requires a lot of extra considerations. Devs want flexibility in their deployment options, which is why Webpack is so complex.
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.
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 really like svelte, there is a build/compile step, but it’s pretty much batteries included.
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.
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.
Zwitterion could add support for .svelte files rather easily
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.
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.
> a lot of those files will already be cached in the user's browser from CDNs anyway
Not anymore.
https://www.jefftk.com/p/shared-cache-is-going-away
Not anymore.
https://www.jefftk.com/p/shared-cache-is-going-away
Interesting.
That means that the module approach isn't faster than bundling, but with HTTP2, the module approach shouldn't be slower than bundling.
That means that the module approach isn't faster than bundling, but with HTTP2, the module approach shouldn't be slower than bundling.
Bundling also deletes dead code so it can potentially save a lot, especially if you import huge libraries and only use a small part of them.
Can you give an example of a bundler that removes dead code and not just minifies it? Dead code removal in JS is a bit tricky, unless we are only talking about code after return statements and other low hanging fruit.
IIRC as long as you use ES modules, tree-shaking is trivial?
EDIT: not that trivial https://webpack.js.org/guides/tree-shaking/
EDIT: not that trivial https://webpack.js.org/guides/tree-shaking/
Hmm. Now that we have async functions meybe we could also add the pure keyword in order to help optimizations.
A much better solution is to not import huge libraries you will only use a small part of.
Browser support is fairly new, I was actually surprised when you mentioned you could do this now :).
But yeah, probably not a terrible way to go. If you are working with an http2 server today then this will work really well.
But yeah, probably not a terrible way to go. If you are working with an http2 server today then this will work really well.
Chrome, Safari and Edge have supported it since late 2017; Firefox since May 2018. So it should be quite safe to use by now.
Svelte was mentioned here yesterday. It's not like the old jQuery days, but it did look simplified to me as compared to other popular toolsets.
https://svelte.dev/
Some examples: https://svelte.dev/examples
https://svelte.dev/
Some examples: https://svelte.dev/examples
Meteor comes pretty close being a zero-config build tool and free choice of frontend framework. But you do need to understand the framework
Create-react-app is what you’re looking for.
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
What have you been doing that React doesn't handle?
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.
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.
I’ve been doing React for years and haven’t experienced this. What kinds of apps are you building?
- web components
- 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
- 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
The app I currently work on is 100% runtime plugin based. React has not been an issue there at all. I haven’t tried using web components, though, so can’t speak to that.
it's not impossible, I have something working with react-registry. With Vue it would work out of the box since it comes with a registry out of the box.
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 why write tests if I have Types! How to configure TS? A few any never hurt anyone, did they? Too many questions. I’ll let Create React App answer this for me. Or is it Gatsby? Or even Nextjs? Oh, and is Lodash the new Underscore? And what is different about those and Ramda? We need more FP! But how do I structure my Code? Dan “Daddy” Abramov tells us to organise it any old way. But how? [0]
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.
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.
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 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)
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)
> 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.
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.
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.
Mobx state is local by default. Observable are just scoped to the component they are created in.
That's true, but in that case observables are little more than syntactic sugar over callbacks. The way I've seen them used in codebases a lot is to decrease the pain of global state--but that's only delaying that pain, and global state SHOULD be painful.
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.
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.
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.
And my experience tells me that fewer than 1 in 10 React devs can make those calls.
I've used React for a while now, and I agree with you that most of these libraries are pretty garbage. I've solved this problem by just not using any of them.
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:
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;
i think this is what happens when you do a lot of reading about web dev instead of just building and trying things out
>need to do anything outside of what it provides
Can you elaborate on what you run into?
Can you elaborate on what you run into?
They have an eject function which lets you modify The environment and extend it however you want.
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.
I'm curious, when was the last time you used it? The Ember of today is a lot different from the Ember of 2015, and even the Ember of 2018. As of a week ago, it's now fully switched to a component library that can be used independently of the framework, and they're now template-only by default. It'd certainly be a shame if you completely gave up on it because of a version still using Ember.View.
EDIT: Forgot to mention component template co-location, which is pretty great, too.
EDIT: Forgot to mention component template co-location, which is pretty great, too.
The last time I used it was early 2017.
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.
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.
That's funny, because my perspective is the opposite on both points. I actually appreciate that they've been able to move forward with new ideas without worrying too much about backward compatibility. (though usually both new and deprecated features are moved into modules that can be imported separately) As far as documentation goes, well, I think it leaves something to be desired. If you like dozens of broken links, the Ember guides are for you. hahaha
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.
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.
> If you like dozens of broken links, the Ember guides are for you.
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.
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.
They burned me with the "rails" problem. Ember and RoR are two projects that have really turned me against overarching frameworks. Both have gone through periods of crazy backwards breaking and paradigm shifts that have left me burnt out.
Agreed.
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.
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.
Yeah, The big problem with these frameworks is that, by their very nature, they punish you severally if you ever step outside of the framework. This can cause a whole bunch of headaches if you decide you want to pull in new functionality perhaps not supported by the framework.
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.
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.
I encourage you to try Zwitterion, that's exactly its goal
> My C# editor
Which do you use?
Which do you use?
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.
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.
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.
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.
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.
Appears to have goals similar to 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? :)
Maybe you have set your internal clock to 2020 a bit too early? All the releases are recent: https://github.com/lastmjs/zwitterion/releases
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.
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.
Which "box" are we talking about?
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!
"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."
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.
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).
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.
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.
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".
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?
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.
Great feedback on the README, thank you
Cool project.
"Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience."
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.
Exactly. Zwitterion relies on ES modules in production and development, so bundling is not strictly necessary. See the README for information on performance implications.
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.
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.
"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.
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.
nor common.js
I don't plan on supporting common.js. See this issue for CSS and images: 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.
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.
But again what is the advantage over parcel?
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.
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.
A couple things I noticed when comparing to webpack:
1. This doesn’t bundle
2. This doesn’t support source maps
1. This doesn’t bundle
2. This doesn’t support source maps
Come on, it clearly says it's not a bundler.
> Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience.
> Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience.
It does, but the title of the HN post says "Webpack killer." That seems misleading.
Thanks for the feedback, seems like sourcemaps will be needed, shouldn't be a problem: 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.
Zwitterion is not a bundler. I believe the world will move away from bundling, and that Zwitterion can replace Webpack eventually.
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>
You should be able to set the MIME type: 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
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
Awesome! thanks for the heads up!
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.
Webpack does more than just module importing though. Tree shaking, minification, uglifying, compiling SASS and a lot more.
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.
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
>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?
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?
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
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.
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.
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?
Like, what made the good days go bad? What is this supposed to be better than?
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.
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.
Exactly
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).
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).
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".
Seriously: it's like you're trying to nuke the moon. This is why people legitimately grief about "the ecosystem".
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.
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.
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.
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.
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.
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.
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.
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.
I'm not sure where this idea has come from, but WASM is designed to run alongside Javascript. It isn't replacing it.
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.
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.
Indeed, I tried Blazor and a simple Hello World page loaded about 7 megabytes of DLLs in the browser just to show some text.
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.
Did they plan to get rid of this somehow? What about lazy loading (runtime and/or userspace code)
Have you actually used WASM? WASM is provided through JS APIs and WASM do not have DOM/HTML5 APIs so that they must be imported from JS wrapper functions. Therefore you will never be able to ditch when you are using WASM.
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.
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.
Is it even on the roadmap? WASM does not have access to DOM at all.
I think it is.
No they are not. Standard DOM API is not i their roadmap. There is no point of doing it when WASM has to be loaded by JS anyway.
Currently DOM libraries using WASM are implemented by importing JS wrapper functions.
Currently DOM libraries using WASM are implemented by importing JS wrapper functions.
The interface types proposal will allow to call DOM APIs from WebAssembly directly [https://github.com/WebAssembly/interface-types/blob/master/p...]
The point of doing it is of course performance.
The point of doing it is of course performance.
That's what I thought. Thanks.
>Standard DOM API is not in their roadmap.
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..."
https://github.com/WebAssembly/proposals/issues/16
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..."
https://github.com/WebAssembly/proposals/issues/16
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?