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.
Zwitterion: a web dev server that lets you import anything
111–120 of 127 posts
Re: Zwitterion: a web dev server that lets you import anything
#112Earlier quoted context omitted.
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 prefe…
> 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 le…
Re: Zwitterion: a web dev server that lets you import anything
#113>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?
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
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.
Re: Zwitterion: a web dev server that lets you import anything
#114Earlier quoted context omitted.
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…
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,…
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.
Re: Zwitterion: a web dev server that lets you import anything
#115Earlier quoted context omitted.
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
Re: Zwitterion: a web dev server that lets you import anything
#116Earlier quoted context omitted.
> 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 le…
Mobx state is local by default. Observable are just scoped to the component they are created in.
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.
Re: Zwitterion: a web dev server that lets you import anything
#117Earlier quoted context omitted.
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% o…
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.
Re: Zwitterion: a web dev server that lets you import anything
#118Earlier quoted context omitted.
> 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
Interesting. That means that the module approach isn't faster than bundling, but with HTTP2, the module approach shouldn't be slower than bundling.
Re: Zwitterion: a web dev server that lets you import anything
#119Earlier quoted context omitted.
Interesting. 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.
Re: Zwitterion: a web dev server that lets you import anything
#120Earlier quoted context omitted.
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.
> 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.