I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the koolaid and go all-in and do my best with Svelte.
6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don't like Svelte very much.
I think Svelte is clever, and interesting, and I'm glad it exists. But I found a few points insurmountable:
- Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
- Special syntax for reactivity is not javascript
- I find the javascript-native flexibility of JSX far more expressive than any custom templating
- There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
- Two-way data binding is a constant source of bugs
- Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
- The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
- Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
- The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
- Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
- The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
I've not used any Svelte significantly yet, so your points may stand.
I have, however, written React for years. If anything in Svelte is more confusing to juniors than how useEffect works, especially in conjunction with unstable references, I would be literally amazed.
useEffect is a loaded automatic pointed at your face if you don't fully understand it. It is truly a terrible API due to how intimately you have to understand JavaScript for it to always work properly.
I can't imagine anything worse in Svelte. If there is, I'd love to hear it.
I actually think that useEffect is an amazing abstraction. It lets you group related functionality like subscribing and unsubscribing into one place and makes it very difficult to leak stuff or use stale values.
I didn’t write many class components beforehand though, so my mental model didn’t have to change all that much.
I wrote a lot of class components and getting used to effects was a 2-week-long headache for me. But then it clicked and I can't go back ever again. Hooks are really nice abstraction. However, sometimes I would like people to name their effects: `useEffect(function clickHandler() {})`, but I understand it looks ugly.
I don't disagree that useEffect is a great extraction overall. But the mental load to understand it vs. explicit lifecycle methods is significantly worse.
The ability to subscribe is indeed amazing (this was much more verbose in class components).
Same experience, I've started working with React when Hooks were introduced in a greenfield project. My last experience with JavaScript was jQuery and Angular 1. I was blown away by the functional-declarative approach of React Hooks, I can't believe that people haven't used it before.
agreed. transition from classes to hooks and useEffect was confusing at first but it now seems very predictable and sensible (does get a little hairy when you have one effect dependent on another).
just started writing my own named effects (eg useAuth() for encapsulating firebase auth) and still in a bit of an uncanny valley with doing that - but again it's very logical once you get used to it and actually in the end a simpler mental model of component state.
never want to go back.
junior devs, start with useState, it'll all flow from there.
If you use `<script setup>` in Vue, yeah it's some compiler magic similar to Svelte, but otherwise that's not really the case, for example Vue tracks depdendencies using ES6 Proxy, which is just a language feature.
Nothing about its usage implies what it actually does. It's about API affordances. You can't simply just read the code as someone inexperienced with React and say "oh, I know what this does". Returning a closure as the result of another closure has no inherent meaning as to when that closure would be called, because there's no "name" for that functionality.
And don't even get me started about the dependencies array, which has different behaviour whether you omit the argument, or pass an empty array, or pass actual `useState` dependencies, or pass other unrelated variables. Again, it's something you just "need to memorize" to use React.
If I hadn't been using React for many years before they introduced useEffect and various other hooks, they would have all been incredibly confusing. They still are really confusing when used in "clever" ways, especially with developers being allergic to writing comments. Even something as simple as `// this will do X when the component unmounts` make reading usages of useEffect 10x easier (vs. having to remember what happens when you return a function)
Sometimes I do miss the simplicity of componentDidMount... I guess you can always still write class-based components. Too bad they're not in vogue anymore! Feels like every library is hooks-based these days.
Totally agree re comments. They're necessary. Hooks do have huge advantages for composability and flexibility, and that can't be denied. But the API is just so arcane.
If my company wasn't a React shop, I'd probably be using Vue. I used Vue at my previous company and liked it a lot.
Headless libraries like `react-table` that use hooks are a revelation though. So nice to get pretty much all the behaviour you could ever need, without it making UI decisions for you. Difficult to use at first and wrap your head around, but hoo boy is it great to have the power to fully control the rendering!
I agree it has. I think this is because hooks have been talked about by facebook as the future of react. There seems to be no appetite for class based react improvements in the future. No wonder people move to the thing that will be better supported, regardless what it is.
useEffect makes easy things easy and hard things very hard indeed.
After building a few non trivial apps in React with hooks I'm convinced that what you really need for that model to work smoothly is a new language that tracks things like hook dependencies for you.
The ESLint plugin helps. But it depends on static analysis. And static analysis is fundamentally incapable of taking advantage of any information only available (or more easily accessible) at runtime.
One limitation that pops up fairly frequently in my experience: Only React's first party hooks can get exceptional treatment by the plugin, i.e. the setState function returned from useState can be assumed to never change and omitted from dependency lists, because those cases are hard coded into the static analysis. There's no way for custom/third-party hooks to indicate to the plugin that the thing they return will never change in the same manner, even if all they're doing is passing through a setState function directly from a useState call that will very obviously also never change reference, for instance.
They can probably offer some rudimentary support for this use case with static analysis by offering some kind of exceptions API for the user to spell out the names of the hooks and return values that should get this preferential treatment, like they have with the additionalHooks config option [1], but the DX around integration with third party modules is going to remain a messy unsolved problem.
Language/runtime level support for this pattern would hopefully be flexible enough to know that the thing we returned from our custom hook or third-party hook is fundamentally the same thing as (or shares some runtime property with) the setState returned from a useState hook, and treat it the same way, regardless of what our hook is called or how it's implemented or where it's from.
Unfortunately it sounds like the React team is planning to double down on static analysis to improve hook DX, so this doesn't seem to be an area they'd be likely to invest in. I think that's a shame because static analysis is much more difficult for users to extend and experiment with new paradigms for than runtime abstractions, and will start to stifle innovation in the ecosystem as we come to rely on it for more and more heavy lifting.
[1] Which, by the way, stops working as soon as you deviate even a tiny bit from the assumptions made in the static analysis, in ways that would be completely trivial to infer as functionally identical for any runtime system. The only way to address these shortcomings is to send in a PR to make the static analysis make fewer assumptions (unlike a runtime system which you can usually extend through some clever wrapping if it's just a function), for which YMMV: https://github.com/facebook/react/pull/20051
I agree with all of this except your terminology: static analysis of javascript can't solve this problem because of the limitations of the language semantics. Static analysis in general could, I think. It just might require a different language with different semantics.
Perhaps a shift in mindset about how to approach using Svelte would help. Svelte is not React, and using React for an extended period really changes how you think about frontend code (structure-wise etc).
As a quick example, the Svelte 'ecosystem' is simply the Javascript ecosystem, which existed well before React. You can import any npm module to a Svelte app. Outside of the React-specific packages (which I argue are overkill), such as Redux or Redux-enabled form libraries, what are you missing? Pre-styled components like calendars, modals, popups, are available in a range of vanilla-JS packages. Anything more than that and it's possible that React thinking has over-complicated your approach.
I'm looking forward to picking up Svelte and just going back OOP for state management. Immutable state with React was a massive eye opener, but right now I think OOP is just better for state management, especially with all the insights gained from using React.
I am really curious to hear about specific examples of some of these points. Specifically:
> The abstraction leaks and when it does, it requires a good mental model of Svelte's magic.
Maybe because I have familiarized myself with how Svelte works I haven't noticed anything like that.
> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
I suspect this is from trying to use React patterns in Svelte, which I've seen quite a lot in people asking questions on Reddit. But I'm sure there are some things like that, could you give an example?
> Two-way data binding is a constant source of bugs
Again, very curious to see an example of this.
> It's not possible to write a one-line function component or similar
What was your use case here? I haven't found myself wanting to do that anywhere.
Is it surprising that two-way data binding is a source of bugs? We learned that lesson from Angular, and it influenced React’s preference for one-way dataflow.
Any error-prone pattern can remain useful with enough discipline, but we've learned time and time again that relying solely on discipline to cover for error-prone patterns doesn't scale.
Define "we". :) I understand this sentiment though, and I also understand designing a flexible system with zero footguns is nigh impossible. My point however was that two-way databinding is not rare in React, and there are other potential footguns to be had in idiomatic React anyway (hooks, React Context).
I realized maybe we have different definitions of 2-way data-binding also haha...
My objection is towards the Angular 1 style patterns where by passing some local component state to some children, you also implicitly allow those children to update it by binding it to some prop or by mutating it directly. This means the moment you need to share some piece of state, you can no longer reason about the state of your component in isolation nor control the ways in which it can be updated. This is at the core of what makes this approach so error prone IME.
In React, state is passed from parent to children as read-only values for which direct modification has no effect (this is the "unidirectional data flow"). The only way for a child component to update the state of a parent component is for the parent to explicitly pass down a function that exposes that functionality as part of its explicit API contract with its children.
Even in the worst case where we just naively pass down state updater functions directly (this is the case that's most similar to Angular-style 2-way-binding, which might be what you're referring to), this still results in state updates that are far easier to trace and debug as you can simply follow the function reference down to the call sites (instead of having follow all use cases of the state you passed down and trying to figure out which use cases bind or mutate). In the best case, it allows for components to offer only the minimum possible API surface to children by further restricting the set of possible state transitions (i.e. passing down openModal, closeModal functions, instead of the setIsModalOpen state updater function directly), and you can look at the parent component in isolation and confidently assert that no other possible state updates can possibly occur.
FWIW I don't have much experience with Svelte, so can't speak for which approach it's more similar to. But when I hear 2-way data binding the Angular style is the first thing that pops up in my mind from all the PTSD, so if Svelte's approach is more similar to the React style then I have nothing to object to.
Not to argue semantics, but that pattern is still called two-way databinding in my neck of the woods. In this deprecated page from the official docs, two-way databinding is defined as:
> Two-way binding — implicitly enforcing that some value in the DOM is always consistent with some React state — is concise and supports a wide variety of applications.
It's not an abstraction leaking, it's an important point to understand about mutating objects.
You are allowed to use `const` to declare an object and then modify its properties, because modifying properties is not the same as reassigning.
You're absolutely right that it's something that might catch you out, but not understanding the difference between reassigning and mutating is likely to lead to other bugs and falling into other traps in future.
(by 'it's not an abstraction leaking', I mean 'the abstraction's behaviour is consistent with the behaviour of the language' - I guess it's a subjective opinion that it's not leaking)
Other reactive frameworks like MobX will react when you only mutate objects. APIs like the useState hook at least make it obvious that you need to replace the whole object. Svelte on the other hand presents this "it's cool man, just change your plain JS state like normal!" paradigm, and it would be very reasonable without being told otherwise to assume that this applies to mutating objects as well. But then it doesn't.
If re-assignment of the whole object is what I have to do anyway, I'd much rather just be given an API that's slightly clunkier but makes that fact obvious. Otherwise the behavior will be surprising and error-prone to those not closely familiar with it yet.
>Well, let's see about that. React components are driven off state, and setState calls are sort of like data events. And React's Hooks and JSX are basically declarative. So what's the issue here?
>Well actually very little. There is only one key difference, React decouples the data events from component updates. In the middle, it has a scheduler. You may setState a dozen times but React takes notice of which components have been scheduled to update and doesn't bother doing so until it is ready.
>But all of this is a type of buffering. Not only is the queue filled by the state update event, but the scheduling of processing that queue is as well. React isn't sitting there with some ever-present polling mechanism to poll for changes. The same events drive the whole system.
>So is React not reactive? Only if you view reactivity as a push-only mechanism. Sure React's scheduling generally doesn't play as nice with push-based reactive systems as some would want but that is hardly evidence. It seems to pass the general criteria. But it is definitely not typical reactivity. Know what else isn't? Svelte.
Using Svelte finally gets me back into the joyous productive groove that I used to enjoy so much when developing with OpenLaszlo, using prototypical "instance first" declarative constraint based programming (beyond what the kids call "reactive" these days), but with standard unbastardized JavaScript and HTML instead of Flash and XML.
There's a lot to learn from past systems that predated React and Svelte, including OpenLaszlo, Garnet and NeWS, which I've used and love to explain:
>OpenLaszlo is a discontinued open-source platform for the development and delivery of rich web applications. It is released under the Open Source Initiative certified Common Public License (CPL).
>Oliver Steele describes "Instance First Development", which the language he designed, OpenLaszlo, supported through the "Instance Substitution Principle". I've written about it here before, and here are some links and excerpts.
>In the right context, prototypes can enable Instance-First Development, which is a very powerful technique that allows you to quickly and iteratively develop working code, while delaying and avoiding abstraction until it's actually needed, when the abstraction requirements are better understood and informed from experience with working code.
>That approach results in fewer unnecessary and more useful abstractions, because they follow the contours and requirements of the actual working code, instead of trying to predict and dictate and over-engineer it before it even works.
>Instance-First Development works well for user interface programming, because so many buttons and widgets and control panels are one-off specialized objects, each with their own small snippets of special purpose code, methods, constraints, bindings and event handlers, so it's not necessary to make separate (and myriad) trivial classes for each one.
>Oliver Steele describes Instance-First Development as supported by OpenLaszlo here:
>LZX is a prototype-based language: any attribute that can be attached to a class definition, can be attached to an instance of that class instead. This is handy in UI programming, where there are a number of objects with one-off behaviors. It’s also handy in prototyping and incremental program development, where it creates the possibility for a novel kind of refactoring.
>[...] The mantle of constraint based programming (but not Instance First Development) has been recently taken up by "Reactive Programming" craze (which is great, but would be better with a more homoiconic language that supported Instance First Development and the Instance Substitution Principle, which are different but complementary features with a lot of synergy). The term "Reactive Programming" describes a popular old idea: what spreadsheets had been doing for decades. [...]
>Oliver Steele (one of the architects of OpenLaszlo, and a great Lisp programmer) describes how OpenLaszlo supports "instance first development" and "rethinking MVC":
>[...] I've used OpenLaszlo a lot, and I will testify that the "instance first" technique that Oliver describes is great fun, works very well, and it's perfect for the kind of exploratory / productizing programming I like to do. (Like tacking a sailboat against the wind, first exploring by creating instances, then refactoring into reusable building block classes, then exploring further with those...)
>OpenLaszlo's declarative syntax, prototype based object system, xml data binding and constraints support that directly and make it easy.
>OpenLaszlo's declarative syntax and compiler directly support instance first development (with a prototype based object system) and constraints (built on top of events and delegates -- the compiler parses the constraint expressions and automatically wires up dependences), in a way that is hard to express elegantly in less dynamic, reflective languages. (Of course it was straightforward for Garnet to do with Common Lisp macros!)
>OpenLaszlo is an open source platform for developing user friendly web based applications, which work identically across all popular browsers and platforms (Windows, Mac, Linux, IE, Firefox, Safari, etc). It's ideal for presenting and editing raw XML data generated by PHP and other web services.
>OpenLaszlo supports a rich graphics model with scalable vectors, bitmaps, movies, animation, transparency, fonts, audio, streaming media, reusable components, user interface widgets, control panels, property sheets, keyboard navigation, browser "back button" navigation, as well as advanced WYSIWYG text and graphical editing tools. In other words, OpenLaszlo is the velvet glove for the iron fist of PHP. What can OpenLaszlo do?
>Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.
>One thing I like about Brad Meyers is that he's a strong programmer, as well as an excellent researcher, so he had a first-hand understanding of the real-world issues involved in programming languages and user interface architecture, unlike many academics who talk a lot of theory but never get their hands dirty. Brad Meyers understands where the rubber hits the road, and how important it is to have good tires.
>At the time I worked on it, Garnet didn't have pretty graphics like Flash, but the underlying programming system had some advanced features that are sorely lacking from most modern user interface development environments.
>Laszlo is a modern open source GUI programming system, with many of Garnet's advanced "natural programming" features like prototypes and constraints. Laszlo currently uses Flash as its virtual machine, but it's a much higher level way to program dynamic interactive web based applications, without using the proprietary Flash authoring tool.
>Garnet had a true prototype based OOP system (somewhat like Self), which is great for gui programming, because guis have so many objects that look and behave like each other except for a few little customizations (like the layout, graphical style, data source and call-back behavior).
>Garnet also had an automatic constraint system, which enabled you to simply define any attribute as a formula that depend on other attributes, without needing to worry about how and when the values were calculated. Garnet's constraint system automatically figured out the dependences of each formula, and automatically and efficiently recalculated and cached any values that needed to be updated, but only when necessary.
>With constraints, you can make a button inside a window, and define its left edge to be ((parent.width - self.width) / 2), and it will automatically remain horizontally centered in the window from then on, without you (the programmer) having to worry about what to do when the parent window's size changes.
>Without constraints, you have to manually write all the code that changes the button position whenever the window size changes, which results in code scattered all over the place in different classes and handlers and intermediate objects.
>Constraints are much easier to use and more general purpose than resize handlers, springs and struts, complex MVC updating schemes, and other Rube Goldberg devices.
>Constraints are especially useful for user interface programming, because they save you from having to write lots of annoying boiler plate and error prone code for handling updates (registering, chasing down dependencies, detecting changes, notifying updates, all happens automatically).
>Constraints make GUI programming much easier, but they're also useful anywhere in your program where one value is defined in terms of other values that might change at any time.
>Once you've tasted a programming language with constraints, you will not want to go back. Programming without constraints is like writing in machine language: error prone, low level, tedious, inefficient and mind numbing.
>Constraints are like structured programming for variables: In the same way that it's better to use loops and conditionals instead of gotos, it's also better to use declarative programming that says what you mean, instead of imperative peeks and pokes and side effects.
>Constraints let you write easy to read code, and concentrate on the interesting high level stuff that matters. You can go back later and change the layout of a complex GUI, without rewriting lots of fragile layout and event hanling code. Look at any MFC program to see how bad it can get without constraints.
>Constraints are natural and close to the way you think, because they let you declare a variable and the formula that defines its value in one place, instead of scattered all around the code. They off-load the tedious task of tracking down and maintaining all the dependencies from the programmer to the computer, which is much better at that kind of stuff.
>Garbage collection is like constraints: the computer can do a much better job than the human at performing the task perfectly, so spending some cpu time on automatic garbage collection and constraint maintenance is well worth the significant increase in programmer productivity and software reliability.
>Garnet had a prototype based object system. It was implemented in Lisp with a system called KR (Knowledge Representation, classic AI "frames" with slots and inheritance). KR was extended with an automatic constraint system that parsed the formula expressions (written in Lisp macros), figured out the dependences, wired up and maintained the dependency graph.
>An expression like "((parent.width - self.width) / 2)" would depend on self's width slot, self's parent slot, and parent's width slot. If any of them changed, then that formula would be automatically invalidated, and only recalculated on demand when it (or something that depended on it) is required.
>The cool thing was that you can make a prototype object, like a button, which has sub-structures like a label, border, drop shadow, etc. The sub-structures can be constrained to the button's dimensions, the label is centered in the border, and the drop shadow floats below and to the right, so the button's layout is automatically updated when it moves or resizes.
>The text color and border fill can depend on the button's "hilight" variable, so they automatically switch between bright and dark when you press the button (the input handler just toggles the "highlight" variable, and the graphics that depend on it are automatically updated).
>Now that you've composed and constrained a button to look and feel how you want, you can use it as a prototype to make other similar customizable buttons instances. Each instance can itself override the prototype's graphical properties, label text, action, etc.
>Instances of a prototype all magically inherit (instances of) the sub-structure of the prototype! It all just works the way you'd expect it to (with a lot of plumbing going on automatically behind the scenes). There's no need to make a separate class for each different style of button or action - prototypes let you customize any instance itself!
>Like Garnet, Laszlo is an advanced open source user interface development environment that supports prototype based OOP with constraints.
>Unlike Garnet, Laszlo deeply integrates recent trendy technologies like XML, JavaScript, Flash, data binding, networking, XML/RPC, SOAP, ReST, Java and Tomcat.
>Laszlo has a class/prototype based object system, and it (currently) uses the JavaScript runtime in Flash as its virtual machine. But it's more than just another way to program Flash.
>Unlike raw Flash, The Laszlo language is easy to learn and Laszlo programs are easy to read and write thanks to prototypes, constraints, declarative programming, and instance-first development.
>AJAX is a new buzzword for old (but not bad) ideas.
>Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.
>Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.
>For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.
>Before he made Java, James Gosling wrote the NeWS Window System. [...]
>NeWS (Network extensible Window System) is a discontinued windowing system developed by Sun Microsystems in the mid-1980s. Originally known as "SunDew", its primary authors were James Gosling and David S. H. Rosenthal. The NeWS interpreter was based on PostScript (as was the later Display PostScript, although the two projects were otherwise unrelated) extending it to allow interaction and multiple "contexts" to support windows. Like PostScript, NeWS could be used as a complete programming language, but unlike PostScript, NeWS could be used to make complete interactive programs with mouse support and a GUI.
HN discussion of "Sun's NeWS was a mistake, as are all toolkit-in-server windowing systems (2013) (utoronto.ca)":
>agumonkey>I've always been curious about NeWS but the web is quite short of demos about it (not helped by newspapers called Sun either). Do you know sites with videos about it ?
>Thanks for asking! ;) I've put up some old demos on youtube, and made illustrated transcriptions of some, and written some papers and articles. Sorry the compression is so terrible on some of the videos. Here are some links:
This is unfortunate for your team, but most of your conclusions are not adequate.
1. Actually, Svelte has much less "magic" involved than React. Sveltes abstractions are not leaky. The reactivity might be more difficult to understand. But the rules are well defined. They are strange - no doubt - but not leaky. When looking at the generated code it's actually much more obvious what is going on than what React is doing. React on the other hand has some leaky abstractions. The biggest one is the effort you have to put into to make it efficient (memoization). Also, hooks.
2. Two way data binding is not a constant source of bugs. Then every team using Vue, Svelte, Angular, React with MobX would have those troubles. I've done 8 years frontend dev in a large company using React and Angular (and recently Vue 3) with different teams. The bugs come from people not technology. I've seen no other correlation there.
Granted, React has the largest ecosystem of all of them, but what do you actually need?. In that regard, Vue hits the sweet spot.
> Two way data binding is not a constant source of bugs
Every team using AngularJS _did_ have those problems (not to say it didn’t have some niceties also). It was one of the big architectural changes in Angular (2+) as a direct result. React does not have this feature; passing down a setter function is not the same as automatic 2-way binding.
As to your first point, different things feel like magic to different people, so it’s really hard to debate this with other people with different perspectives unless maybe your talking about single specific instances. It’s like trying to tell someone they don’t feel cold because you don’t feel cold or vice versa.
Sure, but it maps 100% to an expected JS syntax and improves readability (subjective).
From
<div attr1="str">{children}</div>
To
React.createElement("div", { attr1: "str" }, children)
Custom templating is not like that.
Subjective indeed. If the goal is to leverage the full expressiveness of JavaScript, you could just alias React.createElement to something like `h`. Or use something like https://github.com/caderek/react-plain
Yeah, but that's harder in practice. You often copy html snippets into your code, for example from tailwind or bootstrap samples. This is easier in JSX syntax; you'd just need to copy and fix up some attribute names.
> You often copy html snippets into your code, for example from tailwind or bootstrap samples. This is easier in JSX syntax; you'd just need to copy and fix up some attribute names.
I literally never do this, but I suppose there are people who use React/JSX as a glorified templating library. Even then I probably wouldn't do this and rather use a proper templating library where HTML is valid.
JSX is more akin to a macro than a DSL, which is why I strongly prefer it. Debugging errors in templating languages is invariably more frustrating and time consuming.
More on point, being constrained within the special language is miles away from the constraint of JSX, which is essentially limited to only allowing expressions, because the macro expands to expressions. Everything else is fair game, and that makes it far more expressive.
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
I see this in every project where juniors or just undisciplined developers get to run without oversight. There's nothing special about Svelte stores here. Any store has this trap. There's no framework or library solution for good discipline about if, where, and how you share data.
> - Special syntax for reactivity is not javascript
Well, JSX syntax isn't JS either. And hooks semantics is not JS.
Learning new syntax is easy but we should consider how much the new semantics cause mistakes and to what extent they are incompatible with tools such as linters.
As I see it, the main issue with new syntaxes is the fact that they break compatibility with existing tooling. JSX is not fundamentally different in this regard, except for the fact that it gained so much mindshare that it brute-forced its way to getting first-class support in editors, language servers, different frameworks, even TypeScript. I don't predict that very many new JS-adjacent syntaxes will get that treatment from the industry.
True, although Svelte's syntax is chosen cleverly in a way that is not incompatible with existing tooling. (Starting a statement with $: is syntactically legal JS and a no-op.)
Another question is how much of Vercel's resources would it take to contribute Svelte support into all the major tools.
It's not technically incompatible, but it's mostly parseable nonsense in the plain language. So it really only serves to make sure syntax highlighters still work, which is just one of many aspects of tooling
Considering JSX's current level of support involved cooperation from multiple FAAMNGs, I doubt Vercel could match it
Can you give an example of tooling that is not compatible with encountering the $: label? I can only think of a linter complaining about an unused label "$" or a redefined label "$".
Compare this e.g. with how React linting has to know which functions are actually (custom) hooks, and they cannot have any idea about the semantics of custom hooks.
I'm sure it will let you make that label, but it won't be able to make any sense of it. Maybe I was slightly wrong that only syntax highlighting will be helped by the "standard" syntax, but the point remains that none of the (existing) tooling can properly make sense of those parts of the code. That $ isn't really a label, it's a reaction, which your linter knows nothing about and can't help you with; at best it can "work around" it.
> I find the javascript-native flexibility of JSX far more expressive than any custom templating
JSX is the most significant contribution that React brought to front-end programming. Personally I don't always use React, but I use JSX quite often. It's intuitive in a way custom syntax (the dozens of) never will be.
I'm still appalled by the state of many things in JS tbh. I have the impression you have to perpetually move your codebase by adapting to your stack underlying changes, may it be the build system, the framework, tools or libraries that deprecate themselves quickly...
The reasons that made start Opa are still there: There should be an easy single language to program web apps and a clean coherent single stack to build and run them.
Today, I mostly code in Go and I love it (single stack, tests built in) despite the lack of generics.
On the front-end, it's another story. If I have time one day, I'll rebuild something in that space.
React has special syntax for reactivity. What is useEffect? Is it a native JS function?
I don't understand why JSX is still being used. Why should I a HTML developer change how I write HTML for a framework? And why doesn't it allow style tags?
Svelte lets me use HTML, style tags even a script tag. The only framework that is close to HTML is Svelte. The second version even had .html extension which is now .svelte.
You can 100% use style tags in React, they just aren’t automatically wrapped in module/component scope. Just like normal HTML style tags, actually.
As for JSX, I personally have always hated HTML template languages (“now which slightly-different version of the for iterator does this template get use?”) but I also recognize that there are other people who have opposite preferences. JSX-in-JS and template-directives-in-HTML are both valid approaches and it’s great that there are solutions to cater to various preferences. Trying to argue one down because you don’t like it is like arguing that your favorite color is factually superior.
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
I don't see how having a reactive store has anything to do with the latter. But I find this ironic because every React codebase I've ever seen has components that import globals from other files (whether they be constants or POJOs). I don't find this inherently wrong, but it's exacerbated further by "Providers" and React.Context which seems idiomatic at this point.
Every reason you’ve stated are reasons I’ve switched from one proprietary or open source framework before react to react. 2 way data binding is a mental prison in big apps, I’m sure there’s a good implementation somewhere but I’ve yet to see it.
I don't like templating, it's too restrictive, feels like back to the 90s. This is typically aimed at coders who secretly don't want to code, and fall for tools that seems like they can avoid it.
What I like most about React is being able to break down views into functions and compose them. And if I have the choice, I prefer pure javascript and just a small helper function for Document.createElement instead of JSX, it makes it even more powerful, flexible and less verbose. You can already programmatically create elements in Javascript, I don't understand at all why people use "frameworks" for this, JS and HTML is already a view and a controller, just write the app? A complex single page application needs a couple of dozen lines of helper functions, that's all, why invent a whole new language on top of the language that in the end only restricts what you already have in the first place? This is spring framework enterprise hell all over again in the frontend
I've been developing websites and apps with Svelte for almost 2 years now, and my experience couldn't be more different from yours.
> - Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
Since Svelte runs vanilla JS and works with the DOM directly, my experience debugging any "magic" has been extremely straightforward compared to other frameworks. I'm curious what specific issues you have encountered.
> - I find the javascript-native flexibility of JSX far more expressive than any custom templating
Not once have I wished I had JSX in a Svelte project, and the readability of Svelte's minimal templating sugar is a breath of fresh air for myself. What's an example of a limitation you've faced in practice?
> - There are major trade offs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte.
I would love an example of this, as I've yet to run into any situations where I felt there was something I couldn't accomplish at runtime.
> - Two-way data binding is a constant source of bugs
It's rare that I use two-way data binding, but in the rare cases where it's appropriate, it's very convenient. The improper use of a utility doesn't necessarily discredit the value of said utility.
> - Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
I'm not sure this is true- with access to JS modules, stores, nullish coalescing, and lifecycle hooks, let-style rebinding can be avoided entirely.
> - Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching.
> - The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
Considering you Svelte lets you style things in a plethora of different ways (including the traditional method of external css files), I'm curious how you came to the conclusion that it's opinionated.
> - The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
While it _can_ be, a single function shouldn't be a "component"- but Svelte "actions" are an awesome feature designed to make single functions easy to compose and reuse across components. That being said, there is talk of supporting multiple Svelte components per file (although it's rather controversial and largely unnecessary in Svelte projects).
> - Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
Considering any JS library (most importantly, ones that interact with the DOM) is plug-and-play in a Svelte file- I've never found myself needing something that didn't exist on NPM. Nonetheless, the DX and power of Svelte enables us to create complex libraries and components that would ordinarily be too cumbersome or time consuming to produce in-house, and with much less code than with React. This usually pays dividends in the long-run, as custom solutions are typically easier to debug and extend.
> - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
The runtime speed is pretty low on my list of reasons I prefer Svelte above other solutions. While the performance gains from Svelte are amazing for users (especially ones with low-end devices or shotty internet speeds), the unparalleled DX, development speed, maintainability (do more with less code = less bugs = easier to maintain), community, and overall fun involved in working with Svelte overshadow the free optimization done by the compiler at build-time.
Anyways, I hope that round 2 will be more fruitful for you and your team! I'm highly skeptical that React will solve more problems than it causes when your primary bottleneck is developer experience, but I'm sure we will both be able to learn from your experience regardless of the outcome!
> Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching.
This is the gist of the whole comment. The person posting is not complaining about a bad Svelte experience, they're complaining about bad programming practices.
>Any top-level statement (i.e. not inside a block or a function) can be made reactive by prefixing it with the $: JS label syntax. Reactive statements run immediately before the component updates, whenever the values that they depend on have changed.
>In the long list of cool features of svelte, The one which I use more often is this dollar label thing. Initially, it looked strange to me but later I realized it is a valid javascript syntax. You can use it for doing side effects like useEffect of React, there is also a syntactic sugar way of declaring computed properties.
The Svelte compiler does add special SEMANTICS to JavaScript (and that's what makes it so great), but it does NOT add any special SYNTAX at all.
Although it might mistakenly appear to you that it does, if you're not entirely familiar with the well documented standard JavaScript syntax definition that I linked to above.
Your off-the-shelf code highlighters and linters will work just fine inside the standard <script> tags in svelte files, exactly like they should. That was the whole point behind Svelte's design.
However that's not the case with JSX, because JSX is definitely NOT the same as JavaScript, no matter how fuzzy and inconsistent a definition of "equality" and how many equal signs you use.
Much of this I would have expected, but this was less obvious:
> There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
I read it as: Svelte is faster in theory, but since people write bad Svelte code, it is slower than the React code the same developers would write.
My interpretation is that this can be attributed to either svelte being hard to write, or people being used to React. Both of which are a challenge to companies looking to switch to Svelte.
Wow, this should be great news for Svelte and SvelteKit! Hopefully with Vercel's backing these projects will fly off.
Having worked with React for about 5 years (with a project in Vue in-between) and now having dabbled with Svelte, there is just something more appealing working with less higher-level abstractions. Sure with large apps React does have its benefits and its ecosystem is larger by a good amount.
But there is just something about being less annoying that to me is perhaps one of the most important things with any tool. If I enjoy using it, I don't mind that it may not be the "current best choice" of the moment. People who enjoy MobX especially I think ought to find Svelte quite nice.
Sure though would wish SvelteKit was at the same level with Next.js. Fixing dev server errors is a little distracting at times.
> Fixing dev server errors is a little distracting at times
You will be very pleased with the upcoming release of Vite 2.7! It's by far the most impactful release of Vite thus far for SvelteKit. All the major known issues we've been tracking have been addressed in the latest Vite 2.7 beta (assuming that one of the PRs we're still working out the kinks of doesn't get rolled back, but either way it'll be a huge improvement!)
Svelte’s ecosystem is, in practice, actually much larger than React and any other framework because Vanilla JS works out of the box without framework specific wrappers. So just about any JavaScript package can be imported into a Svelte file and used without hassle.
The last place I worked was a React shop, before that I did most of the frontend as well and used Vue, Current place uses Svelte and I'm really glad they did/do, the continual surprise is how Svelte makes easy things easy and hard things doable.
This seems like a huge positive step forward for Svelte and the community. Big congrats to Rich!
I've been excited about Svelte for a while and recently chose to use it as the UI for a cross-platform video editing app (https://getrecut.com), with the back end in Rust. I've found it a pleasure to work with -- Svelte Stores and the Context system are especially great for sharing state, and the app feels snappy. Last few weeks most of the focus has been on the Rust backend but I'm really looking forward to building out more of the UI soon.
I've also been happy to find that its generated code is pretty readable. On one little performance-tuning side quest, I was profiling to figure out why the app was performing a Layout on every video frame, and I was able to step through the compiled Svelte component code and narrow it down to one of my own functions. I also briefly went down a path of trying to manually set the text content on an element, to see if it'd be faster than letting Svelte do it. Turned out the answer was no, but it was nice to know that level of control is available if I need it some day.
Excited to see where the Svelte community goes from here!
Do you have a mailing list I can toss my email on for when this is available on Linux? Honestly I was ready to buy it instantly before I saw the platform limitation, but it would be even better if it could run some basic filters like removing pops and de-essing, which I always struggle to get working right in Audacity (I have a screenshot saved of my filter curve because Audacity doesn't save it, it's so stupid).
It's not Linux-specific but you can sign up to hear about the Windows one (click the "Get Notified" button on the home page) and I'll let everyone know if/when there's a Linux version.
Fair warning I haven't even tried getting it to run on Linux yet... but I've been meaning to try it out, if only for the profiling and debugging tools! (rr looks really cool!)
In theory it runs everywhere because Electron, but my gut says the difficulty with supporting other platforms will come down to compiling and packaging. That's been the biggest hurdle with Windows so far anyway.
Linux packaging can definitely be confusing -- as a user I definitely prefer something like an AppImage for a program like this, which should be easy enough to provide. I wouldn't worry about making distribution specific deb and rpm packages, personally.
Yeah, rewriting it with Electron + Svelte + a Rust backend for the heavy lifting.
I looked at alternatives to Electron because I wanted to avoid the bloat, but nothing felt like the right fit. Tauri (https://tauri.studio/) is the most exciting, but I couldn't find a good way to get raw video frames into the UI without a bunch of expensive copies or serialization. I also looked at native toolkits like Qt (I've worked with it in the past) but I didn't love the idea of building lots of custom UI components without the benefit of HTML + CSS. So for now it's Rust + Electron, and I'm paying extra attention to performance.
Are you referring to ease in complexity of creating components compared to the alternatives? Because I end up with the same choice when sieving frameworks to use crossplatform. But I've been looking nto Flutter recently, although it's still in beta, it has potential.
Yeah. I talked about this in another reply but I’ve had mostly web development experience over the past few years and UI work is familiar. I didn’t love the idea of having the entire tech stack being unfamiliar. (I’m already new to Rust and ffmpeg/video stuff)
My thought process was, if I’m gonna have to rewrite the app, I may as well use the web dev skills I already have, so that at least the UI work will be in my wheelhouse. Rust is new to me, as is low-level ffmpeg stuff, both of which I’ve had to learn from scratch.
I learned Swift in order to build the Mac app, and I know from that experience that building custom UI controls while learning a new ecosystem slowed me down a lot. I didn’t love the idea of repeating that experience, and where I’m headed there’s gonna be a good bit of custom UI.
That sounds like a responsible way to divide focus. Kudos
I forget the word or the link, but I think there was a "rule of thumb" thing that circulated HN about having a limited budget for taking-risks/being-bleeding-edge, and focus in spending that on differentiating properties of your projects, while the rest should stay "old and boring"
Sounds like an easier process for you, but at the cost of your users. This proliferation of web tooling when it clearly doesn't suit the environment (desktop) is part of the reason why our software is getting slower, even as our hardware is improving.
Being very conscious of those downsides, I'm putting in extra effort to make sure it's fast. So far it seems to be working!
It uses less CPU than any other Electron-based video apps I've seen (and even less than a few Qt-based editors I tried) and it feels snappy.
I think tools like Figma have shown what's possible when enough attention is paid to performance early on – but yeah, it's one of my main worries with going with Electron and I'm trying to avoid the downsides as much as I'm able.
The ones I have less control over are memory usage and disk space. I'd love to get those down but it seems like that'd require digging into Chromium and ripping things out. Which, honestly, I looked at doing, but that code base is a beast and I'd rather get something into peoples' hands sooner.
On a related note: I think there's a real opportunity for an "Electron Lite", like some kind of custom Electron/Chromium build that turns off stuff you don't need. I suspect it could help disk usage + memory usage + startup time. Chromium's build system has lots of flags that make it seem like you can turn things off. But it didn't work that way when I tried, so I think it probably requires source-level changes, which then means maintaining those patches across Chromium updates etc. But really, though: I don't need WebRTC, or printing, or media codecs, or probably a zillion other things. It'd be so cool to be able to turn those things off at will.
If dceddia is able to add features and fixes more quickly, that's good for users too.
And if Svelte on the desktop becomes popular, people will likely come up with more efficient options. For example, a more efficient Electron or something like "Svelte Native", which could be a good thing.
I'd love if all software were more efficient, but getting up to speed on a new platform has a huge opportunity cost too.
React-native might be the close to what you're looking for at the moment. But the ecosystem is still tiny on Desktop, and I don't think it supports desktop linux at all.
I looked into it at one point and it sounded like WASM isn't as fast as native (yet?), and the main benefit would be the ability to run in a browser. That'd be useful for making a web version and I might look into it again, but for now, if I'm already shipping an Electron app, WASM seems like extra hassle with less speed. I might be wrong about this though! Happy to hear if there are benefits I'm missing.
It's pretty dam close to native. I would consider researching it again. You could do away with Electron altogether and just run it in browser. You can make it a PWA to give it that "Native app" feel so the users are none the wiser but you don't have to deal with the complexities of Electron and managing releases etc. If you want to launch a new release just deploy it to your web host and you're done for all platforms.
This is all assuming there isn't some specific OS level requirements in your app. I know there are other video editors using WASM successfully and apps like Figma.
Also curious - I'm spinning up a small side project with Rust and Svelte. Was looking in Tauri as a replacement for Electron but wondering what other approaches people have worked with (assuming this is a cross platform desktop app, that is).
I'm using quickjs (rquickjs specifically) to bind GTK's C API to Javascript and adding a light DOM wrapper (get/setAttribute, add/removeEventListener, etc) that covers all the functionality Svelte needs. I've had to make a few modifications to the compiler (<10 lines total) to get binding and CSS working but so far it's been great.
Working in GTK with hot reload and instantaneous esbuild rebuilds is.... insane.
Tauri seems like a nice option. It's not as full-featured as Electron yet but their focus on security is great to see (last I saw they were getting the codebase professionally audited). The main reason I didn't go with it was just that doesn't seem to (yet?) suit my use case with zero-copy data transfer between Rust <-> Browser.
My hope is that by writing most of my backend in Rust, that it'd be easy-ish to switch to Tauri or other options if something changes down the road.
This is such amazing news! Betting on Svelte was the best thing ever for both my career and sanity. I'm now heavily involved in the Svelte community and next Saturday we'll be hosting our fourth conference solely dedicated to Svelte.
If you're interested in checking it out the URL is here, it's free and will be streamed on YouTube: https://sveltesummit.com
There are also two watch parties that will be hosted in New York (Rich will attend!) and in Mainz, Germany.
Genuinely curious, what’s there to do about for an entire conference about a single library? For someone from academia, where conferences typically span an entire field of research, this seems extremely niche and quite boring after a bit..
Well - that might be overstating the matter; after all, academia also has workshops focused on very small niches...
...but also: it's not uncommon to find industry conferences about a specific framework, because it's not just about the framework - it's about the uses to which that framework can be put, and about interacting with the community around that framework. Both of those facets permit a lot of variety, especially for foundational tools (e.g. web application frameworks, UI libraries, database platforms, etc.)
Because the last Computer Science Conference I went to wasn't small and cozy enough that I got to hang out and personally chat with the leaders in the field.
Rich Harris has done a lot of great work. Until esbuild came along, Rollup was the only sane JS bundler for those of us who can’t stand Webpack. Svelte has some interesting concepts, albeit I am planning to stay with React. His code is always interesting to read.
Then there’s Vercel. I was a big advocate for them years ago, back when they were Zeit. I used them in production at multiple companies and I contributed to their CLI to improve its error handling. But they really screwed me as a vendor with changes to their hosting platform and then again with changes to their authoritative DNS service. They broke every promise or expectation they ever set with me and reversed practically every facet of their original philosophy as a platform. They are bordering on being on my “never again” list. I hope Rich is genuinely able to stay independent creatively.
Hi Lee. I appreciate the offer but the simple answer is that Vercel abruptly pivoted away from backend oriented services. That broke everything I built on the Now v1 platform and there wasn't anything to do but switch to other providers. It was stated that migration to Now v2 would be simple but that never materialized in time for the Now v1 shut down. On top of that, I encountered a lot of bugs with the deployment system when the new infrastructure started coming online, where it would auto deploy to data centers that couldn't run Now v1 apps and then the CLI would crash. I tried to be understanding, given you were a startup in a competitive space. It was unfortunate but I decided to at least continue using your domains and DNS features. But then the format of the zeit.world nameservers changed a couple of times and again with relatively short notice. Other frustrations... the domain search & buy page used to be public, now it requires a login for seemingly no reason (trying to keep bots out?). The marketing of early Zeit was all about embracing open standards and now Vercel is basically the exact opposite, with proprietary solutions for running frontend projects being at the heart of the product. I can only guess as to why it unfolded that way, but the transition was extremely rough for people who bought into the original vision. I just logged in now to transfer out some domains I still have in there and discovered that years later you still don't have a way for customers to change their domain's nameservers other than contacting support. That's just user hostile. A lot of people would say that is a dark pattern. I've literally never encountered another registrar that didn't have a simple button to change my domain's nameservers. Having to contact support to do this was excusable when your company was only a year old, but at this point it looks negligent, if not deliberate.
It's only sane if you use it raw (i.e. ESM in, UMD out), but add plugins and suddenly you have a slower and less capable webpack with lengthy config.
I'm generally a fan of Rich’s tools but they only look good on the surface generally. Svelte itself changed face 3 times already, with each iteration completely incompatible with the old one.
You are misreading. He's saying that rollup[1] was the only other option for bundling static assets besides webpack until esbuild was created. Rollup was created by Rich.
I'm tired of having to learn yet another templating language without a very compelling reason.
Why do I have to learn, what is essentially, a new programming language for each of these frameworks (Angular, Svelte, Vue, React... Do I really need to learn yet another language construct for stuff like `loops`, `if/else`, event handlers...etc.
Why must all of these frameworks re-invent the wheel?
At least with React it is most close to the languages we already have learned, JavaScript, and HTML.
From what I can tell Svelte looks similar handlebars templating with it's own unique syntax variations... I can't count how many different versions of the same thing I've had to relearn again, and again.
For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code.
And the reason these things change is because that's what needed changing. One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't think unfamiliarity is that damning a criticism.
Maybe I'm just used to switching up languages on a regular basis, but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.
<ul>{#each myItems as item}
<li>{item.title}</li>
{/each}</ul>
One is literally just javascript and html the other is an entirely different template language. You might say... JSX is not HTML... well it's very very similar... If you know HTML you JSX is very intuitive.
But React isn't just JSX. It's also the entire runtime library, hooks, event handling, forms, state handling, etc. The example you shared is a bit too simple to understand where Svelte shines because it doesn't introduce any of those concerns.
By having it's own templating language, Svelte is able to compile the templates to JavaScript in a way that addresses many of those concerns in a way that I think it easier to deal with as an end user of the framework.
If Svelte were using JSX, I don't know that it'd be possible to do everything else that it does so simply because you can write anything that's valid JavaScript in JSX whereas Svelte has just a couple of basic control structures that its compiler can parse and convert to runnable code.
No, they are JavaScript, it is array based programming wrapped in a reactive functional-declarative approach. Simply array of objects cascading with state. {#await promise} is more cryptic than any useHook function implementation.
> No, they are JavaScript, it is array based programming wrapped
Javascript has no support for array-based programming.
So, hooks are not Javascript: they look like regular function calls, but:
- they can only be declared and called before rendering
- they can't be called out of order
- they cannot be called conditionally
- they have to be called a specific name to be handled correctly by React runtime
- some (but not all of them) require dependency lists that determine how they are invoked
> {#await promise} is more cryptic than any useHook function implementation.
usEffect documentation is something like 20 pages long. The use of {#await promise} is immediately understandable from the code example, and its entire documentation fits on a page and a half
> How come they break Javascript semantics and execution flow?
wait what?
since when do they break execution flow and javascript semantics?!
useEffect(function () { }); when exactly do you think the function will be called? - correct only the "framework" defines that, but that's completly normal javascript execution and semantic.
Nah, JSX also gets converted to Javascript. The difference is in that the React runtime re-renders whole components every time something changes, and Svelte is more granular about it even during the compilation step.
That's a poor assumption that appears to be based on your personal preferences and what you're comfortable with. I personally find both require some learning, but prefer the svelte version.
And JSX isn't JavaScript and it isn't HTML, and if you know JavaScript and HTML you still don't know JSX, so you're still using "yet another language" in addition to JavaScript and HTML.
JSX is easy to summarize as: HTML where everything in curly brackets is a JS expression that gets evaluated. There are some additions (prop spreading) and restrictions (curly brackets apply to whole attribute values and element bodies only), but they're very simple.
And custom event handling attributes, camel casing, special cases like htmlFor and className, non-standard attributes being ignored except for custom elements, the style attribute, the special case of checked/selected properties vs attrs for form elements, key and ref properties. Plus all the semantics of component updates, memoizing and so on.
This is already far more to learn than the handful of simple control structures Svelte introduces.
JSX is JS. Nested brackets are simply converted to nested function calls & objects, attributes convert to properties.
This is evident when comparing conditionals, loops, etc. Instead of learning template syntax you simply use JS syntax, albeit a declarative subset (no branches).
JSX is simply syntactical sugar for nested JS, you can use it without, but it's prettier with.
One could add this syntactical sugar natively to the language spec, in fact E4x (ECMAScript for XML) share some properties w/ JSX and was once proposed to the spec.
edit: instead of downvoting, please voice how you disagree with my assessment
By the same logic we could call any structured format “is js”, because it is homomorphic to some js expressions. Are xml, pug, plist, dbf, all js? Nope, it’s all python.
I agree 100%... Adding JSX to the language spec would be interesting. It might be too heavy to include within the language spec as many JS applications do not involve the DOM at all, so then you have to essentially bundle DOM functions into every application... or common.js would omit this subset of the language.
One nice thing about JSX is that it is pretty straightforward to write the function (React.createElement replacement) that it transforms to, so you can use it to construct any complex tree-like structure. No DOM stuff is needed. For example writing a JSX factory to output a static html string is maybe 20 lines of code.
Mozilla Xulrunner and Rhino (a JavaScript interpreter implemented in Java) used to support E4X: ECMAScript for XML, the ISO/IEC standard 22537:2006, and it was removed in 2014.
>ECMAScript for XML (E4X) is the standard ISO/IEC 22537:2006 programming language extension that adds native XML support to ECMAScript (which includes ActionScript, JavaScript, and JScript). The goal is to provide an alternative to DOM interfaces that uses a simpler syntax for accessing XML documents. It also offers a new way of making XML visible. Before the release of E4X, XML was always accessed at an object level. E4X instead treats XML as a primitive (like characters, integers, and booleans). This implies faster access, better support, and acceptance as a building block (data structure) of a program.
>E4X is standardized by Ecma International in the ECMA-357 standard. The first edition was published in June 2004, the second edition in December 2005.
>The E4X standard was deprecated by the Mozilla Foundation in 2014.
>"use strict" is currently our one real opt-in boundary for simplifying the language and reducing threats by dropping legacy complexity that is generally no longer needed. As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. Until we encountered this issues, it looked like SES could bring ocap security to ES5.1 without doing an accurate lex or parse. With this restriction, we could regain this economy.
>Besides, no one wants to upgrade the E4X semantics to be compatible with ES5 or ES.next, so this seems a good time to impose this opt-in restriction.
>Brendan Eich was quoted as saying something along the lines of "E4X is crazyland". Parsing it is hard as hell to do right. Think of all the tooling that's out there for JavaScript right now that will either a.) not support JSX code or b.) bloat up beyond belief as it takes into account the suddenly absurd requirements necessary to deal with a similar-but-not-quite-XML-or-even-HTML-for-that-matter syntax. Oh, you want to lint that JavaScript? Bless your heart! You want to add syntax highlighting? Love will find a way. You want to use other static analysis tools, sweet.js macros, or anything else non-trivial? How cute!
>So essentially, it's a great way for Facebook to push React.js without making React.js a standard.
>It was deprecated and removed from the only browser that ever supported it because it was a poorly implemented language feature that was causing all sorts of problems.
>As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. — Mark S. Miller
>The only way for it to come back would be via a new edition of ECMA-357, which Adobe and Mozilla were going to work on. Until then, it's out. — Brendan Eich
>The idea behind it wasn't bad, but the way it was integrated into the language was. SpiderMonkey was the only JS engine that ever implemented it, and there were endless problems caused by that and severe complications of the engine's implementation required for this support. — Till Schneidereit
This JSX syntax is a perfect example of one of its subtleties: map() creates an array, and an array of elements is automatically expanded to single elements. I know that when I learnt JSX, this was not intuitive.
The word 'each' conveys the intent of this code way more explicitly.
And this subtlety is based on a difference in React.createElement() interface. If you pass an array among its children, it automatically requires all of its items to be keyed, and if you pass it as …array, i.e. variadic arguments, it doesn’t. But I believe you either can’t do {…array.map()} in jsx or its creators decided that it is not tasty enough.
Repeating a blog post over and over doesn't make it true.
The author is wrong. Most of his statements are about React, not JSX.
It's syntactical sugar for nested function calls, that's all. Brackets are turned into function statements, attributes are turned into object props.
The author conflates React properties with JSX, which is wrong. The author also confused JSX limitations, you cannot do statements because it's a single expression.
Please go read the JSX spec instead of some random blog post.
Thank you for that definitive link. Note that first boldfaced sentence in that JSX specification is as follows: "It's NOT a proposal to incorporate JSX into the ECMAScript spec itself."
That should have been the end of this discussion and fight that you picked about your incorrect statement that "JSX is JavaScript". You just unwittingly undermined and terminated your own argument by linking to the JSX spec itself, which clearly and explicitly says you are wrong, in BIG BOLD WORDS.
As JimDabel said, "They wanted to be 100% clear about it." So stop repeating something that the JSX designers so insistent is not true that they put it in bold at the top of their design specification.
You already won this argument, for the "JSX is NOT JavaScript" side. It's over.
You're arguing the wrong thing. You're arguing a semantics debate about whether an extension is JS. I'm arguing that it allows you to use JS features instead of a custom template system.
In the semantics debate you want to have I think it is JS because it all becomes JS bytecode and it's just nested function calls in the end, but that's subjective. If you want to be pedantic it's a JS extension, but in the future it could be JS if the spec is merged into engines not the compilers.
JS is an umbrella term, you're arguing it's not Ecmascript, okay, I never said that. I said it's JS, and you want to have a tussle about it instead of comparing templating systems.
> JSX is an XML-like syntax extension to ECMAScript without any defined semantics. It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.
Further down:
> Why not just use that instead of inventing a syntax that's not part of ECMAScript?
We're splitting hairs now. It's an extension of the JS spec. Once a parser adds this grammar it is JS.
It's syntactical sugar, unlike template syntax #if, ng-if, etc.
Your argument is it's not part of the current Ecmascript spec, I never said it was, but if a parser or engine adds these two new PrimaryExpressions and attributes, it is JS.
The entire point is JSX extends JS to allow templating via nested JS functions w/ pretty brackets instead of creating an entire templating system.
Under your reasoning nothing that isn't in the current accepted Ecmascript spec implemented by browsers is JS. Does that mean decorators aren't JS? Were async functions not JS before they were in browsers?
We’re not splitting hairs. It is, quite literally, not JavaScript in a fundamental way.
If you want to go around telling people it’s a non-standard extension to JavaScript or if you want to go around telling people it’s a superset of JavaScript, then by all means do that. But it is simply not JavaScript. Why do you insist on saying otherwise? All that does is start completely pointless arguments. What do you gain from insisting it is JavaScript when it isn’t?
The point is this small extension to JS grammar lets you do templating with normal JS, instead of #for you can use .forEach, .map and other array methods.
You can use JS instead of replacing tokens in a template.
It's not a superset of JS, that's not accurate, it's an extension of the spec.
I hope the JSX spec is added to the standard sometime to stop this stupid debate.
Until you realize what JSX is you don't realize the full potential it has over templates.
> The point is this small extension to JS grammar lets you…
If that’s the point, why are you telling people it’s JavaScript? You can make that point just fine without starting arguments.
Saying “This is an extension to JavaScript” is fine. Saying “This is JavaScript” starts arguments. What is your goal here?
> I hope the JSX spec is added to the standard sometime to stop this stupid debate.
But you are starting this stupid debate by telling people it’s JavaScript when it isn’t. If you are tired of people pointing this out when you call it JavaScript, why do you do it? There seems to be absolutely nothing to gain from that except “a stupid debate”.
> Until you realize what JSX is
I know what JSX is. I’ve written plenty of JSX.
> you don't realize the full potential it has over templates.
We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.
> If that’s the point, why are you telling people it’s JavaScript? You can make that point just fine without starting arguments.
First, I say it's JS because it is. Just as decorators are JS. By being an extension of JS it is JS. The two are mutually inclusive.
Second, I didn't want to start an argument, I wanted to call out the very wrong blog post, how it referenced React not JSX, how the spec is an extension of JS, explain the limitations, etc. Until now it was more of a debate. Now it's a bit more of a semantics debate unfortunately.
> But you are starting this stupid debate by telling people it’s JavaScript when it isn’t. If you are tired of people pointing this out when you call it JavaScript, why do you do it? There seems to be absolutely nothing to gain from that except “a stupid debate”.
Actually if you go up the comment chain you'll see I didn't start this debate. If you're tired, just don't participate.
> We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.
Oh but we are, again if you go up the comment chain, it's being compared to Svelte's template system, that's how it got brought up, and that's usually why this topic gets brought up. You don't have to create a whole template system. You just use nested functions. To use pretty brackets it needs a small extension of the spec. You don't have to come up with a loop system, a conditional system, etc.
> By being an extension of JS it is JS. The two are mutually inclusive.
This is absurd. If JSX were JavaScript, JavaScript wouldn’t need to be extended to include JSX. The whole point of it being an extension is that JavaScript doesn’t include it, therefore JSX extends it. If JSX were JavaScript, then JavaScript wouldn’t need to be extended. The two are mutually exclusive.
> > We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.
> Oh but we are, again if you go up the comment chain
In the context of “Is JSX JavaScript?”, the value of JSX is irrelevant. Whether JSX is useless, useful, or amazing makes zero difference to the question of whether JSX is JavaScript or not.
You can still go around telling people JSX is great. It doesn’t have to be JavaScript for you to do that. People telling you that it isn’t JavaScript aren’t telling you that it’s worthless. They are just telling you that it isn’t JavaScript.
The point of all of this is it's a JS feature, not a system written on top of JS. A few syntax changes unlocks the rest of JS instead of having to reinvent the wheel, making your own loop and conditional systems. I don't see why the semantics of it not being included yet doesn't make it JS.
When the feature isn't in all browsers and only Babel doesn't make it not JS, similar to how async functions were JS before being natively in JS engines.
You're not being genuine when you say decorators aren't JS. No one looks at Angular 2 and says "whoa that's using some foreign language mixed with JS", they say it's using a JS experimental feature.
I'll concede that it's not "JS" it's an "experimental JS feature", I'll use that in the future to avoid this pedantic debate.
> I don't see why the semantics of it not being included yet doesn't make it JS.
You don’t see why something not being included in JavaScript doesn’t make it JavaScript? Really?
> I'll concede that it's not "JS" it's an "experimental JS feature"
JSX is not an experimental JS feature. You’re trying to draw an equivalence between decorators and JSX, but they aren’t equivalent at all.
Decorators were submitted for inclusion into JavaScript. They have undergone a lot of review to determine whether they belong in JavaScript, and people agreed they did. The specification has been refined to make them suitable for inclusion into JavaScript. Everybody plans on decorators becoming part of JavaScript. Browsers will implement decorators.
JSX, on the other hand, is explicitly not proposed for inclusion into JavaScript. The second and third sentences of the JSX specification read:
> It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself.
The second sentence is even bolded in the specification. They wanted to be 100% clear about it.
The standards committee isn’t reviewing JSX for suitability for inclusion into JavaScript. Nobody is planning on JSX becoming part of JavaScript. No browsers are planning on implementing JSX.
These are two entirely different situations. Decorators being on the cusp of becoming JavaScript does not mean that JSX is JavaScript.
So far he's ignored instead of addressing all the valid points you've made, and now he's trying to derail the conversation by bringing up experimental features, which, as you say, have nothing to do with anything else.
Since he's working from his own definition of the word "is", and his own definition of the JavaScript standard, there's no way he's going to admit what he said is wrong, even though it is, and the JSX designers were 100% clear in their documentation about shooting down his mistaken idea that JSX is JavaScript.
Now that you've made that point, he's probably just going to try to derail and change the subject again, like he was just trying to do by diverting the discussion to decorators.
Please see the reply I posted to @JimDabell, I didn't answer you due to your rudeness, but my reply applies to your points as well, your wall of text was the same as his two sentences.
edit: I'll expand for you...
I'm sorry you wanted to get sucked into "is an experimental feature JS feature JS or not". That was not my intent. The entire intent was you can use JS by using the JSX extension. Instead of #for you use JS iterator functions. You can use non experimental JS features in JSX instead of conditionals or loop systems you roll yourself. Your only argument is "oh it's not included yet" okay, no shit.
Anytime someone says JSX is JS they don't mean it's currently in the standard spec, no one is arguing that, they're arguing you can use JS language features instead of a custom template system.
Anytime someone says JSX is JS, what they said means what those words mean, and what those words mean is wrong. JSX is not JS.
If you want to say something that is different than "JSX is JS" then use different words than "JSX is JS". Nobody is misunderstanding you. You're simply wrong, and insisting on saying something that's not true.
It's possible in the English Language to put together a different sentence using different words that is not incorrect, so do that, instead of saying "JSX is JS", if you want the words you say to not be wrong.
But you don't get to unilaterally redefine the meaning of the word "is", or the JavaScript language definition, and then act rude and angry and frustrated when people disagree with you and get tired of your infinite looping and mindless repetition of things that simply aren't true.
So try this: next time you feel the urge to repeat the false statement "JSX is JS", and find yourself looping infinitely picking arguments with knowledgeable people who disagree with you, instead say something completely different, that actually means what you're trying to say and is true, like "You can use JS language features instead of a custom template system", which means something totally different than "JSX is JS".
Then you won't be saying something that is wrong, and you won't feel so sad that people are misunderstanding you, and you won't get sucked into an infinite loop and keep going around in circles, because you're not simply saying what you mean, and instead inexplicably saying something that's not true instead.
> The point is this small extension to JS grammar lets you do templating with normal JS, instead of #for you can use .forEach, .map and other array methods.
But then React is much more than just "small extension".
Hooks alone are less of a Javascript than any Svelte template syntax.
Those are all features of React or the React JSX transform, not JSX. Other JSX transforms or frameworks using them may or may not share any or all of them. (JSX is not only used in React.)
Ah. So we're comparing a specific templating language (Svelte) with an idealized and nonexistent version of JSX (JSX is a non-standard extension that has different flavors depending on what underlying framework, and versions of a framework, you use).
and if you really want to use statements, you can, using an IIFE for example. It’s not pretty but you can because… ehm… it‘s just javascript.
At this point the "is JSX just javascript" discussion has gone on a little to long imho. It feels like "is html a programming language". We all have strong convictions about the answer but it doesn‘t matter, really.
It‘s interesting that fans all of 3 frameworks constantly claim that it’s "just“ or "closer to vanilla" html or js. Should we really care anymore?
The issue is not only the syntax, but the semantics. What happens to the scope when you nest #each expressions? Does it work with iterables (like for..of), or it behaves like for..in? I don't use Svelte, and I don't know those differences by reading the code. To me the nice thing about JSX is that is straight forward with JS semantics:
const a = <div prop={expression()} />
is a DSL for:
const a = factory('div', {prop: expression()})
is only a DSL to create tree structures (React is another story, you can use JSX without React).
Yeah, now add state management, event handling, side effects and performance optimizations and come back with your example. You're just comparing syntax. This is very naive.
Both Svelte[0] and React[1] are the same in this regard, the key is there as an optimization and isn't required in either framework. The only difference is that React's key is on the element whereas Svelte is as part of the each expression.
I'm not sure that's a fair assumption, one of the original sells of a shadow dom was that manipulting the dom directly is extremely slow, so doing as much work away from it is faster.
Keys are also essential to retaining an element identity, which is structurally more important than performance, because 1) code may have a reference to an element and think that it relates to some data, 2) an element may have an explicit state (like focused, animating, etc).
Keys are a hugely leaking abstraction, but are inevitable when you bridge a declarative immediate mode rendering into a stateful one.
Yeah it's not strictly necessary, but if you are updating the list (adding/removing especially), Svelte can know how to reuse elements properly if they are keyed. You also need keys for animations to work properly.
> but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.
I agree. As long as you understand the basic concepts, it's only a matter of learning the syntax, which is really not as big of a deal as the person you replied to is making it out to be.
It's not a herculean task... I agree, until you've learned 10+ (angular, vue, svelte, wordpress/php, jade templates, laravel, underscore/lodash, handlebars/mustache, hugo, etc..) of these "super simple templating languages"! And keep them all straight. I have no problem learning a new language if there is a compelling reason. But If it's just additional shit I have to remember for no clear reason... No thanks...
We can have a debate on unidirectional data flow vs 2-way binding, how each framework manages state changes, how opinionated each framework is... How mature and vibrant each developer community is... etc. These are all another discussion though. My question is why must we reinvent the wheel again and again.
You need to stop insisting that a wheel has been reinvented with Svelte. It shares 95% of the same DNA as other frameworks, with multiple improvements over them. So with that in mind, what you're actually suggesting is that the existing offerings were somehow perfect, and we don't ever need to improve on anything again. That is an absurd notion, especially given that the other frameworks have gone through MASSIVE changes since launch -- sometimes even complete rewrites, because they acknowledged they got it wrong the first time.
100% - Common guys we are programmers in a field that is know for changing consistently (probably a lot faster than other careers). If you see learning new "syntax" for the basics (loops,conditionals etc) then you going to have problems down the road. Weather you use svelte, or some other new tech. If you really never want to learn another syntax.. learn LISP and be done with it.
You are a programmer, you will need to learn new syntax a few times in your career.
If some of the "biggest" complaints are "oh no I have to learn how to write for-loops again" - I guess svelte is doing the important stuff right.
Wayyyy back in the day(ok not that long ago - 80/90's) when I was learning a new lang (Pascal,C, C++) I used to tell myself If I can get an working example of:
1) "user-input (readline,scanf etc)"
2) "printing input/output"
3) "calling functions/procedures"
4) "Do the loops + conditionals"
5) "file I/O"
6) "Memory schematics"
You basically mastered the "building blocks/mrk(min-req-knowledge)" of the new lang and like maths you only need now practice or a good project.
TL;DR
If you are a professional-career-programmer, learning "new syntax (we used to call them keywords)" is a requirement.
Oh but it‘s not just about the syntax, it‘s also about the semantics, scope rules etc. This is the reason I still like JSX best, because I have a fairly deep understanding of that stuff in javascript while vue templates still leave me scratching my head sometimes. But I can see the appeal either way.
useMemo and useCallback do feel a little boilerplate-y. Something is slow, I wrap it in the thing, I let eslint fill the dependencies and there‘s no big downside to doing it all the time anyway. Feels like something I maybe don‘t need to be typing?
useState is also something svelte eliminates, though I personally prefer to keep that explicit.
As a backend guy who moved away from frontend long ago for these very reasons, I have to ask: why are people downvoting this? Is it wrong? I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.
It might be true, but it's a rant that just barely touches the actual topic, which is mostly: a company will pay somebody to work full time on an open source project that is still independent. And I think it's pretty nice. And also I think Rich Harris has given a lot to people for free and I'm happy for him that he will be paid to work on something that he loves.
So all in all it would be nice if we would for once be spared of rants how tiring, immature, half baked whatever whatever the JavaScript world is. Show us maybe how it should be really done, but maybe in a separate post please.
I didn't downvote, but I'll speak to my experience.
First off, you don't have to go learning every framework out there. Pick one and stick with it, or just go vanilla. That said, The features these frameworks provide gives a boost in productivity that far outweighs the low learning curve.
My pick was VueJS and I'm very happy with it. Using Single File Components is pretty similar to vanilla HTML/JS/CSS. Beginners that were under my guidance (with only HTML/CSS/JS experience) usually pick it up and were productive in the same day.
I disagree that React (JSX) is most similar to vanilla JS/HTML at all (I don't prefer it, but to each their own). Vue and Svelte are much further on the side of a vanilla-ish approach.
Is it false though? If it’s true, then maybe we need to look at why it’s true.
It’s not just front end developers though. I think other domains and their frameworks went through the same thing. This is just the time for front end.
Yes, it is false. Anyone in the space can tell you how stable things have been for years now.
Plus, there are a lot of people writing JS. It’s not a tiny community fracturing itself over different ways of doing things, and becoming destined for obscurity. It’s tens or hundreds of thousands of developers. In a community this big I’d say having a few choices is a sign of health.
Indeed, it’s false. React is 8 years old, and when React was first released jQuery was only 7 years old. I follow this stuff pretty closely and I can only think of maybe 10 JS UI frameworks that have attracted remotely significant use and active development at any point in the past 15 years.
I’m just picking a few frameworks and languages I’ve used in the past and are still used. Obviously there are still new frameworks and libraries that come out for these languages. But sometimes the big projects fold those in. Or they write their own or whatever. I can pick the popular names and do pretty much what I need.
JavaScript is 25. But most of that time we weren’t doing what we can now. And most frameworks are fairly young. Angular is 11. But most people (and jobs) have jumped ship to React(8) and now there is Svelte(4) which also looks good. And I think there will be more changes to come.
These JS frameworks aren’t exactly veterans that are impossible to supplant. Not yet anyway.
Why is no complaining that there more than one way to build a php app? Perhaps because like JS it's a huge ecosystem with a giant user base and millions of use cases. Front end dev has lots of room to support the dozen or so mainstream frameworks we've used over the past decade-plus
Agree, and it’s nice to see this worn-out trope getting downvoted for once. Sneering at JS / Frontend developers is one of the more distasteful tendencies of HN.
Probably because it's an entire industry that is self-sustaining, without really a reason for it to exist. Most software can be built with regular HTML / JS / CSS without some convoluted framework. Even better, let's make a desktop application (when was the last time we had those?!), and we can get all kinds of performance and security gains without having to tack everything on to the web as a platform.
> Frontend developers like to change frameworks every week it seems like
Most of the popular frontend frameworks (Vue, React, Angular, Svelte) have been around for years at this point. It is like arguing Ruby on Rails vs Spring Boot.
Anyone that's worked in a reasonably sized FE codebase can very clearly understand that changing your framework is essentially migrating a huge production DB but on steroids.
Where exactly have you seen a team of developers change their front end framework every week?
It is wrong because it has slowed down to a crawl compared to what we had from 2010-2014.
Most companies have settled on either React or Vue, which are extremely similar. Angular is used in some niches, almost always because teams already knew it.
Those three are responsible for almost 99% of the frontend positions you'll see.
Svelte is getting popular but so far it's still niche. It's more of an inspiration for others, but also a contender. And really, what's so wrong about having more options and more competition? Even if you want to stop learning new things, there'll be no shortage of job vacancies for the three frameworks above.
Also, since you're a backend dev, there are much more backend languages in use today than frontend frameworks, to give an example. And it's not hard to find companies using more than one.
Naw, the Python/Zope/ZODB/CMF/Plone/TAL/MeTAL/TALES stack can out-boilerplate the yin-yang out of Zend.
Each of those Dagwood Sandwich layers has its own special purpose object system that leaks abstracts to all of the other layers, and its own domain specific languages for writing boilerplate that sprays those abstraction leaks all over the place. ;)
Well in this case, it's more that svelte is the least of all evils when it comes to this. React and Vue have way more boilerplate and React in particular has the most framework-specific stuff of them all. Svelte is much closer to pure html/css, or so I'm told.
all of the js frameworks mentioned are view layer libraries. i.e. they create html. Hence they need a DSL for writing templated html, which will be used for generating final html
Hence, it is completely natural for them to offer a custom DSL as html does not have standard way of expressing those concepts.
Since each js framework has its own idiosyncrasies and motivations, custom DSLs reflect it.
If you were to go around and make a new js framework, you too are going to create a new DSL
I've used react for some years now and it's very very hard to do animation and event-driven operations with pure react render. You'll need extensive lifecycle events or hooks and refs to get animation or handle focus, etc well. It's due to how react render the components.
It doesn't make react bad but I guess some newer frameworks (vue, svelte, I haven't learned those yet) try to tackle this from different approach.
> I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.
Perhaps not in the "frontend community", no it hasn't slowed down. There will always be new frameworks coming and going, and people will work on them as fun open source projects or use them in their side projects or whatever. But people doing real work are almost unanimously settled upon React as an industry standard at this point. There's still a decent sized faction of contrarian Vue holdouts, but by and large the JS framework wars are over.
I never asked anyone not to use svelte... I said why should I be compelled to learn this new language, other than it being the hot new UI framework of the day.
It doesn't have a virtual DOM? It doesn't have synthetic events? Ok why not just use web components which provide their own encapsulation and vanilla JS. I don't have to learn a new language which may or may not be around/supported a few years from now... Also I'm continuing to grok web standards.
No, it's not wrong, it's absolutely correct. There's a lot of flexing around who can come up with the most elegant abstraction which ignores the important point: making sure what's necessary to understand the framework, use it long-term, and move away from it after is focusing on the core technologies of the web (HTML, CSS, and JavaScript).
The abstractions are cool, but completely unnecessary (see link to my framework above where I circumvent that problem entirely).
I assume because there's no value to it. What's the opposite side of the argument? You have an area with a lot of growth and many problems with the way we're solving these problems and something like svelte is not"completely reinventing the wheel" as the OP positions it, by nature it's try to solve specific problems using our existing tooling whenever possible. The original post is a shallow, feel-good rant
I don’t know about “wrong,” but my opinion on the overall theme of that first comment is that the requirement to learn is not at all a bad thing. I enjoy learning new things even when that is in some sense a “requirement.”
IMHO, syntax is the easiest part. Semantics are the tricky part. One very clear example of this is how Svelte and React deal with async stuff.
The Svelte approach follows the handlebar approach of having semantics be represented by DSL constructs - which is a very reasonable approach IMHO.
The Suspense semantics are so far off left field that someone literally wrote a whole framework specifically in response to its complexity[0].
And that complexity permeates every language construct used within a React component. Why can't we call hooks from inside if statements? Aren't if statements just JS? If you have to bring up React's internal implementation to explain, that's no longer "just Javascript", it's also a healthy chunk of very React-specific knowledge that you need to be aware of.
Vue is another example that provides a successful story of a very large algorithmic migration from a reactive system to virtual dom with virtually no disruption to consumers, thanks to the abstraction provided by its DSL. In contrast, try telling my wife (who's learning about class components in her React course) that functional components and hooks "are just JS, what's the big deal", and see how far that takes you :)
I completely agree with you, and I've yet to see a compelling argument against this. I've been doing this since the rise of the SPA, all the way from vanilla, jQuery, Backbone, Angular 1.0, Ember and React and after reading your comment all I can think of is "great, we're going back to handlebars templating again".
There is no net-gain in re-inventing the wheel. It just becomes yet another thing to master to stay relevant. In a decade of doing JS front-end applications things have only gotten more complex and more time-consuming.
Thankfully I've found a sweet spot where complexity, velocity and quality are in balance using technologies considered no longer cool and that's fine with me. I get to focus on the actual problem at hand instead of trying to figure out the inner workings of this new shiny thing.
The youngest framework of your list is 8 years old already. Svelte itself is gonna be 5 years old in a couple weeks, and there's absolutely no need to pick it up right now.
The meme that there are new frontends daily is extremely tired and has been totally false for several years now.
Also the only thing those baseless complaints achieve are flamewars and shitting in other people's work.
For me Vue 3 with <script setup> get's pretty close to pure JavaScript/TypeScript. 90% of the code will be exactly like JS code, the only difference being the use of computed(), ref() and reactive() to achieve (something JS simply doesn't provide but is necessary for every non-trivial application). Your HTML code and CSS code are not mixed with JS and look and feel like the real thing as well.
Other than the reactivity indication and the occasional onMounted(), etc. Vue 3 with <script setup> does away with all boilerplate and unidiomatic parts of Vue 2 and imo is the framework that most closely resembles pure HTML/CSS/JS while allowing for far greater productivity.
Are we still taking about vue <template>? I don‘t see how that is any way close to html when it has: custom conditional and loop syntax and semantics, arbitrary js expressions and a unique concept of scope?
Yeah I never really understood this benefit. The file structure is irrelevant to me after 15 minutes, the nitty-gritty semantics of my code are causing me headaches and bugs forever.
(I like working with all 3 current frontend frameworks btw, not trying to start a flamewar)
I don’t love that aspect myself, but I have to point out that in Svelte’s case it is definitely not “without a very compelling reason”. The special build-time processing is the entire point of Svelte.
Though personally I’d almost prefer it was a whole new language than a “kind of JS but with some (necessarily) new syntax”
Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.
SolidJS[https://www.solidjs.com/] does exactly that. That ability is more about fine grained reactivity than it is about templates. The use of templates and single file components is a stylistic choice by the Svelte team. You could argue Solid has poor ergonomic compared to Svelte I guess.
The "more constructs to work through" is precisely the problem. Without restricting JavaScript to some subset, you're not going to be able to statically determine the behavior of any given program.
React is a free for all, you can render pretty much anything you want at any time. With templating languages, the DOM output can be statically analyzed at build time, so the amount of work needed to diff the HTML output when things change at runtime can be dramatically shortened.
I used to be full stack before the re-invention of wheel phenomenon got way out of hand in the js world. Keeping up with what’s going on with the ecosystem and employing the best practices became a huge chore that took time away from solving actual business problems.
Turning away from front end let me concentrate time on learning devops, cloud, ml and other things that aren’t as volatile in terms of design patterns and that lets me design more high level solutions to problems and create more overall value.
Maybe people just differ in how wide or deep information they could handle but I certainly can’t keep up with such a wide array of patterns and tools that do the same thing.
The problem with each of these frameworks is that they make the mistake of surfacing the underlying standards like HTML and the DOM. This is why they look remarkably similar and can only possibly be incrementally better, at best.
HTML and the DOM are still essentially modeled on static documents. Building apps that deal directly with these standards is an impedance mismatch that, remarkably, people keep trying to solve by adhering to those same standards, but in a slightly different way.
Why should we know or care about HTML or the DOM?
A robust, event-driven, component-based framework that manages the low level Web standards could offer true advancement.
Yes, these are moving in the right direction, but have a ways to go and are heavy for what they do. Visual Basic of old may actually be a better example.
Even reactive models are built around matching data to the DOM, essentially. And there's still too much wiring that's required.
I think where we'll see the innovation here is in the no-code and low-code platforms, which will move away from the model of code frameworks to better componentize and abstract away the low-level details. They'll surface high-level interactions via an elegant event model, and automatically handle reactivity through easy to specify component-to-database bindings.
The concept of a lower-level code framework will be replaced by that of a simplified abstract "environment" in which devs work.
I like the database-to-component binding idea. If you squint, that‘s what a GraphQL/React app simulates (with mountains of boilerplate).
I‘m not so sure about moving up the level of abstraction in the direction of no code tools. You can make it super easy to build the 1000s of CRUD apps we need today, but a dominant UI toolkit needs to be low-level enough so we can also build the kinds of apps we don‘t know about yet and the no code tools to make those apps. I think the component model popularized by react is here to stay for a while, especially because it fits in perfectly with the low/no-code tools, but everything around I can see improving.
Yes, but while great for telling a browser how to render that tree, it's not an efficient way of mentally representing a frequently-updating app-driven UI.
What devs are really rendering is a tree of components, laid out on a canvas. There's no reason they should have to think in terms of how those components are managed or represented in lower-level HTML, any more than in binary.
I just don't get people complaining of trivial or superficial stuff such as how to do ifs, loops or binding handlers. When the most important part of these tools are the architecture, the trade offs, the state managements, the tools, the libraries and the ecosystem.
Complaining just because of the syntax is just trying to convince yourself you don't like it.
It's like when people just discard tailwind because they don't like how ugly many classes together look on the html, ignoring everything behind it which is what really matters (and that you can still like or dislike).
But I think, I'd rather learn an entirely new technology or language instead of every year having to learn a JS Frankenstein language!
I kind of regret posting my OP now... as its turned into a bit of a flame war. It was not my intent.
And I applaud people try and build anything new. I'm just ranting a bit about how it feels like UI development has a new framework/language/ecosystem every year or that is touted as the next big thing to supersede the rest! But then ends up reinventing much of the same constructs only with subtly different syntaxes.
This is very overdramatic and isn't actually based on reality. Svelte is far closer to vanilla JS/HTML than any other framework, while also using extremely similar patterns from the other modern frameworks. Yeah, it has some sugar, but it's not just some templating system any more than React is just some templating system, and the only "unique syntax" you could be referring to is the auto-subscription to stores using $, which is super convenient.
You're acting incredibly disinformative, and have no legitimate basis for your assertions.
No special languages or syntax. Plain HTML, CSS, and JavaScript with the same reactive UI stuff in all the other frameworks. It's also part of a full-stack framework so you can whip up lightweight, fast apps.
The best part is your skills are transferrable as I'm not introducing any domain-specific abstractions. You can go from learning HTML, CSS, and JS to this without any "gotcha" in the process.
Any new language/framework trying to sell me on it's improved ergonomics should not bother showing me syntax and instead show me a stack trace. Vue is really concise and expressive but seeing a pile of node internals on every typo is infuriating.
Agreed, I thought we were past this with the 4th generation of these frameworks, this is like knockoutjs all over again.
The moment the penny dropped for me was when I read something like this about React:
"We realised that inventing our own Yet Another Binding Language that was less expressive than javascript was harder and worse than doing the work to put the relatively simple HTML constructs into Javascript"
Yeah, It‘s my favorite templating abstraction because I could convert it by hand and so I don‘t really need to mentally model it as an additional layer.
I've been pretty skeptical about SPAs but having tried out Svelte for a few side projects, I have to admin I was probably directing my skepticism to the wrong thing, probably React was the cause of my dislike for SPAs. Svelte looks really awesome and the simplicity it brings back is invaluable. I really wish it takes off, for real. Looks very promising.
FWIW I would give Inertia a look. I’ve been using it as the glue between an SPA and my backend, and for me it’s been a best of both worlds experience. Nearly stateless front-end, atomic deploys, easy to understand, no client side routing. Yet you still get the very snappy SPA experience and the nice DX from componentization of your UI. I highly recommend it.
The complexity and the over engineering going on, mostly.
Things such as redux, rxjs, observables, thunks, etc really put me off when you compare that to just MVC with Rails for example, plus most applications I worked with React were just forms anyway, with some fancy controls/widgets on top.
Not having a clear way, even today with Next, to load data (client side, without doing SSR) before a route transition happens (which leads to spinners everywhere), and now the solution seems to be all the server components, concurrent mode, suspense, etc, etc which to me is just mind blowing how complex things became.
Also hooks which conceptually they make a lot of sense and I like them, but then you have to do all the dependencies tracking manually, they have a lot of gotchas (async in useEffect, ordering, etc).
The "rerendering of everything" and the need for manual memo, useMemo, useCallback, etc and the whole "don't optimize it until you need it" (guess what, a my company as in many others it never was a product priority to make it fast).
Now, take the good parts of the approach, remove all these complications, and you have a very nice and clean approach to do web apps. To me that is what Svelte brings back.
I don't agree that everything has to revolve around MVC. It's not a hammer for every problem. This is why other patterns like MVVM, MVP and other abbreviations were introduced to solve broader needs.
React starting as purely a UI library paved the way for people to find new ways to manage state and data for different kinds of applications and needs. That's how we ended up with what we have today. You can say what you wan't, but I think it's remarkable what people came up with in the past 10 years.
And these solutions are just optional things you can choose in case you have a need for them. React comes with a lot of things for building rich UI. Sure some things may require more code, but so is the nature of writing applications with specific requirements.
Server components, Concurrent Mode and Suspense came out of the frustrations that it was hard to provide great user experience and avoid common pitfalls with async I/O and high performance because they were limited by React. The solutions they came up with, while not perfect (or even ready yet) aims to solve these issues, while avoiding breaking backwards compatibility and that could be further improved upon while also avoiding breaking the API.
With regards to hooks, I agree that it can be annoying to have to manually pass dependencies. But this is unfortunately the nature of JavaScript and React's mission to not break things. The alternative would require massively changing the API. We've seen other attempts at remedying this with projects like CrankJS and SolidJS that takes a clean slate, preserving the concept of React, but taking a more modern approach on these concepts, as they have freedom of designing their own API from scratch.
We seem to agree. I'm not saying React's approach isn't justifiable. It is what it is for reasons.
I just don't agree all that complexity is worth when you need to ship things fast with a decent robustness and performance. Specially when you don't have 100s of devs in the project.
I'm just saying that given React vs Rails, for 80% of projects I'd pick Rails+hotwire+etc... But given Svelte vs Rails, I'm more inclined to pick Svelte now, because it is not so complex, for now at least.
Yes. I totally agree with this. That's why I chose Vue as well. As I've gotten into it more I've found chunks that certainly feel over engineered here and there too.
Awesome news! Having worked with frontend frameworks for years, I've grown pessimistic about them in general, but I'm enthusiastic about Svelte because it does so many things right that actually avoid a lot of the issues other frameworks claim to solve but actually make worse.
Interacting with the Svelte compiler is ridiculously easy. Though the documentation can be improved, I found it trivial to import the Svelte compiler and prerender a component into an HTML string. Yes, this is somewhat of a niche thing to do, but I appreciate it when libraries and frameworks make it easy to access its internals. Heck, I pretty easily managed to implement Typescript support for Svelte components using Deno's `emit` function; hooking into Svelte's preprocessing was trivial, the complexity I ran into being on the Deno side.
Contrast that with Ember, which seems to have an attitude of "no one would or should ever want to do that", making it really hard to do anything slightly off the beaten path without lots of trial and error or entering the Ember inner-circle.
Yes, I know I'm comparing a component library to a framework, but what I'm commenting on is more about development philosophy.
It's good to hear the creator of Svelte will be able to dedicate his time to it and be able to provide project guidance. I think he has the right vision for what Svelte should be.
Ember was the first framework I used and also the most frustrating. At least with Vue and React I can poke at the internals and they make sense, but Ember's internals had so many oddities that thoroughly confused me.
What I like about Ember is that it gives a lot of rigid structure that, at least at one point, made it comparatively easy to work on multiple Ember based projects and be productive sooner.
As you've pointed out, a problem with that project is that there's a ton of intimate knowledge for how things work under the hood or why things are the way they are. They also seem to oscillate between opting for simplicity and opting for complexity and magic.
One example would be the latest version of Ember which doesn't even ship with `@ember/render-modifiers` by default despite how everyone will end up installing it out of necessity anyway.
Why might that be, you may ask?
> [...] we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern.
Why on earth did they reinvent components and ship them without providing the supposedly correct way of interacting with their lifecycle? You actually have to install a separate add-on to develop a production-ready app with Ember, which completely flies in the face of the idea that you can run `ember new` and have pretty much everything you need. Go ahead and try interacting with individual elements of a Glimmer component in a vanilla Ember project and see how productive and ambitious your web app will be.
Strangely (and thankfully), the RFC for what I think is a needlessly complicated alternative for lifecycle interaction is effectively stalled:
By their own verbiage, the only official way to interact with component/element lifecycle is an antipattern.
So far Svelte and SvelteKit are avoiding all that extra crap. The day that Svelte calls its own solutions "antipatterns" and spends years pontificating things like the actor pattern will be a sad one.
And I shouldn't have made it about that. As I get older I the more I just get tired of extra things. There's always a price when you add more things. Svelte technically does add things, but I think it has better bang for its buck. The fact it doesn't pointlessly impose OOP constructs upon the end-developer is a big win for me.
Why is this 'awesome news' for us devs, the market and competition if one vendor now controls all modern SSR frameworks plus significant parts of the tool chain (swc)?
Does Vercel actually “control” Svelte, though? The existing governance structure is untouched, they’re just paying the salary of the lead (and definitely not only) developer.
Not sure if this topic is worth our time to debate. There are millions of ways of subtly controlling/influencing entities. And it's much easier if you pay money, ESOP and pay even more money if future goals and exits come alive.
The Zope Corporation hired Guido van Rossum to work on Zope for three years (a Python web application server and content management system), then he moved on. That didn't destroy Guido, or Zope, or Python.
>He has worked for various research institutes, including the Centrum Wiskunde & Informatica (CWI) in the Netherlands, the U.S. National Institute of Standards and Technology (NIST), and the Corporation for National Research Initiatives (CNRI). From 2000 until 2003 he worked for Zope Corporation. In 2003 Van Rossum left Zope for Elemental Security. While there he worked on a custom programming language for the organization. From 2005 to December 2012, he worked at Google, where he spent half of his time developing the Python language. In January 2013, he started working for Dropbox. In October 2019, Van Rossum officially retired before coming out of retirement the following year to join Microsoft.
Guido and Rich are both uncontrollable forces of nature!
Even if Vercel came out and said “we’ve bought Rich Harris’s voice, every choice will be controlled by us” (which they haven’t!) they still wouldn’t control the project because Rich isn’t a BDFL.
If we have such trustworthy markets and competition, then how the hell did we end up with React and Angular, huh?
Ayn Rand sucks at software design, as much as she sucks at philosophy and economics and social design and writing. Your trust in her is certainly misplaced.
Anyway, why do you have such a huge problem with Rich acting in his own best self interest, that you found a need to personally attack him so viciously and often as you did in this discussion for all that he's done for himself and the Svelte community?
Don't you believe the invisible hand of the market, which you trust so much, will prosecute your vengeance on Rich, who you find so untrustworthy?
Calling someone weak is a personal attack. You are not Rich. Don’t speak for him or his attributes. Keep the discussion constructive, you’ve already been asked in this post to calm down the personal attacks even after Rich gave you a kind reply
I'm definitely curious about it. I'm one of those "swore off frontend framework" people who's attracted to tools like Phoenix Liveview so I never have to deal with it.
Svelte does look pretty sharp and simple though. I wonder how well it works with something like LiveView? Does it really depend on the styling structure mentioned or can I use it with Tailwind?
It works great with Tailwind, I’m doing that in a project right now. I haven’t tried pairing Svelte with LiveView and I’d worry they would end up fighting over elements of the page, but I’d think you could have them control separate parts of the same page, or have them controlling distinct pages just fine.
Well, this is awesome -- but fuck me: Vue is the only major player not under the Vercel umbrella now, haha.
Looks like I might have to phone in half a decade of experience.
Svelte is close enough to Vue with "script setup" mode anyways, the major difference is whether your logic/keywords go INSIDE the HTML tags or OUTSIDE.
Lee from Vercel here. The governance of Svelte isn't changing – it's still the same independent, open-source project and community. We're just supporting Rich and helping the project grow!
Absolutely, but in my mind this means Rich/Svelte have been "blessed", and I've built enough Next.js apps to know that you aren't going to find a better Dev UX/superior experience to what Vercel is providing.
Benefits of being a framework owned by a business that makes a lot of money off of it.
Next.js 12 as any indicator, I'm just going with whatever falls under the Vercel umbrella now -- I can tell you that Nuxt is not a competitor (as an unbiased voice and someone who doesn't particularly love React).
> We're just supporting Rich and helping the project grow!
I'll admit that I have a negative bias towards this... in spite of Basecamp+RoR, Mozilla+Rust, or all the great OSS HashiCorp makes, it's still hard for me to believe that business do anything out of the goodness of their heart.
Is there a strategic goal for hiring Rich? is it that Svelte is used so much in house that it only made sense to support it? Is it to get more cred with developer by supporting projects they love?
Again, sorry if this question is to skeptic and cynical... I love to be wrong on this! :)
In the case of Vercel, I'd imagine that improving svelte's reach positively affects them commercially seeing as they're a major player in the relatively small market of svelte hosting.
This is the standard narrative when OSS contributors got hired but ok, I'd write the same.
But then just tell us what was the motivation of Vercel's shareholders and CEO to acquire Rich for such a high price (he is the compensation and ESOP you pay absolutely worth) but what's your gain? "Just supporting Rich and helping the project grow" or just buying him out of the market?
On a high level: if Svelte succeeds, the Web succeeds and Vercel succeeds.
More concretely: we want Rich to help shape Vercel's support for frameworks as an open platform. We want to hear how, as a framework creator, the platform can best serve him. We project this work will have ripple effects like making Astro or Remix better on Vercel, or the next framework you invent. You'll hear about this work soon.
We want to hear what edge infrastructure would make Svelte the fastest for developers and visitors. We want to also help him build a better Svelte by connecting him with customers who are betting on it in production. We want to learn from his DX expertise so that we can make better products.
We are very excited about this and we think betting on Open Source for the SDK together with an Open Platform for infrastructure is the only way to succeed in our space.
Now in all seriousness, JSX does have its benefits like being able to write a small function that returns a piece of JSX. But in my experience, using Svelte is a huge productivity booster than I don't mind losing JSX's benefits.
>Let's retire the 'virtual DOM is fast' myth once and for all
>Rich Harris, THU DEC 27 2018
>If you've used JavaScript frameworks in the last few years, you've probably heard the phrase 'the virtual DOM is fast', often said to mean that it's faster than the real DOM. It's a surprisingly resilient meme — for example people have asked how Svelte can be fast when it doesn't use a virtual DOM.
>It's time to take a closer look.
>[...great article...]
>Why do frameworks use the virtual DOM then?
>It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.
>But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.
I love Vue because I come from a bygone era of HTML + sprinkling jQuery as needed. 99% of the websites don't need a full blown JS frontend but everyone is doing it, I must be wrong.
Do you work with a designer? I’m convinced most of the push for JS apps as pages is mostly perpetuated by designers who don’t know how the DOM works and feel the need to redesign the wheel on every project. I work within a company that provides a design system and a platform of hundreds of generic component, but individual designers still always want to push their particular vision.
I think if most designers took existing web elements and tried to build a UI, instead of drawing an arbitrary picture and asked devs to implement, we would have much less JS overall.
Product designer and HTML/CSS person here, and in my experience it is the opposite. Designers and front-end focused people wh get a chance to work with Vue love it because it actually respects basic HTML/CSS/JS and doesn't encourage doing everything in JS, unlike React which basically forces your hand. This makes working in Vue (and Svelte) so much more accessible to people who are great at HTML and CSS but not JS as much (and in my experience many React devs are great at JS and terrible at HTML/CSS).
Designers more often know HTML and CSS over JS, so it is unlikely they are the ones pushing for JS solutions. It is the developers who don't know how to implement designs without falling back on JS for everything who are causing this paradigm.
That being said I blame a lot of this on design tooling as well. Figma and Sketch are custom rendering engines that just don't understand HTML and CSS and therefore give no opportunities for designers to learn how the web works. Fortunately a new generation of design tools are coming that are built on HTML/CSS renderers that feel like Figma but actually output usable code for devs to interpret into their projects.
> Fortunately a new generation of design tools are coming that are built on HTML/CSS renderers
These days I spend more time in browser devtools than Figma, and honestly I'd prefer a more visual way to edit code directly. Something like Webflow but without all the cruft behind it. Preferably built into devtools, maybe as an extension
No, we don't have a design team, we're too small for that.
Just that our backend is already built using Django many many years ago. If I need to add some interactivity, I use jQuery currently. Looked into Vue and it allows us to keep everything as is in the backend and use it like jQuery.
I shudder everytime I need to install npm, webpack, gulp, etc..all the JS tools feel super flaky, unnecessary and does not inspire confidence in the tooling. That's my take anyways.
Lot of developers don't have the priviledge of starting a new project. It's an existing doctors appointment website or some shit people cobbled up in PHP in 2004 that is still running and we need to maintain it.
> "I shudder everytime I need to install npm, webpack, gulp, etc..all the JS tools feel super flaky, unnecessary and does not inspire confidence in the tooling. That's my take anyways."
For context, I started doing web dev back in ES5 JS, jQuery, Angular.js (1), and server-side templated HTML views days.
I write in a lot of other languages as well, and I would hear people say this and not get it. I thought to myself:
"It's not THAT bad. I think the experience is fine."
Then I wrote an app recently on the JVM. Sweet jesus the JS/Node ecosystem is a nightmare + house of cards.
The JVM and CLR (.NET) have their stuff together. I need like ~10 dependency libraries to do a large project, and often times they are over a decade old.
The tooling is on another level.
I don't have PROBLEMS writing TS apps, and the experience is good. But some of them have a dependency tree that span thousands of packages, and I've come back 2-3 years later to try to run a project and had some downstream dep break, and then updating fails, and then...
I know it's somewhat of a meme, but this is unironically why I find Deno interesting. (Disclaimer: Haven't shipped anything with it)
Especially since with the most recent release, they have an option to emit Node-compatible JS bundles from Deno code.
I totally identify with your aversion to build tools, but things have changed for the better in the last few years.
My advice would be to check out Vite, and use it with Vue. I've introduced Vite/Vue2 to a pre-existing Django project and couldn't be happier. I've explored a number of different approaches for integrating Vite and Django, and this blog had the best approach, IMO: https://weautomate.org/articles/using-vite-js-with-django/
I find that Svelte is the most "jQuery-friendly" of the frameworks. I can easily add a single Svelte component back into other wise static pages without requiring anything other than a simple build tool to output the JS + css. It's really the best of both worlds – sprinkle it in where needed, or go whole-hog.
Yeah, I really like Svelte for this. I did a whole blog post this way, with little embedded animations to show various operations on linked lists. Each of the animations is a Svelte component, but the surrounding page is just a static HTML page created from Markdown (using Jekyll as the generator).
It's nice that Svelte components can be independently mounted like that.
To be fair, the same thing would be possible with React or the other frameworks. I do like that it's only 29kb of JS for all those animations though (and most of that is the SVGs, I think).
Well, I guess I'm wrong too then, as most web apps I create are SSR (with dotnet), with a sprinkling of vanilla JavaScript. Previously I used jQuery, but we're finally at the point where it's not necessary.
This is a really cool idea. This has always been my biggest beef with single file components. It never occurred to me that you could do this with Vue. Thanks for the tip
Admittedly I haven't followed Svelte super closely, but isn't "no JSX/TSX" kind of a major ideological point? From reading the intro docs, it seems like separation of js/css/html is a selling point. JSX/TSX would contradict that, no?
Just wondering if my read is correct or if there's some other reason it's been left off the table.
Nobody truly separates JS from HTML. You either have to put something HTMLish in the JS, or something JSish in the HTML (HTML itself supports this of course).
IMO the HTML-in-JS solutions (i.e. JSX) are superior to the JS-in-HTML solutions (e.g. Angular/Vue Templates) because they put the standardised turing-complete language in the driving seat rather than the propriety, hard to extend template language.
Still, it's way easier to integrate a js library in a svelte component than in a react component. So maybe the two approaches have different tradeoffs and respective advantages
I've been using Solidjs the last month for a project, and I really like it. Small bundle size, super fast, not much to learn, not too much magic, lots of control. Basically instead of having a vdom the framework is able to track finer-grained reactive sites and update those when the data changes.
If no one has managed to add JSX, I believe it would be feasible to implement. The Svelte compiler is pretty straight forward to interact with. However, I have little experience with the semi-standard build toolchain for Svelte that most people are using. You would of course need to import React.
This is such great news! I've been vaguely aware of svelte for some time now but it wasn't until a few months ago that I started using it professionally and it is such a joy to use!
I recently did an onboarding and explained why svelte instead of react of vue, and svelte code, to me, is so much more intuitive and clean!
Thanks for the awesome work Rich and best of luck in this new chapter!
I'd like to hear more. What were your conclusions? I'm particularly interested in it compared to Vue.
I picked Vue because of most people's complaints about React, so most of the comments I'm seeing are about specific gripes with React and don't really help me make an informed opinion.
For React, I agree with the complaints. The change from class components to functional components and the addition of hooks for we was a step backwards.
As for vue, most of my experience is with vue 2, never really spent a lot of time with the features of vue 3.
To the the some of the syntax of svelte makes more sense than that of vue. For example, to list something in vue an html with v-for is needed, or <template v-for... >. This always felt a little awkward to me. In svelte you iterate on the data, not on an html element. So you have an array and just put {#each item i items} ... {/each}, not need for extra html or pseudo <template>
I also prefer svelte's computed properties to vue's.
All it takes is a $: value = a + b and from there whenever a or b changes value also changes. Sometimes my computed property on vue will start growing a little too much.
Something similar in vue and svelte that I enjoy a lot is that the code is separated from the html and from the style. Some people are fans of JSX but I can't stand it! It allows me to shoot myself in the feet and I do it way too often.
The store is VERY VERY nice too! it's lighter than vuex but seems to have some of the limitations that redux/mobx have, say, it has to be functional. I haven't had to write any reducers like with redux tho, but stuff like [].push() won't update.
Overall I really really like it because it's almost transparent. I really didn't have to "learn" svelte as I had to vue or react. It was similar enough to HTML/CSS/JS that it took no time picking it up.
> I really didn't have to "learn" svelte as I had to vue or react
As someone who is primarily a back end dev with limited experience with frontend frameworks (very little react, somewhat decent amount of vue), this was the biggest surprise when working on a project with svelte. You know the saying "hit the ground running"? This was the first time I felt like that with a frontend framework.
I've used React extensively, and now I'm about into 1 year of Vue 2 with Nuxt after having switched jobs.
My gripes with Vue are:
- Despite they say it is not a "Python 2 to 3 like" situation, it is. Every library you find specifies if it is for Vue 2 or 3, some have versions for both, some are only for 2 and will never be upgraded to 3, others are just for 3.
- Vue doesn't have any spirit or ideas of its own. It just copies over every feature from every framework trying to be all to everyone, which leads to too many different ways of doing the same thing.
- There is a horrible culture of auto importing things (components, functions, ref sugar, etc) . This breaks tooling and editors, then they patch those to auto detect these tricks, then introduce a new one and everything breaks, then again..
- Many, many times I was trying to investigate a problem and you end up in a Github Issue which has part of the discussion in Chinese. Doesn't happen as much in official repos, but it happens in many of the third party libraries you end up needing anyway. Some libraries don't even have a readme in English.
- In the part of Europe I'm in, nobody wants to use Vue, so it is difficult to hire.
- Nuxt.js is terrible compared to Next.js. They're also in this "2 to 3" rewrite, and have been terrible at communicating. Probably our project at work will never move to Vue 3 and/or Nuxt.
- Community feels an order of magnitude smaller than react.
On the good site:
- It has a far, far, far better reactivity system than React. No need to manually track dependencies, memoize callbacks and components, etc.
- It is a lot more easy and intuitive, a lot less foot guns.
- It is a real framework, as you have an official router, state management solution, styling approach, etc. I love this.
Thrilled to hear it! As someone who has primarily written back-end code, I found Svelte to be the most accessible (readable, good/simple docs with lots of examples, easy getting started instructions, clear conceptual framework). Eager to see what comes out of this.
Started learning JS a few years ago. Picked svelte for my front end stuff because the other frameworks seemed saturated with experienced devs already and I wanted to be closer to the ground floor on something. I've been waffling the last year or so, wondering if I should focus more on NextJS because it was backed by Vercel.
I breathe a little easier today! This is great and can only be a good thing for svelte and sveltekit.
I love Svelte, and have been using it for a year or so now, but lack of community mindshare means that I've had to roll a lot of my own components.
That said, I think Netlify missed the boat on this one - happily using Netlify with Sveltekit, and it would have been great to have the competition in the PaaS space.
>You know, I guess all I can say is that we're thinking about this stuff too, and, like, we want the development velocity to be as fast as possible. But we also don't want Svelte to become like some, I don't know, some VC-funded FauxSS -- did I just coin that: FauxSS? I like that!
>It feels like there's more and more of that these days. There's a lot of people working on open source software, and then, like, you discover that there's a business model behind it.
>And I'm always a little bit skeptical about whether or not that is in the best interests of the software itself. And I don't want Svelte to become a thing that is run in the interests of the people building it, I want it to be a thing that is run in the interests of the community at large.
So what is the opposite of FauxSS? ProSS?
Hmm: "pross: a person who engages in sexual activity for money."
So I guess that means OSS is as great as sexual activity. ;)
I've been following Svelte, and it sounded great, so I've wanted to use it for some time. Now I've finally started a project with SvelteKit, and it's even better than I hoped, with extra layers of greatness I didn't even realize, like pre-rendering pages, at the same time as being very mobile SPA friendly.
This is my first look at Svelte. It looks amazing. I hope for day when front-end development is more language primitives and less frameworks--what with their 'useEffectOf' and @Component's of the world.
I think the problem Svelte is having in this area is folks looks at it the same way they look at React, Angular and Vue. All those frameworks (especially React and Angular) have their own way of doing things, so you have to know "HTML, CSS, JS and React/Angular".
I think folks think that Svelte is the same way, while it does have it's own special sauce, it's nothing compared to React/Angular. Like others have said, when hiring for Svelte, you don't really need the candidate to have Svelte experience.
Consider trying to hire outside Svelte - Anyone that can write using the major frameworks will do just fine. If the problem is candidates uninterested in using it, that's a different problem.
Cloudflare will regret not having a developer go-to framework for their advanced Worker stuff one day.
I think they are waiting for someone else to build for it which is IMO the completely wrong approach for the dream of the serverless app. You got to own the full stack including software.
I can easily see Vercel becoming the pretty much only go-to in this space just from the developer trust they have created with Next (and now Svelte). The general getting started experience between the two serverless providers is night and day.
One is where do I begin / how should I do this (cloudflare).
The other is simply code... and... go! (vercel)
I'll be all in on whatever Rich makes there. Been waiting for a solid Cloudflare Worker framework for literally years bridging front-end and back-end. Instead, we got Pages (which is cool, just boring for the fun stuff).
Cloudflare currently markets successfully to a very different calibre of engineer. Meanwhile, Vercel don't even support 2FA login yet, and publish mandatory cache-busting query string parameters to the public Internet. Their "CDN" is a BYOIP range running on AWS Global Accelerator
Hey! Guillermo, CEO of Vercel here. Security is the absolute top priority at Vercel, and you should be seeing continued progress in that area in the coming weeks and months.
We're heavily investing in security all the way from the SDK and its supply chain[1] to platform, product and cloud.
We proudly use the best infrastructure and products available to help our customers scale without stress. AGA is quite incredible[2] and so is Cloudflare[3] and we are honored to be able to work closely with the purveyors of the finest infrastructure on the Internet!
Thanks for chiming in here. Unrelated, I saw that Vercel is ramping up hiring for designers. I’ve always worked in consumer-facing design spaces (banking, travel, etc.) and want to make a change toward something more dev-oriented like Vercel, but I worry being told that “I don’t have the right experience”. Does Vercel hire folks looking to change the industry they design for? I’m a senior IC in design systems, so the extent of what I design for devs is mainly documentation sites.
Absolutely. A core goal for us is to Lower the Barrier of Entry[1] to building for the Web.
Building a beautiful and fast Web experience needs to feel myspace-code-easy (or as Rich Harris puts it: it has to be fun!). I think ultimately that's what makes the Web win long term. It's open and accessible.
The best way to contribute to this mission is to come in with a fresh mindset, passion and big ambitions. Please reach out: https://vercel.com/careers
As a heavy contributor to SvelteKit, I can't see a loss in neutrality happening. I personally use other hosting platforms frequently with SvelteKit, both Rich and Vercel have expressed they want to avoid this outcome, and other SvelteKit maintainers work full-time at Vercel competitors and also wouldn't let that happen ;-)
They do have https://flareact.com/ and although it is still early, it is very promising. They have used patterns from Next.js so it is easy for developers to migrate.
Yes! To compete, cloudflare really needs a nicer "full-stack" experience where you have one repo, one config file, one CLI and one codebase that is shipped automatically into pages and however many workers, dns rules, kv stores, durable objects, Images and Stream deployments etc. They have Wrangler but it doesn‘t really feel "complete". At least they should rename it to cloudflare-cli and cloudflare.toml.
I do think it's interesting how they've positioned Cloudflare Pages. Kind of an "Amazon" move. Unlimited bandwidth and seats. Will be interesting to see though if it works for Cloudflare, they still don't even have Gitlab integration.
Vercel is built on cloudflare workers meaning vercel winning means cloudflare wins. Also I think building out the datacenters across the globe is a much harder problem than building out a framework.
That animation in the background could use a little optimization. It's redrawing nonstop for no reason. Left the site open for a few mins and it got my humble Thinkpad's fans going hard (Vivaldi).
making a framework popular is harder than making data center stuff; people successfully rack boxes and crank rust/go/js/.. every day, but most js frameworks fail
Cloudflare seems to be disciplined about releasing solid lower-level platform building blocks first (e.g. durable objects), and leaving the "developer go-to framework for their advanced Worker stuff" to be built on top later.
Seems like a smart approach to me, but I agree the space is moving fast and even though they release stuff at a pretty rapid pace, it never seems fast enough for early adopters
Why has this discussion become a Svelte vs React war? React is not going anywhere, Svelte is pretty cool and very young and it's exciting and it will be fun to see what cool new patterns emerge from larger use, as much as React patterns changed with time.
I started with Emberjs (which i love and had some faults), then move to React (which i love and had some faults), then Vue (which i love and had some faults) and now I am trying Svelte, which i love and has some faults.
That's what maintainers do, make their frameworks better.
people saying that they don't understand the new toy as well as the old toy they are used to...i mean...yeah!
and people saying that devs write bad code because of the framework, remember how much logic and bad code was in the view layer of mvc frameworks, how much logic and bad code was in class initializers and lifecycle methods in react components etc.
Give svelte some time and contribute to make it better if you care!
Svelte is really great. It really needs this boost in cash to polish the rough edges and improve tooling etc.
I’d add that most people here who are hating on the syntax didn’t go to check what svelte is actually about. I say that even though I work with React professionally
So smart by Vercel. So many people will use their platform because of the association with Rich. This is a marketing expense that will show up on the books as headcount. Rich deserves this, he's created an amazing project with an amazing community.
Hey! I'm Lee, Head of DevRel at Vercel :) Happy to answer any questions you have.
Vercel is a frontend cloud platform that integrates with any framework you prefer (or just plain HTML!). We are also the creators of Next.js, which is a React framework. We try to make it as easy as possible for you to write some code and put it on the web, globally.
Hey Lee, just listened to your chat with swyx the other day. It was great hearing how Vercel positions itself and your thoughts on devrel!
I know Vercel has a great developer relations team already— what would the appetite be for more Svelte DevRels in future? I've been working as a developer advocate and love Svelte enough to have even given talks on it. Would be an opportunity I could see myself in for years :)
The cool thing about Svelte is that it compiles your code in a way so that when variables change, bindings in HTML change, but only that HTML and not an entire DOM re-render. (Right?)
So, if this is the case, how come React couldn't do the same thing? They'd lose the ability to just include react in a script file, but why can't a smart compiler look at your JSX and throw out the virtual DOM component, so your variables are directly bound to where they're used in the HTML?
i did try that - https://twitter.com/swyx/status/1294310598419689472 but when the core team is not interested in it there's only so much i want to push it on my own - rather just move to Svelte where the community already gets it
Looks great! Seems to me that there’s just not enough pain around this. Ironically, React being “good enough” at performance (in most cases) probably means that there’s not appetite for squeezing out the last few millimeters (again for the vast majority of use cases — clearly there is some need otherwise svelte wouldn’t exist).
I often ear this "vast majority" claim but is it true? Every slow website I encounter is react or angular based. Maybe I just don't notice the fast ones, but react and fast enough are not really my experience
This might be possible in simple cases, but there are two reasons I think.
1. React has an ethos of being “just JavaScript” (despite the JSX syntax which is purely sugar around calls to React.createElement). This means the core team doesn’t seem to be interested in adding an extra compiler step.
2. Related to the above, because React is just JS, you can do all the normal and horrible things with it you can do in JS. Wanna pass React elements around in context or even using global variables? That’s allowed. A compiler could probably handle a lot of simple cases but there’s a whole lot of things it wouldn’t be able to deal with.
Hm, I think this isn't possible with React. You'd have to impose lots of constraints on how a component renders. Currently it's basically anything goes. IMHO, the result just wouldn't be React anymore.
In fact, Angular works exactly like this. Only the DOM nodes that have bindings/directives attached are updated, the rest is static during a component's lifetime. Though all this still involves tons of runtime framework code.
I actually think Ember/Glimmer happens to have the best implementation of this, where their diff can be incredibly optimised because they know the semantics of the template and can just skip all work on static elements and attributes that never change.
When your React component renders, it returns an object that describes the
desired state of the component tree. Take this component:
function MyComponent() {
return <div>Here's <b>bold text</b></div>
}
At runtime, React calls your component function and then applies the returned
data to the DOM imperatively. If your component has rendered before, React needs
to _diff_ the virtual DOM your latest render returned against the VDOM React last
applied to the real DOM. Very simplified idea of what happens on every render:
function reactInternalRenderLoop(root) {
const newVdom = MyComponent({})
const diff = diffVdoms(root.prevVdom, newVdom)
for (const change of diff) {
change.applyToDOM(root.domNode)
}
root.prevVdom = newVdom
}
React's runtime time complexity is fundamentally limited by this `diffVdoms`
function, and React's memory usage is fundamentally limited by the size of the
VDOM returned by components.
What Svelte does is entirely eliminate this whole process involving diffing and
what-not. At compile time, Svelte analyzes the data dependencies between the
rendered template and reactive values in the app, and generates self-contained
components that know how to update their own DOMs. You can think of it as
essentially moving the entire `reactInternalRenderLoop` function from _runtime_
to _compile time_. There is no more diffVdoms function call on your user's
devices. There is no more big allocation of VDOM data structures.
Svelte might compile `MyComponent` to something that looks like this:
And since the Svelte compiler knows the contents of MyComponent never change,
the mount function will only be called once for the entire runtime of your app.
So it sounds like the tradeoff here is that the generated bundle is more complicated/bigger. I'm not familiar with Svelt, but wondering about bundle size + debuggability.
At a certain size, yeah the bundle will be larger, but it would take a lot to get to that point. For pretty much anything you would do, the bundle will be much smaller. Especially if you use SvelteKit which is smarter about what is bundled and when it loads.
As for complexity, the generated Svelte code is extremely readable. Take a look at the generated JS tab in the repl: https://svelte.dev/repl
When I tried Svelte a while back (year or two ago) I had difficulty working with code in the debugger, couldn't seem to get source maps to work correctly, I wonder if it's fixed.
Surgical = "It checks a diff of what the component rendered before an update vs. after and then only patches or updates the parts of the DOM that need to be changed (as opposed to replacing the entire DOM, which is slow)." Similar to React. Svelte may not be using the exact same mechanisms but this is in the ballpark.
Virtual DOM is just an in-memory representation of the DOM that describes which child elements (e.g., a <p /> nested within a <div />) belong to which parents, and which attributes/values those elements need at render time. When a change happens, you can generate an updated virtual DOM and diff it against the previous (or current) version and pick out what specifically needs to be changed in the DOM (read: surgically).
There is no diff going on with Svelte. And there doesn't need to be an in-memory representation of anything. Because it is compiling the code, it knows exactly what will change and in response to what.
For example in that repl, you can see that it makes a call to `$$invalidate` when the input value changes (see `input_input_handler()`) which triggers a `set_data` call (see `p()`) to update just the textNode that contains the name. This is what is meant by surgical. No other work is done other than what is required to update the specific places where a variable is used.
I like React’s opinionated top-down model (with callbacks passed downwards as needed either directly as props or through a store / context) for handling state changes, as this improves composability and ability to reason about state.
My understanding is that Svelte’s main difference from React is that it is not opinionated in this way, and this is considered a positive feature by its proponents. Is my understanding incorrect?
I think it is so much easier to simply `bind:value` than have to write my own event handler to update inputs, etc. Similarly, it's much simpler to have the parent bind to a property of the child rather than passing the value down along with a function to update the parent every single time. In effect it works the exact same way, but I have much less to do to get there.
Store-wise, Svelte stores aren't fundamentally different from having all of your state in Redux, and I prefer that it encourages smaller stores rather than one giant one.
On top of that, it just feels better to me writing HTML, CSS, and JS instead of trying to shoehorn everything into JS.
Virtual DOM? That’s the internal machinery that allows you to specify (and update) the UI declaratively while applying only localized updates on the actual DOM. It’s a feature, not a drawback, when you want to code declaratively.
Next just bought its biggest upcoming competitor—SvelteKit. Next is the best that React has to offer but it still has flaws. Svelte and SvelteKit are so awesome you cannot believe it before you've built something bigger and so much ahead of the entire React ecosystem.
We migrated a huge/complex React app in a month and the difference is night and day (performance/bundle size/dev productivity). React was great but it's time to move on.
I'm disappointed by Rich. Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)—he just cashed out (sky-high compensation and ESOP). Not a rant and to give you some background, one major reason we went with SvelteKit was not to rely on the Next team. And now, I am again with them...
Now we have a monopoly of rare, modern SSR frameworks.
I understand this perspective! But as anyone who knows me will tell you, I would be the worst person in the world to try and build a business around Svelte. As others have said, the expectations from investors would make it far less likely that Svelte could remain a community-centric project.
It's important to clarify that Vercel (which has earned its open source bona fides) hasn't 'bought' Svelte or SvelteKit. It's more accurate to say that they're supporting Svelte's development by paying for a full time engineer to work on it. There's a healthy core team of developers who certainly won't relinquish _their_ independence because of _my_ career choices.
It's fair to be sceptical about all this! But I've had multiple conversations throughout this process where the importance of maintaining independence was expressed by both sides, and I truly believe this is the best outcome for Svelte and its community.
Congrats on the job, Rich! I've been using Svelte, Typescript & Babel in the past couple of months to build a set of TV apps targeting some fairly slow and ancient devices and it's been brilliant. Totally impossible to do that with React, I do know some people who tried it though.
We're all lucky that you got a polite, substantive reply, but please don't cross into personal attack like this in HN comments. It generally causes discussion quality to tank drastically.
@dang, second reply and apologies, now I know what you mean, I edited some part away which you probably meant and which is still in quotes of others' comments. Sorry, I'll try to improve and thanks for the hint!
Can't follow you, what do you mean/where did I cross into personal attacks? I highly appreciate Rich but the elephant in the room had to be addressed, especially on HN.
I wonder that I am the only one that questions his move and that you also approach me instead of welcoming a healthy debate. Whatever, I guess you just do your job.
Btw, when does HN get proper pagination and a darkmode?
Do I get shadowbanned now for asking too many questions?
> I'm disappointed by Rich. Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)—he just cashed out
That includes a lot of assumptions and is unduly personal. I realize you're coming from a place of being a fan, but still, there's an ordinary human being on the receiving end of such comments.
> Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)
In no world would taking VC funding have been easier. They’d want cash returns and hockey stick growth, and soon. So instead of focusing on making the framework as good as it could be, Rich’s attention would be diverted.
When SvelteKit becomes a framework impossible to run on anything that isn’t a Vercel platform, then maybe I’ll be outraged. Until then, subjecting an incredibly talented developer to the day-to-day whims of VCs seems like just about the worst outcome for everyone.
I don’t normally mean to sound uncharitable but your original comment is pretty uncharitable to Rich, so: if you want a stable platform that will live for many years to come, the absolute last thing you want is for it to take VC investment. That you don’t see this speaks volumes to your understanding of how any of this works.
interesting that you think talking to a VC and starting a startup (where he would be spending >50% time on business things and be forced to come up with a monetization plan) is better for svelte than getting fulltime sponsorship to solely work on Svelte and working with the top tier talent at Vercel.
Svelte and Vue got started when someone just went and did it. If you think it's so important to have many competitors in this space, just go and do it :)
No desire to be acquired (open to investment but that's it), just build a business around accompanying features/services.
Goal is fast, simple, and friendly regardless of your skillset. No lock-in as the entire thing is a thin abstraction over Node.js/Express.js and components are built using plain HTML, CSS, and JS (no special languages or syntax). Also adding in a lot of helper stuff so you're not stuck cobbling together random packages for common stuff (i18n, form validation, etc).
Feel free to email me if you or your team have questions: ryan.glover@cheatcode.co.
Edit: your account has unfortunately been posting a lot of unsubstantive comments. Worse, we've had to ask you many times not to break the site guidelines. I don't want to ban you, so could you please review the rules and fix this?
We're really trying for a different sort of internet forum here, and we need everyone to pull in the same direction to have a chance of that working in the long run. The default is deterioration, followed by scorched earth, followed by heat death. We're trying to stave that off here, at least for a while longer: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so....
I'm sure he'll see this soon, so congrats Rich! Svelte has been a cool project since the beginning, and I'm excited to see Rich have more time to work on this. As an early contributor I've seen Svelte go through a lot of maturing and it's exciting to see it finally getting the recognition it deserves lately.
I think stencil or Lit are more interesting. I'm not sure I'm the fan of small libs like Lit or preact - I think for scenarios where you have more than 2-3 elements you will have less bytes over the wire very quickly.
Seems more like variety. React is in a league of it's own with React Native. For web tech Svelte is cool, for app tech it's not on the radar.
I used to be a web developer, now I'm a React Native / RNW developer.
I don't use web tech unless I'm making a simple web page, when I do I use vanilla HTML/CSS/optional JS.
You get a web app for free when you make a RN app. You can share 95% of code among 5 platforms. (web, windows, macos, ios, android)
Conditionals can change any styling you need amongst them. You can swap out scripts depending on platforms, you can access any extra native platform function with extensions.
Svelte doesn't work for me because you need JS. I don't want to need JS for simple web pages, for apps I need cross-platform.
Svelte could work well for edge computing like CF workers.
How is RN? I have seen several teams try to consolidate their App Devs into RN devs, only to split back into iOS/Android devs. From what I’m told, if your app could be a webpage, RN is great. But if you need to really leverage the specific platforms, it’s hard to do that.
> But if you need to really leverage the specific platforms, it’s hard to do that.
Not my experience. I have a production app for web, ios, and android, with desktop platforms coming.
You can swap out anything per platform and write any extension for any native functionality you don't have, but the std and community extensions are plentiful.
RN sucks for "web pages", great for apps. In fact sometimes I embed web pages inside my RN apps. (surveys, etc.)
I haven't heard a single good argument of why it doesn't work. If you were going to write a native app you can write a native extension and share the common parts in JS.
RN is not Cordova, it's not a black box, it's very flexible and extensible.
-- @Jcampuzano2 because of post limit --
Earlier yes there's some fickleness with the toolchain, I don't really have issues now, it's fine unless you're on bleeding edge versions or old versions. Performance issues usually relate to the JS bridge, JSI will alleviate that, most devs won't experience an issue. I don't know why others struggle with RN, it works well for me. Flutter is a no go because it emulates native, it's not true native. You can feel the difference on iOS and the web part sucks so hard.
Weird because this is the exact opposite of everything I hear from most developers I know.
I personally also worked with React Native for a while, and sure, you can write native extensions for everything, but the biggest complaint is how fickle it is when it comes to upgrading, package management, mind boggling errors related to the metro bundler, etc.
I.E. It's great when it works and you have something simple, but things broke so often compared to native development when you had to do anything complex. And the performance characteristics weren't very great on top of this.
I haven't done React Native in a bit more than a year but from people I talk to not much has changed, and most people I talk to who were all in on React Native mention to use Flutter instead nowadays if you really want cross platform UI.
react native can definitely ship production ready applications that large teams work on. bundler problems arent even react native related.. theyre webpack/babel etc. Package management? how is that related to RN?
Because you never have to deal with that stuff in mobile apps unless you use react native? So sure maybe it’s not directly react native’s fault but it is an issue.
This thread initially started by me comparing Svelte to React.
React uses webpack usually, RN uses metro usually, you can use esbuild, swc, etc for either though.
Svelte is a web tech, and thus uses web bundlers like webpack, thus has the same "faults", though I'm not sure what specifically is being critiqued.
When comparing RN to other cross platform solutions like Flutter you're wanting to compare it's package manager / bundler to Metro and the native dependency systems such as Cocoapods.
you will always have to manage dependencies somehow. Maybe you prefer the model used by flutter or something, thats preference. Its not a matter of whether of one is unsustainable or not. react native is fine for professional or hobby projects. even if you have problems with babel/webpack/etc bundle server (which btw can be worked around using inline bundling...)
My experience with the tool chain was abysmal. It's been almost 3 years away now for me, so I don't know the current state of things. I hope it has improved.
But every update was a large effort in bringing the app back into compliance with the new changes. The debugging platform used a different interpreter than in app resulting in things that worked in the debugger but not in production. Odd bugs at boundary layers nobody could (easily) decipher. The inability to even catch or do anything with some crashes.
It was the worst experience I ever had with a development tool chain in my entire career.
Disclaimer, these memories are about 3 years old...
> What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.
Exactly what I said, there would be some code that would run differently in the two environments. I know more now than I did then, but I believe the example was specifically on iOS the app was using JavaScriptCore and the desktop dev tools was using v8.
> I'm not sure I understand, could you provide an example?
> Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.
Best as I recall, there was a semi-frequent bug that happened down in our logging system. When it blew up we got a native stack trace instead of JS. My best guess is some kind of handshaking problem between the two layers. Neither used code we wrote and maintained.
Because the whole thing happened inside our error reporting engine, it wouldn't end up in our logs other than a high level apparent failure. It was a mess, and we had limited native experience on the team when it happened. We hired a dev with more native experience, but we still didn't ever figure it out while I was there.
The tool chain always felt like it was a hacked together early beta. To complicate our experience our internal APIs were a mess and unreliable and our React Native codebase wasn't dramatically better. Between our internal problems and all the idiosyncrasies and unintuitive issues in the tool chain it was really miserable.
It wasn't unusual for everyone on the team to spend more than a day simply trying to get the app running again after an update, that is after a dev had completed a 1 to 2 week migration required after the update.
To me, it's uplifting the entire web ecosystem. There will always be developers who pick Svelte and friends over React, even if that reason is just syntax preference. Those developers should still have the best infrastructure for their apps. Better to be pragmatic than over-prescriptive.
If you are building a platform for web dev, it’s better to be able to control your technology. Any change FB makes to React may leave you scrambling to patch your tech. Or What if one day FB decides to stop supporting React, or they make a design decision incompatible with your business? While it sounds unlikely, it’s bitter pill to swallow from a business angle.
And then you would probably be forced to support classic FB React for customers that didn't want to migrate, and forked React.
The real issue is if you build any special sauce on top of React. Say you went all in on providing a customized React.Component that worked like a React.Component, but had your platform's logging, perf metrics, etc built in. Then React comes out with hooks and functional components and then you are stuck trying to reimplement your special sauce using these. Or you have to tell customers, "we only support class based components." While functional components are old, FB has shown it will introduce paradigm changes into React, and you are left holding the bag when it comes to supporting them in your platform. And if customers saw a new React feature previewed yesterday, be sure they will be asking for support for it today. FB isn't likely to hand over React to Apache or any sort of open governance model, so changes can be easily made without a huge amount of forewarning, or even a business relationship. Last time I checked FB wasn't selling support contracts or partnerships for React.
I've been a fan of Svelte and Vercel for a while so it's cool to see Rich working with them, and for Svelte to get more support. Very excited to see what comes of this!
Feels like a good move. How else could framework be developed than implementing some requirements. Vercel should provide lots of them.
What else can be added to Svelte btw? It looks like a finished project already. People can only invent in Svelte area if browser standards move forward, right? Otherwise Svelte can only be used to support needs of some platform.
2. Compared to React yes, because Svelte ships no runtime (or at least a very minimal one). There is a curve though, and very large apps (in the hundreds of components) will eventually be overtaken by something like Preact or vue.
3. No runtime means no restrictions on what they include in the framework. They take full advantage of Svelte being a compiler and include things like complex state management in the form of stores, a built-in transition/animation system with support for springs. Also the included syntax is extremely concise, if you're familliar with vue it'll be fairly easy to pick up.
Honestly, don’t really know much or care much about Svelte for my own use. But hearing that someone is going to be sponsored to work on their invention full-time is wonderful. Glad to witness this personal victory and sending good vibes to help make Svelte great.
i just started rebuilding my personal site with nextjs but the enthusiasm here is pushing me to try svelte for the first time.. guess ill have to take a look at the feature list
It is really worth it. Svelte is sooooo much better than React. Believe me, I was one of the skepticals about the entire SPA thing but after trying Svelte I think my problem was with React, not with the concept per se.
i dont actually have any problem with react, but im definitely open to new things this thread reveals to me that this Rich character has some useful information i should look into.
`next/image` works self-hosted (it uses either Squoosh or optionally Sharp) as well as with any third-party solution you want. Vercel is just one choice!
Didn't know who Rich Harris was. Could probably include that in the title, or link to the blog post on the Vercel website. Clicking on his Twitter picture requires logging in and only through the Vercel blog post headline did I find out.
That's still all web tech, though. Druid and Iced look more interesting, as they are general UI frameworks which lets you build both web and desktop apps without dealing with HTML or CSS.
I do React for my day job. For personal projects and MVPs, I came back to Rails and it has been insanely fun. I can drop in whatever frontend framework I want or none at all.
With Sveltekit, you can actually build your back end with it as well. The path based routing is so nice and intuitive (compared to my recollection of Rails 3.x), and if you compile your SvelteKit application with the node adapter, it will include a back-end server too.
The only catch of course, is that you have to like both Svelte and NodeJS.
Is there any reason why something like Svelte couldn't be written in one of the lisply languages? The compiler approach seems definitely like a good fit.
I guess I'm not a fan of seeing investors money expand it's control over the open source ecosystem. I like open source because it empower the little guys. But I don't expect others to share my values and perspective and perhaps Rich Harris turns out to be a robinhood. Why not doing something like the creator of Vue? With that said I look forward to see what comes out of their shop. Good luck :)
People downvoting...I've bootstrapped my own business so I can speak my mind freely and don't mind being disliked, as long as my customers like my work.
Now for today's topic:
1) life 101: nobody gives you money for nothing
2) If they give you 5% they will act as if they have given you 90%, it will happen gradually
3) Vercel is seeking monopoly over front-end deployment using investors money and buying open source contributors, of all the major frameworks, they would have done the same with ReactJS and Vue if they could and they will try doing it with any framework that gains momentum. It is a fine strategy, not my cup of tea.
4) I'd rather support bootstrapped business and solo developers
5) I personally wonder how someone with the portfolio of Rich Harris couldn't manage to get sufficient sponsorship to go full-time given how much value he has generated to the community, I think this is something open source community need to tackle, perhaps crypto can help contributors make money earning easier? How about 1 token for each download, fork or install something like that that would help open source contributors generate money just by creating value...something is really broken here and I think there is a room to innovate with micropayments, I mean we know the likes, forks, issues, we have the entire repo content, we have the history of the contributors, given all the fuss about crypto, I wonder why haven't we seen anything in that direction yet, am I missing something? I think monetization of open source should be built within the platform (Github or some modern alternative), with different options on how contributors can run their content creation business. They can choose to give it free, free up to a point, or charge from day one, it is still open source, etc. Lots of room for innovation.
6) Many people share my mindset, but afraid to speak out, so here it, is plain and simple.
6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don't like Svelte very much.
I think Svelte is clever, and interesting, and I'm glad it exists. But I found a few points insurmountable:
- Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
- Special syntax for reactivity is not javascript
- I find the javascript-native flexibility of JSX far more expressive than any custom templating
- There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
- Two-way data binding is a constant source of bugs
- Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
- The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
- Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
- The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
- Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
- The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.