91–100 of 127 posts
"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.
nor common.js
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.
Good old days of web development didn’t ever disappear - you can still include normal JS code directly through the tag if you want.
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?
In "the good old days", you would just import a script using a normal 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.
Earlier quoted context omitted.
Come on, it clearly says it's not a bundler. > 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.
Zwitterion is not a bundler. I believe the world will move away from bundling, and that Zwitterion can replace Webpack eventually.
Earlier quoted context omitted.
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.
Can anyone point me to a workflow where the cognitive load is similar to how it was in the good old days? i.e. some thing that does everything for me apart from the bit where I write application and presentation code? That mostly just works and doesn't require me to understand the whole stack. Because when I switch to other languages/environments I can most remain blissfully unaware of the plumbing that keeps the thi…
Can anyone point me to a workflow where the cognitive load is similar to how it was in the good old days? i.e. some thing that does everything for me apart from the bit where I write application and presentation code? That mostly just works and doesn't require me to understand the whole stack. Because when I switch to other languages/environments I can most remain blissfully unaware of the plumbing that keeps the thi…
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.
Earlier quoted context omitted.
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…
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 mentio…
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.
>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?
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?
My 2c about what this is referring to: In "the good old days", you would just import a script using a normal 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…