3 ms·
tl;dr watch this fantastic intro to svelte talk by it's creator: https://www.youtube.com/watch?v=AdNJ3fydeao https://www.youtube.com/watch?v=AdNJ3fydeao , it co
by hardwaresofton 7y ago
tl;dr watch this fantastic intro to svelte talk by it's creator: https://www.youtube.com/watch?v=AdNJ3fydeao https://www.youtube.com/watch?v=AdNJ3fydeao , it covers some of the growing pains of React that svelte addresses.
While it might look like the frontend is going around in circles, there are major & minor differences between the technologies, and they have each introduced novel (to JS at least) things... Off the top of my head (this timeline might not be right but it's how I went through it at least):
- Backbone got you away from jquery spaghetti, helped you actually manage your data & models. Often paired with Marionette to handle views (if you squint this is the precursor to components) and bring some order in that part of the app.
- Angular bundles backbone's data handling (services), marionette's orderly view separation (views, directives), but they made a fatal mistake in the apply/digest cycle and maybe encouraging a bit too much complexity. Angular is everything bundled together, with consistent usage/documentation/semantics, a familiar programming pattern (MVC), and a large corporate sponsor in Google it caught on like wildfire.
- Knockout sees Angular's MVC, laments it's complexity and focuses on MVVM -- simple binding of a model and a relatively simple reactive-where-necessary controller
- React comes along and suggests an even simpler world where the only first class citizen is components and everything else comes separate (this isn't necessarily new, there is an article out there comparing it to COM subsystems for windows). React is almost always used with react-router and some flux-pattern supporting data management lib -- these are also departures from how angular, backbone and knockout structured in-application communication (backbone was pure event bus, angular had the usual MVC methods, knockout was just callbacks -- if you have a handle to an observable when you change it things reload).
- Vue sees the complexity that React grew to (case in point: shouldComponentUpdate) and devises a much simpler subset along with a new way to handle reactivity -- using the `data` method of a vue component. Vue made a lot of decisions that helped it stay simple and small yet very productive and this is in large part thanks to React existing before hand.
- Svelte comes on the scene and realizes that truly optimal rendering could be achieved by just compiling away the excess and eschewing the virtual dom all together in most cases. No need to track all the structure if you compile the code with the updates necessary. Don't quote me on this but I think a whole host of things influenced this project -- smarter compilers, better type systems, the ideas around zero cost abstractions & doing more work at build time.
- Ember (formerly SproutCore) is actually an anomaly because it tries it's best to be both angular like (so large, and usable by large teams) and keeping up with the tech as it evolves (see: Glimmer, Octane). Ember also has some innovations, like Glimmer's VM-based approach -- turns out you can just ship binary data representing how to draw your components to the browser and skip a bunch of JS parsing, if you bring your own virtual machine that is optimized to draw the components.
As all this moves forward, there are ecosystem pieces like typescript that have gained tons of steam and changed how people are writing JS code these days.
- Zelphyr 7y agoThis is literally the first time anyone has ever put together a cogent argument for why the framework du jour exists. Thank you! I still personally feel like I can usually get more done with pure Javascript but, as I said in my original post, at least they appear to be headed in a better direction. I did a project in Vue last year and it didn't entirely suck. Unlike the nightmare that was an Angular project I did two years ago.
- hardwaresofton 7y agoOh definitely -- when you can get stuff done with pure javascript it's beautiful -- but once you notice yourself doing too much, it's time to pick one of these small frameworks. BTW, you should check out Mithril[0], it's my current favorite, it's very small and self-contained yet very complete. It's got a slow, cautious moving community, and just enough of what you need and virtually nothing you don't -- very easy to use without bundling at all. Also, the web components spec[1] is on the horizon and once it lands (and most frameworks support some mode where they spit out web components) we're going to get interop for free. Also pro tip if you're going to start a new project these days and you need to get in the whole bundling swamp, use parcel. It's amazing, almost always zero config or close to it, and just works[2]. [0]: https://mithril.js.org https://mithril.js.org [1]: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components [2]: https://parceljs.org/ https://parceljs.org/
- hardwaresofton 7y agoCommenting on my own comment, but Polymer[0] also deserves some love! v3 looks really amazing ergonomics wise, and it's the most web-standards friendly. The early demos of polymer (some showing being able to just drop a <google-map/> on your plain HTML page) really were mind-blowing. Also, it's actually in use on a bunch of google properties, like Youtube (you can actually see on some of the older pages that some URLs have a some use_polymer query parameter that turns it on/off). Polymer is really interesting because it represents a kind of return to the early web but with all the new-web thinking -- just drop some custom component on your page (so only needing to think in HTML) and you're good to go. [0]: https://polymer-library.polymer-project.org/3.0/docs/about_30 https://polymer-library.polymer-project.org/3.0/docs/about_3...