Rich Harris joins Vercel to work on Svelte full time(twitter.com)

907 pointsby leodriesch5 anni fa542 comments

Rich Harris joins Vercel to work on Svelte full time

https://twitter.com/Rich_Harris/status/1458822051263823875

556 comments

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.

StaticChamp5 anni fa

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.

============== Svelte > React ==============

merrywhether5 anni fa

> And why doesn't it allow style tags?

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.

taurath5 anni fa

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.

jseban5 anni fa

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

DonHopkins5 anni fa

>- Special syntax for reactivity is not javascript

Are you referring to Svelte using the $: dollar label prefix syntax for reactivity?

Yes, that is most certainly is standard JavaScript syntax. Read the docs:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

>label: The labeled statement can be used with break or continue statements. It is prefixing a statement with an identifier which you can refer to.

https://svelte.dev/docs

>3. $: marks a statement as reactive

>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.

https://dev.to/itsjzt/understanding-svelte-s-dollar-label-sy...

>Understanding Svelte's $: (dollar label) syntax

>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.

bGl2YW5j5 anni fa

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.

Aeolun5 anni fa

Redux is not React specific. I assume you could use it with Svelte somehow.

That said, most React components are lightyears ahead of native Javascript components, simply because everyone uses React.

acemarke5 anni fa

Yes, and in fact we even have a demo of our new RTK Query data fetching API (part of our official Redux Toolkit package) being used with Svelte:

https://redux-toolkit.js.org/rtk-query/usage/examples#svelte

joeyjojo5 anni fa

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.

tshaddox5 anni fa

How about unstyled components like a dropdown menu or a multi-select with autocomplete?

arxpoetica5 anni fa

> Special syntax for reactivity is not javascript

That's because there is no syntax for reactivity in JavaScript, period.

Sammi5 anni fa

> 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.

JimDabell5 anni fa

> - Special syntax for reactivity is not javascript

> - I find the javascript-native flexibility of JSX far more expressive than any custom templating

These are odd points to combine – JSX is special syntax not JavaScript as well.

veidelis5 anni fa

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.

toastercat5 anni fa

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

jeswin5 anni fa

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.

toastercat5 anni fa

> 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.

Kiro5 anni fa

It's very common if you're working with Tailwind (since the markup is self-contained). No need to be condescending.

toastercat5 anni fa

Sorry, I did not mean to be condescending. I do use Tailwind, but even then I don't really copy-paste HTML examples.

zdragnar5 anni fa

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.

malcolmstill5 anni fa

> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte

Do you have some specific examples?

bdougherty5 anni fa

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.

jakelazaroff5 anni fa

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.

toastercat5 anni fa

2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).

eins12345 anni fa

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.

toastercat5 anni fa

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).

eins12345 anni fa

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.

[deleted]5 anni fa

awestroke5 anni fa

It's never two-way in react. You're always in charge of updating the state in the event handler, which means you know where the update came from

toastercat5 anni fa

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.

[1] https://reactjs.org/docs/two-way-binding-helpers.html

awestroke5 anni fa

Well, that mixin has never been the standard way and has been deprecated for years (and for good reasons)

toastercat5 anni fa

The mixin is irrelevant to the point I was making. :) The point is that even the official React docs defines two-way binding as I describe it.

wruza5 anni fa

What do you mean by two-way and one-way exactly? (Asking it because web sometimes has a different history for terms.)

brundolf5 anni fa

Not the GP, but here's an example of abstraction leaking straight from their intro tutorial:

> A simple rule of thumb: the name of the updated variable must appear on the left hand side of the assignment. For example this...

  const foo = obj.foo;
  foo.bar = 'baz';

> ...won't trigger reactivity on obj.foo.bar, unless you follow it up with obj = obj.

This looks like a huge footgun to me, and it's not even an exotic usecase. It's in the very first page talking about reactivity in the docs.

d1sxeyes5 anni fa

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)

brundolf5 anni fa

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.

DonHopkins5 anni fa

Another way of stating it is that Svelte doesn't attempt to plug any of the leaky abstractions that already existed in JavaScript.

JavaScript is riddled with huge footguns that aren't even exotic use cases, and if you remove or paper over them, then it's not JavaScript any more.

While React's biggest most obvious leaky abstraction is that React isn't actually reactive.

Neither is Svelte, but at least Svelte doesn't have the audacity to falsly CLAIM it's reactive in ITS OWN NAME, like React does!

I do give Svelte credit for being quite self-referentially svelte, though! And that's something great that React definitely isn't.

How React isn't reactive, and why you shouldn't care

https://dev.to/this-is-learning/how-react-isn-t-reactive-and...

>[...] Is React not reactive?

>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:

https://en.wikipedia.org/wiki/OpenLaszlo

>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).

https://news.ycombinator.com/item?id=22025026

>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.

https://news.ycombinator.com/item?id=14418108

>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:

>Instance-First Development

http://blog.osteele.com/2004/03/classes-and-prototypes/

>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.

https://news.ycombinator.com/item?id=21841054

>[...] 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. [...]

https://news.ycombinator.com/item?id=7756215

>Oliver Steele (one of the architects of OpenLaszlo, and a great Lisp programmer) describes how OpenLaszlo supports "instance first development" and "rethinking MVC":

http://osteele.com/archives/2004/03/classes-and-prototypes

http://osteele.com/archives/2003/08/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!)

What is OpenLaszlo, and what's it good for?

https://web.archive.org/web/20080313080025/http://www.donhop...

>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?

Constraints and Prototypes in Garnet and Laszlo

https://web.archive.org/web/20080224054750/http://www.donhop...

>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 old NeWS, Laszlo is non-toxic AJAX

https://web.archive.org/web/20080227082801/http://www.donhop...

>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. [...]

https://en.wikipedia.org/wiki/NeWS

>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)":

https://news.ycombinator.com/item?id=22455722

>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:

https://news.ycombinator.com/item?id=22456831

toastercat5 anni fa

> 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.

jeswin5 anni fa

> 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.

hbbio5 anni fa

JSX popularized it but we built it with opalang.org first (also with strong static typing before TS)

dharmatech5 anni fa

Opa was pioneering. Very impressive. Ahead of it's time.

What stack do you prefer these days?

It seems some folks still have their eye on the "full stack / single language" holy grail.

hbbio5 anni fa

Thanks a lot!

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.

conradfr5 anni fa

Funny as when I used React back in 2015 it was my least favorite feature (I moved to Vue since then).

lucasyvas5 anni fa

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.

el_dev_hell5 anni fa

Agree 100%. The migration from componentDidMount, componentDidUpdate, etc to useEffect was a major regression in terms of readability.

The return function in useEffect vs. componentWillUnmount is just terrible. This is always a bizarre topic for juniors.

leodriesch5 anni fa

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.

mlajtos5 anni fa

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.

el_dev_hell5 anni fa

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).

_hzrk5 anni fa

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.

marstall5 anni fa

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.

phist_mcgee5 anni fa

Why do you think it's terrible?

francislavoie5 anni fa

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.

TranquilMarmot5 anni fa

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.

francislavoie5 anni fa

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!

phist_mcgee5 anni fa

It's very easy to convert a hook to a HoC, purely wrapping that functionality in a class component.

TranquilMarmot5 anni fa

Also true. It just seems like `class` has become a bit of a dirty word, at least the last two places that I've worked on React codebases.

phist_mcgee5 anni fa

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.

rajin4445 anni fa

Overloading the meaning of native language features is not the most beginner friendly. It’s a quirk you just have to remember.

Compared to an explicit method name it is much less intuitive.

STRiDEX5 anni fa

I agree, but it can be made easier by exposing named functions that help like useUnmount

https://github.com/streamich/react-use/blob/master/src/useUn...

angusturner5 anni fa

As someone familiar with the old react API, I agree 100% about useEffect being super arcane.

There's just too much magic going on, which is the same thing that makes me reluctant to write Vue or Svelte (after reading this)

0x1428575 anni fa

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.

cageface5 anni fa

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.

bigyikes5 anni fa

Eslint will ensure all dependencies are listed in the array. Is there something more you’re wishing for?

lewisl90295 anni fa

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

brundolf5 anni fa

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.

nsonha5 anni fa

mobx tracks dependencies for you, and it's not magic if you understand the basic concepts of proxies and dereference

kecupochren5 anni fa

MobX does that.

toshk5 anni fa

Yeah useEffects was the start over overcomplicating react.

midrus5 anni fa

Yes, clearly it is not for purists.

Donckele5 anni fa

“ - 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.”

What? Can you expand on that? Makes no sense.

korla5 anni fa

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.

tuukkah5 anni fa

> - 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.

brundolf5 anni fa

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.

tuukkah5 anni fa

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.

brundolf5 anni fa

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

tuukkah5 anni fa

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.

brundolf5 anni fa

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.

brundolf5 anni fa

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

What are some examples of this?

FractalHQ5 anni fa

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!

arxpoetica5 anni fa

> 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.

_ta_22312345 anni fa

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.

merrywhether5 anni fa

> 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.

tekkk5 anni fa

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.

benmccann5 anni fa

> 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!)

for1nner5 anni fa

Bless you.

sxiao5 anni fa

Ben, please don't surprise us and tell that you are the next one on Vercel's payroll.

benmccann5 anni fa

I'm doing my own thing and won't be joining any existing company ;-)

sxiao5 anni fa

> won't be joining any existing company

Good news and the most underrated and overseen comment in this thread. Nice man!

FractalHQ5 anni fa

> ecosystem is larger by a good amount.

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.

noir_lord5 anni fa

It's also really easy to use with typescript.

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.

jeswin5 anni fa

> So just about any JavaScript package can be imported into a Svelte file and used without hassle.

But you can import any package into React (or any other framework) as well.

mikojan5 anni fa

You cannot even import native javascript functions. Looking at you, useInterval and useJoinString

nodejs_rulez_15 anni fa

Hearing about a JS framework "X" that is surely that much more elegant than "Y" feels like it's 2010s again!

bGl2YW5j5 anni fa

At least this time Svelte is a step closer toward the native browser stack rather than yet another abstraction layer.

the__alchemist5 anni fa

Why not use the native browser stack? It's pretty good now.

vagrantJin5 anni fa

This is the real question.

[deleted]5 anni fa

kall5 anni fa

Well if there‘s any place to learn from next.js it‘s probably Vercel. Looks like great news for Svelte.

dceddia5 anni fa

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!

Tade05 anni fa

> I was able to step through the compiled Svelte component code and narrow it down to one of my own functions.

This is the best part about next-gen frontend frameworks. We can go back to having a stack trace uncluttered by layers of asynchronous abstractions.

dceddia5 anni fa

Love me some good old synchronous code! :D

vgel5 anni fa

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).

dceddia5 anni fa

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.

vgel5 anni fa

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.

gnrlst5 anni fa

I see your app is MacOS only at the moment. Are you re-writing it in Electron or what? Very curious

protonimitate5 anni fa

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).

akiselev5 anni fa

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.

dceddia5 anni fa

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.

dceddia5 anni fa

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.

rickstanley5 anni fa

> without the benefit of HTML + CSS

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.

dceddia5 anni fa

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)

nicoburns5 anni fa

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.

dceddia5 anni fa

Yeah I looked at it briefly but the lack of usage was a bit of a worry. And if I’m honest I really wanted a chance to use Svelte :)

combyn8tor5 anni fa

Interested to hear if you considered compiling Rust to WASM and what your thoughts were?

dceddia5 anni fa

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.

combyn8tor5 anni fa

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.

dceddia5 anni fa

Definitely worth another look. Thanks for the link!

combyn8tor5 anni fa

https://clipchamp.com/en/blog/clipchamp-pwa-case-study/

vips7L5 anni fa

Did you look at .Net solutions like Maui, xamarin, uno platform, or AvaloniaUI?

dceddia5 anni fa

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.

O_H_E5 anni fa

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"

dceddia5 anni fa

Thanks, and yes! "Choose Boring Technology", love this: http://boringtechnology.club/

The idea of spending fewer "innovation tokens" was definitely on my mind when I was thinking through this.

spoils195 anni fa

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.

dceddia5 anni fa

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.

cakoose5 anni fa

Not always at the cost of the users?

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.

LinguaBrowse5 anni fa

Not clear from your wording, but Svelte Native incidentally does exist:

https://github.com/halfnelson/svelte-native

It's a Svelte renderer for NativeScript (a framework targeting iOS and Android), rather than being a port of React Native to Svelte.

kingcharles5 anni fa

Looks cool - what is the timescale for Windows?

dceddia5 anni fa

Weeks to months, hopefully by the end of the year? We’ll see! A lot depends on what other challenges come up, heh.

kevinak5 anni fa

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.

Links: - https://lu.ma/sveltenyc - https://lu.ma/sveltesummit-2021-mainz

ramraj075 anni fa

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..

candu5 anni fa

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.)

DonHopkins5 anni fa

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.

tnzk5 anni fa

Meetup with people who share an interest itself fun?

sholladay5 anni fa

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.

rudian5 anni fa

"Sane" lol have you ever used it?

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.

Be ready for Svelte 4 I guess.

enumjorge5 anni fa

Maybe I'm misreading your comment, but Richard Harris did not create esbuild. Evan Wallace, co-founder of Figma, is the person behind it.

beeandapenguin5 anni fa

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.

- [1]: https://rollupjs.org/guide/en/

enumjorge5 anni fa

That makes more sense. Thanks for clarifying!

deepakkarki5 anni fa

You did misread.

> Until esbuild came along, Rollup was the only sane JS bundler

Rich Harris did create Rollup

dragonshed5 anni fa

Rich created rollup :)

leerob5 anni fa

Hey, Lee from Vercel. I'm sorry you had a bad experience here. If you want to email lee @ vercel, I'd love to hear what we could have done better.

sholladay5 anni fa

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.

If you want more details, my contact info is here: https://seth-holladay.com/contact

cphoover5 anni fa

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.

RoboticWater5 anni fa

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.

cphoover5 anni fa

What how can you say that???

      <ul>{myItems.map({id, title}) => 
          <li key={id}>{title}</li>
      }</ul>

vs... svelte

     <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.

benmccann5 anni fa

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.

noir_lord5 anni fa

Not to mention it takes reactivity to new heights while adding amazingly little actual syntax.

When property changes, the fetch refires, loading appears until the fetch resolves then it displays whatever array someFetch resolved to.

I came from Vue and that plus the way Svelte does stores (literally nothing special about them) was a breath of fresh air.

    <div>
        {#await someFetch(property)}
            <div>Loading...</div>
        {:then data}
        
            {#each data as item, index}
                <div>{item}</div>
            {/each}
    
        {/await}
    </div>

Aeolun5 anni fa

But what does ‘#await someFetch’ actually do? The thing I like most about react is that it’s just executing plain Javascript most of the time.

dmitriid5 anni fa

> The thing I like most about react is that it’s just executing plain Javascript most of the time.

Then explain what hooks do ;)

Hooks are decidedly not Javascript (even if they look like Javascript), and are a much more weird construct than {#await promise}

_hzrk5 anni fa

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.

dmitriid5 anni fa

> 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

Aeolun5 anni fa

They are definitely javascript. I can click to definition of the useEffect function and see exactly what it is doing.

I completely agree that learning them is a bit crazy, but ultimately every hook comes down to being a function execution.

dmitriid5 anni fa

> They are definitely javascript.

How come they break Javascript semantics and execution flow?

> but ultimately every hook comes down to being a function execution.

That's really beside the point when it comes to understand what something is and using them.

{#await promise} is immediately understandable from its use.

Hooks are... well, I already said above.

merb5 anni fa

> 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.

noir_lord5 anni fa

https://svelte.dev/tutorial/await-blocks Explains it better.

hunterb1235 anni fa

His point is you don't have to read some project's documentation to know how some "await blocks" work.

With JSX you can use native JS features instead, you only need to know the language.

For example, instead of looking up how to loop in the template syntax, you use an iterator.

noahtallen5 anni fa

Not just most of the time — all of the time! JSX is converted to plain JS (react.createElement) before it gets to the browser.

tuukkah5 anni fa

Isn't it actually the opposite? Svelte code is compiled to plain JS whereas React has a large runtime.

Aeolun5 anni fa

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.

wruza5 anni fa

I’m neither of (react, vue, svelte) guy, but isn’t that snippet equivalent to some:

  div
    Await promise={mypromise}
      div Loading…
      {res => res.map(…)}
      div Error: {err => err.message}

(writing in pug-like because I can’t stand closing these tags on the phone)

Isn’t it easier in both react and vue to create Await component with children=(ifwaiting, ifresolved, ifrejected) than suffering all over the code?

Edit: I messed data flow up in the error handler, wontfix but you get the idea

[deleted]5 anni fa

makeramen5 anni fa

> If you know HTML you JSX is very intuitive.

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.

DonHopkins5 anni fa

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.

Ambroos5 anni fa

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.

ricardobeat5 anni fa

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.

dwaltrip5 anni fa

Come on… If you know JavaScript and HTML you are 95% of the way to being fluent in JSX. It’s basically just JavaScript expressions.

wruza5 anni fa

And if you know javascript and html you are 100% fluent in any sort of hyperscript, which is just js expressions.

hunterb1235 anni fa

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

wruza5 anni fa

Jsx is not js, it’s python!

  <div className={red}>
    {text}
  </div>

  import react
  react.create_element("div", {"className":red}, text)

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.

cphoover5 anni fa

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.

hunterb1235 anni fa

It's actually a fairly small change (two new PrimaryExpressions), the spec is here:

https://github.com/facebook/jsx

Example parser from Acorn:

https://github.com/acornjs/acorn-jsx/blob/master/index.js

No part of JSX uses the DOM, it doesn't share anything with HTML.

The JS engine itself would need the modification.

Also JSX doesn't have to be for the UI, it could be for dialogs for an NPC in a game, for configs, etc.

edit: I agree with @proxyon, I'm really disappointed with HN that this simple fact is downvoted without retort.

The common sentiment here is wrong, JSX is a small extension to the grammar of JS. It is JS.

kall5 anni fa

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.

DonHopkins5 anni fa

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.

https://en.wikipedia.org/wiki/ECMAScript_for_XML

>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.

https://bugzilla.mozilla.org/show_bug.cgi?id=695577#c1

>Mark S. Miller, 10 years ago

>"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.

https://news.ycombinator.com/item?id=8266648

>bastawhiz on Sept 4, 2014 | parent | context | un‑favorite | on: JSX: XML-like syntax extension to ECMAScript – Dra...

>So..uh...this was a thing. And nobody wanted it. So it was deprecated and killed. See the "Prior Art" section at the bottom of the page.

http://en.wikipedia.org/wiki/ECMAScript_for_XML

>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.

https://stackoverflow.com/questions/33642820/why-was-e4x-dep...

>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

alvarlagerlof5 anni fa

At least it's pretty much only built up of J's and html instead of something entirely different.

proxyon5 anni fa

JSX is just JS with brackets instead of nested function calls. I expected more from this community than this kind of commentary.

subpixel5 anni fa

I grant that it isn't Javascript and you have to get familiar with it. But at least it's not Hugo templating.

bGl2YW5j5 anni fa

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.

wruza5 anni fa

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.

uallo5 anni fa

> literally just javascript

Repeating it over and over again does not make it true.

https://linkedlist.ch/jsx_is_not_just_javascript_39/

hunterb1235 anni fa

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.

https://github.com/facebook/jsx

DonHopkins5 anni fa

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.

hunterb1235 anni fa

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.

Also you're very rude.

JimDabell5 anni fa

Right from the very top of your source:

> 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?

It is not JavaScript.

hunterb1235 anni fa

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?

JimDabell5 anni fa

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?

hunterb1235 anni fa

I think you're getting a little too worked up.

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.

JimDabell5 anni fa

> 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.

hunterb1235 anni fa

> 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.

JimDabell5 anni fa

> 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.

dmitriid5 anni fa

> 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.

hunterb1235 anni fa

We're not talking about React we're talking about JSX.

Svelte has a lot more going on than it's template language as well.

We're only comparing the templating system to JSX.

dmitriid5 anni fa

Let's compare to JSX then: https://news.ycombinator.com/item?id=29194287

kall5 anni fa

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?

pier255 anni fa

Objectively, the Svelte example is cleaner and easier to read.

diegof795 anni fa

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).

kosolam5 anni fa

Subjectively, I’d say. But since I agree that it’s cleaner and easier to read- I upvote you

spoils195 anni fa

By what metric are you measuring it objectively?

pineconewarrior5 anni fa

density.

epolanski5 anni fa

Saying it is objective but not mentioning the reason really makes your statement subjective.

midrus5 anni fa

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.

ksdnjweusdnkl215 anni fa

Seems like svelte is superior for not needing a key.

s-lambert5 anni fa

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.

[0] https://svelte.dev/tutorial/keyed-each-blocks

[1] https://reactjs.org/docs/lists-and-keys.html

winphone19745 anni fa

The key is used by the shadow Dom for update performance; the is no shadow Dom in svelte

afavour5 anni fa

And yet Svelte is faster than React in pretty much every benchmark I’ve seen.

patrickthebold5 anni fa

That makes sense though right? One would assume that shadow dom and dom would be slower than direct dom manipulation.

thinkloop5 anni fa

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.

ttfkam5 anni fa

Because React's model requires tracking the entire DOM tree for changes and rewriting whole branches where a change is detected.

Svelte bypasses the whole problem for the most part. https://youtu.be/AdNJ3fydeao?t=247

alserio5 anni fa

List diffing is done even in svelte at runtime. Keys are used the same way as any other frameworks or frontend libraries, virtual DOM or reactive.

cphoover5 anni fa

fair criticism I wonder how svelte optimizes for rerendering of long component lists. React uses keys to avoid rerendering the entire list.

Mavvie5 anni fa

I believe you can specify a key in Svelte as well, but perhaps it's used slightly differently than react.

bdougherty5 anni fa

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.

wruza5 anni fa

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.

[deleted]5 anni fa

tflinton5 anni fa

Neither of those are JavaScript..

fron5 anni fa

> 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.

cphoover5 anni fa

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.

rawoke0836005 anni fa

>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..)

So you want all of these to be a universal-template-language - (D)HTML ?

bryans5 anni fa

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.

rawoke0836005 anni fa

100% agree !

rawoke0836005 anni fa

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.

kall5 anni fa

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.

nnoitra5 anni fa

What boilerplate does React have? Do you mean Babel?

cphoover5 anni fa

I know...

This comment had no context...

You don't have to even

    import React from 'react';

anymore

kall5 anni fa

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.

d235 anni fa

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.

locallost5 anni fa

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.

SparkyMcUnicorn5 anni fa

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.

spoils195 anni fa

(6)

ratww5 anni fa

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.

wishinghand5 anni fa

It's a false truth that anyone has to learn yet another one of these. Even Angular 1 and Backbone.js are still in production.

sergiotapia5 anni fa

So is Joomla - yet I wouldn't recommend people learn it today. Might as well learn COBOL and Zend Framework too.

cutler5 anni fa

Ah, Zend - the only framework to out-boilerplate Spring MVC.

DonHopkins5 anni fa

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. ;)

https://en.wikipedia.org/wiki/Dagwood_sandwich

sam0x175 anni fa

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.

rk065 anni fa

The comment is negative and incorrect

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

fendy30025 anni fa

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.

ramesh315 anni fa

> 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.

lowbloodsugar5 anni fa

Didn't downvote either. Almost consider upvoting for visibility of the hilarity displayed.

"There are too many frameworks! Why does everyone keep re-inventing the wheel? Why can't everyone just use the one that I like?"

cphoover5 anni fa

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.

d1sxeyes5 anni fa

You’re right, you don’t have to! Who is forcing you to?

Rich Harris is going to work for Vercel, who are arguably most famous for Next.js, which is… React.

rglover5 anni fa

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).

jessaustin5 anni fa

The parenthetical makes the comment!

rglover5 anni fa

I applaud your sarcasm and award it 10 points.

winphone19745 anni fa

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

tshaddox5 anni fa

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.”

cutler5 anni fa

It sounds like you'd be better off with something like Ruby's Hotwire/Stimulus, ASP.Net Core/Blazor or Elixir/Phoenix Live View.

lhorie5 anni fa

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 :)

[0] https://crank.js.org/blog/introducing-crank

danny_taco5 anni fa

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.

ratww5 anni fa

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.

kall5 anni fa

We moved on. Now there is a new javascript build tool written in a faster language daily (and I love them all).

cutler5 anni fa

I think the pendulum may be swinging back with options like Rails/Hotwire, ASP.Net Core/Blazor and Elixir/Phoenix Live View. Let's hope so.

hijodelsol5 anni fa

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.

kall5 anni fa

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?

Drew_5 anni fa

It does have extra non-native features but the overarching

  <template />
  <script />
  <style />

format for single file components is plain HTML which makes it feel closer to vanilla than React.

kall5 anni fa

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)

Drew_5 anni fa

I like it because it separates layout, styling, and scripting while still collating them in the same file.

gherkinnn5 anni fa

You don't need to know every framework. And that little bit of custom syntax is peanuts compared to how the rest of these differ.

Even if Angular and React shared the same templating syntax, you'd still be left with 95% of work ahead of you.

brundolf5 anni fa

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”

cphoover5 anni fa

100% no more js frankensteins...

Id prefer to learn a new language altogether

[deleted]5 anni fa

joppy5 anni fa

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.

richeyryan5 anni fa

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.

Aeolun5 anni fa

> I don't know how you could implement such a thing (with good ergonomics) without a template language.

Parse Javascript? I don’t see how it would be any different, except you have more constructs to work through.

tshaddox5 anni fa

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.

dbbk5 anni fa

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.

jitix5 anni fa

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.

unclebucknasty5 anni fa

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.

kall5 anni fa

What would that look like for you? Something like SwiftUI or Flutter (which feel React inspired) or a totally different thing?

unclebucknasty5 anni fa

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.

kall5 anni fa

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.

cphoover5 anni fa

perhaps you are right about DOM but isn't HTML/XML just a way of representing an object tree... I don't see anything inherently wrong with this?

unclebucknasty5 anni fa

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.

adamnemecek5 anni fa

The templating language is the easiest thing to learn. The hardest is architecture.

midrus5 anni fa

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).

miohtama5 anni fa

Because if we do not keep constantly learning and get better, we would be stuck writing COBOL and BASIC.

cphoover5 anni fa

haha fair enough!

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.

gaws5 anni fa

You're getting flamed on Twitter for this comment lol: https://twitter.com/dancow/status/1458906853488967684

bryans5 anni fa

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.

rglover5 anni fa

You'd like https://github.com/cheatcode/joystick.

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.

tootie5 anni fa

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.

cphoover5 anni fa

Very true... How can I debug this thing when it breaks that's a great question. I wonder how sourcemaps work with svelte

chrbp5 anni fa

No one says you have to learn new languages or frameworks. It's really your own choice.

Tarks5 anni fa

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"

timeon5 anni fa

And then you have ended up with shadow DOM.

intrasight5 anni fa

They are all just trying to replicate XSLT - but by mixing imperative with declarative syntaxes.

[deleted]5 anni fa

block_dagger5 anni fa

This is why I have focused on backend for the last decade.

travisl125 anni fa

My solution is pretty easy to this problem: I don't.

[deleted]5 anni fa

tpict5 anni fa

JSX is syntactic sugar for `React.createElement(...)` (most commonly), so React pretty much is plain JavaScript.

kall5 anni fa

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.

midrus5 anni fa

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.

burlesona5 anni fa

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.

midrus5 anni fa

Yeah, I really like the middle ground approach, but having tried almost everything in the category, my favourite by a long margin is Unpoly.

solarmist5 anni fa

What bits were misdirected? What worries did you have?

midrus5 anni fa

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.

chrbp5 anni fa

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.

midrus5 anni fa

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.

solarmist5 anni fa

Oh, okay. Thank you for the explanation.

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.

ravenstine5 anni fa

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.

cobertos5 anni fa

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.

ravenstine5 anni fa

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.

https://github.com/emberjs/ember-render-modifiers

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:

https://github.com/emberjs/rfcs/pull/567

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.

/rant

sxiao5 anni fa

This is so HN, in an Svelte thread memories from Ember (sharing your sentiments though).

ravenstine5 anni fa

HAHAHA

I try not to go full HN, but sometimes you do.

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.

sxiao5 anni fa

Yeah, Svelte is pure gold.

sxiao5 anni fa

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)?

afavour5 anni fa

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.

sxiao5 anni fa

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.

DonHopkins5 anni fa

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.

https://en.wikipedia.org/wiki/Zope

https://en.wikipedia.org/wiki/Guido_van_Rossum#Work

>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!

afavour5 anni fa

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.

sxiao5 anni fa

Good point and I agree about Rich but I rather trust healthy markets and competition more than people.

DonHopkins5 anni fa

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?

ahevia5 anni fa

Wouldn't Vercel benefit from being the defacto platform to deploy Next & SvelteKit apps?

sxiao5 anni fa

(3)

[deleted]5 anni fa

brightball5 anni fa

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?

dceddia5 anni fa

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.

leerob5 anni fa

What could be improved in the documentation?

gavinray5 anni fa

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.

Svelte doesn't support JSX/TSX though =(

leerob5 anni fa

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!

gavinray5 anni fa

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).

_benj5 anni fa

Glad to see you here Lee!

> 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! :)

leerob5 anni fa

https://news.ycombinator.com/item?id=29192174

byhemechi5 anni fa

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.

sxiao5 anni fa

> The governance of Svelte isn't changing

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?

Rauchg5 anni fa

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.

pier255 anni fa

> Svelte doesn't support JSX/TSX though =(

It actually supports the next best thing: HTML!

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.

DonHopkins5 anni fa

Plus JSX is based on a "Virtual DOM", and "Virtual DOM is Pure Overhead":

https://svelte.dev/blog/virtual-dom-is-pure-overhead

>Virtual DOM is pure overhead

>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.

pier255 anni fa

> Plus JSX is based on a "Virtual DOM", and "Virtual DOM is Pure Overhead":

If you mean React + JSX then yeah, but JSX is just a DSL and doesn't imply using a virtual DOM.

For example, Solid js uses JSX and doesn't have a virtual DOM.

https://www.solidjs.com/

rawoke0836005 anni fa

>It actually supports the next best thing: HTML!

Haha - Oh where will our crazy tech take us next :D

systemvoltage5 anni fa

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.

dexwiz5 anni fa

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.

The5thElephant5 anni fa

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.

miguel-muniz5 anni fa

> 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

systemvoltage5 anni fa

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.

gavinray5 anni fa

  > "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.

radus5 anni fa

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/

hamilton5 anni fa

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.

dceddia5 anni fa

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.

Right click > View Page Source, and scroll to the bottom to see how all the Svelte components are mounted: https://daveceddia.com/linked-lists-javascript/

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).

miguel-muniz5 anni fa

Do the designers you work with have experience with front-end development, or have access to your design system in their design tools?

It sounds like an issue that can be resolved with some communication

GordonS5 anni fa

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.

romero-jk5 anni fa

You can "sprinkle" react too

systemvoltage5 anni fa

Not as well as Vue.

Vue is just straight forward exactly like jQuery: https://www.smashingmagazine.com/2018/02/jquery-vue-javascri...

lioeters5 anni fa

Yup: https://reactjs.org/docs/add-react-to-a-website.html

Keats5 anni fa

> Svelte doesn't support JSX/TSX though =(

You have https://www.solidjs.com/ that does

gavinray5 anni fa

Solid is really cool, and I love the posts by it's author describing the journey to performance that is some years old now.

But what is unique about Vue is that it lets you arbitrarily mix ".vue" and ".jsx/.tsx" files in the same project.

So if you need to define say 50 really tiny helper components, like "Button", "Modal", etc. it's great.

I can write one TSX file and do:

   // UtilComponents.tsx
   export function Button() {}
   export function Modal() {}
   export function Icon() {}

And then in my .vue file I can do:

   <script setup lang="ts">
   import { Button, Modal, Icon } from "./UtilComponents"
   // ...
   </script>

This is not a popular approach, almost nobody uses Vue's JSX/TSX and I'm not sure if people even know you can mix and match arbitrarily like this.

But I've been doing this for a long time and it works great for me haha.

richeyryan5 anni fa

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

protonimitate5 anni fa

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.

nicoburns5 anni fa

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.

alserio5 anni fa

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

swyx5 anni fa

it is. HTML is the first language of the web, not JS - this is why framework agnostic libraries are so much easier to use with Svelte than with React.

pjungwir5 anni fa

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.

ravenstine5 anni fa

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.

rglover5 anni fa

Check out what I'm working on. I'm staying indie indefinitely: https://github.com/cheatcode/joystick.

No JSX or other templating languages, just plain HTML.

[deleted]5 anni fa

_benj5 anni fa

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!

solarmist5 anni fa

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.

midrus5 anni fa

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.

_benj5 anni fa

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.

But, that's just me

unknownOrigin5 anni fa

> 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.

falafelite5 anni fa

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.

dang5 anni fa

We changed the url from https://vercel.com/blog/vercel-welcomes-rich-harris-creator-... to Rich's own post.

There were two other submissions - one to an interview (Svelte Creator Rich Harris: Web development should be more fun - https://news.ycombinator.com/item?id=29189209) and the other to this Twitter link (https://news.ycombinator.com/item?id=29189467). I've merged those threads into the current submission because it was posted first.

pier255 anni fa

Thanks dang! This was the right move.

leerob5 anni fa

Agreed, thank you so much.

owlbynight5 anni fa

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.

_puk5 anni fa

This is absolutely fantastic news!

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.

DonHopkins5 anni fa

Rich Harris Coined the Term “FauxSS”: Fake OSS!

Svelte Summit Spring 2021: Rich Harris @6:07:00 (link with timecode):

https://www.youtube.com/watch?v=fnr9XWvjJHw&t=22020s

>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. ;)

DonHopkins5 anni fa

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.

slantyyz5 anni fa

My favorite feature of Sveltekit is probably the server-side endpoints. It's so easy to create an API using them.

barelysapient5 anni fa

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.

arberx5 anni fa

Svelte is fucking awesome.

Long way to go to catch up to React, but it'll get there. No brainer.

Donckele5 anni fa

Yes, it is good. In many ways I hope it doesn’t catch up to React - it’s running a different journey which I also prefer.

arberx5 anni fa

Catch up in terms of hirability/company usage.

smt885 anni fa

Yeah, I stupidly started some projects with SvelteKit instead of NextJS and am having a very hard time finding people to work on them.

_fat_santa5 anni fa

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.

[deleted]5 anni fa

lucasyvas5 anni fa

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.

smt885 anni fa

This is what I've done, but it's still hard to find someone who will do things in idiomatic Svelte.

lucasyvas5 anni fa

FractalHQ5 anni fa

Have you made a post on the Svelte discord #jobs channel? All job postings that go up there get gobbled up pretty quickly.

pier255 anni fa

Woah as a Svelte user I'm super happy and this is going to change everything.

I can only speculate as to the reasons behind this decision by Vercel. Why Svelte and not Preact for example?

In any case, congrats Rich!

leerob5 anni fa

We love Svelte and are super excited to help it grow. IMO it's fun, easy to learn, and is fresh take on modern web development.

More here: https://vercel.com/blog/vercel-welcomes-rich-harris-creator-...

WORMS_EAT_WORMS5 anni fa

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).

blackandsqueaky5 anni fa

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

Rauchg5 anni fa

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!

[1] https://news.ycombinator.com/item?id=29003089

[2] https://news.ycombinator.com/item?id=29158742

[3] https://twitter.com/swyx/status/1456665048949018626

kadomony5 anni fa

Hey Guillermo,

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.

Rauchg5 anni fa

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

[1] https://rauchg.com/2021/making-the-web-faster#realtime

rce5 anni fa

SvelteKit has an out-of-the-box adapter for Cloudflare workers: https://github.com/sveltejs/kit/tree/master/packages/adapter...

WORMS_EAT_WORMS5 anni fa

This is kind of exactly my point in not owning the full stack with Serverless.

I'd be a bit nervous right now if I built my business / app on that.

mwcampbell5 anni fa

I hope that Rich joining Vercel doesn't end up compromising SvelteKit's current neutrality when it comes to deployment targets.

benmccann5 anni fa

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 ;-)

ksubedi5 anni fa

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.

WORMS_EAT_WORMS5 anni fa

This is not Cloudflare:

> Flareact is an experiment created by Josh Larson in August 2020.

ksubedi5 anni fa

You are right. Sounds like they need to sponsor him!

kall5 anni fa

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.

systemvoltage5 anni fa

I predict that Cloudflare will acquire Vercel one day.

WORMS_EAT_WORMS5 anni fa

I think an executive has commented before that is not going to happen. Things can change though.

If I were Vercel, absolutely would not sell either. They aren't like "Netlify" and positioned to be truly the goat of serverless.

skrebbel5 anni fa

> They aren't like "Netlify"

What do you mean by this?

admn25 anni fa

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.

deltron30305 anni fa

The 25mb limit in folder size isn't enough for mid-sized blog though, even if you host the images somewhere else.

friedman235 anni fa

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.

leerob5 anni fa

Vercel's infrastructure is multi-cloud, primarily using AWS. We're currently using Workers specifically for Edge Functions (https://vercel.com/edge).

sva_5 anni fa

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).

leerob5 anni fa

Thanks for the feedback, we'll improve this!

rabaut5 anni fa

Do you have a reference for this? Curious to learn more. I thought Vercel was built on AWS.

[deleted]5 anni fa

lmeyerov5 anni fa

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

andrew_5 anni fa

Denoflare (https://news.ycombinator.com/item?id=29142772) is compelling.

johanndev5 anni fa

Do you have experience with denoflare? I really would like to try it, but I can't even get the basic `hello-worker` sample working, see https://github.com/skymethod/denoflare/issues/2

johnspurlock5 anni fa

Hi there, denoflare is still in early development, thanks for trying it out - that issue you found should be fixed in the latest release 0.3.1

WORMS_EAT_WORMS5 anni fa

Also not Cloudflare (to my knowledge)

johnspurlock5 anni fa

Correct - no affiliation, just a happy customer.

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

Donckele5 anni fa

Great news for everyone using Svelte - a good move by Vercel and wish Rich gets more resources and freedom to continue the refinement of Svelte.

bl4ckm0r35 anni fa

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!

Glench5 anni fa

Awesome. Been using Svelte exclusively for a couple years in my projects and don't see myself using React ever again.

kosolam5 anni fa

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

xrd5 anni fa

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.

yumraj5 anni fa

Can someone explain what Vercel does.

I'm familiar with Svelte, but interestingly not with Vercel. A scan of their website wasn't completely clear, but that is probably just me.

Edit: thanks to all who answered, very helpful.

leerob5 anni fa

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.

ronvoluted5 anni fa

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 :)

leerob5 anni fa

We'll likely be hiring more DevRel folks focused on Svelte in the future! We have one currently (Steph) and she's great :)

ronvoluted5 anni fa

That's awesome and yeah Steph sounded great from your podcast chat! Thanks Lee :)

inglor5 anni fa

They are a competitor with other clouds like AWS/Azure/GCP/DigitalOcean with a focus on JAMStack and modern workflows.

dbbk5 anni fa

More like a competitor to Netlify, GitHub Pages, etc

_fat_santa5 anni fa

Vercel is a hosting provider for static websites. I see it as a simplified versions of AWS, specifically for static websites.

ryanSrich5 anni fa

Used to be called Now. It’s a PaaS.

whiddershins5 anni fa

We have used Svelte for a major internal project and it has been an absolute joy to work with.

This is really exciting news.

crummy5 anni fa

I have a stupid question:

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?

swyx5 anni fa

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

travisd5 anni fa

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).

alserio5 anni fa

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

rk065 anni fa

The ones based on next.js are pretty fast. but yeah vanilla react apps tend to be on slower end

samc985 anni fa

The React team had explorations of a compiler for React, I believe -

https://github.com/facebook/react/issues/9223 https://github.com/facebook/react/issues/7323 https://github.com/facebook/react/issues/7324

I also think this is why facebook had been investing in `prepack` - https://github.com/facebook/prepack

travisd5 anni fa

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.

fuzzy25 anni fa

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.

dbbk5 anni fa

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.

cphoover5 anni fa

[deleted]

didip5 anni fa

Can someone teach me how Svelte does what it does? The front page is not telling me much?

How does it "surgically" update the DOM? Why is it better than virtual DOM?

jitl5 anni fa

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:

    const MyComponent = {
      mount(parent) {
        const element = document.createElement('div')
        div.innerHTML = "Here's <b>bold text</b>"
        parent.appendChild(div)
      },
      update() { /* no-op */ }
    }

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.

tuan5 anni fa

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.

bdougherty5 anni fa

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

jgalentine0075 anni fa

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.

rglover5 anni fa

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).

bdougherty5 anni fa

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.

https://svelte.dev/repl/7161f10f8eb645d8984fb231a0bc3982?ver...

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.

rglover5 anni fa

This is a cool approach, thank you for sharing that link.

ummonk5 anni fa

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?

whiddershins5 anni fa

Svelte's main differences include being compiled, and being truly reactive.

timeon5 anni fa

And how about shadow DOM?

ummonk5 anni fa

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.

bdougherty5 anni fa

Yep, at least it is for me.

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.

sxiao5 anni fa

Am I the only one?

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.

rich_harris5 anni fa

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.

sxiao5 anni fa

sanitycheck5 anni fa

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.

dang5 anni fa

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.

https://news.ycombinator.com/newsguidelines.html

sxiao5 anni fa

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?

dang5 anni fa

This is the part I meant:

> 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.

Of course I'm not banning you, just trying to persuade you to post more in the spirit of the site! But please stop taking the thread further in this off-topic and personal direction - https://news.ycombinator.com/item?id=29192231 and https://news.ycombinator.com/item?id=29191992 are definitely not helping.

sxiao5 anni fa

@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!

afavour5 anni fa

> 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.

sxiao5 anni fa

swyx5 anni fa

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.

tnolet5 anni fa

Exactly. I think the OP does not know what it means to "raise money" and go at it. It would turn that person into a full time business owner.

exhaze5 anni fa

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 :)

6gvONxR4sf7o5 anni fa

This is all that’s wrong with open source free software. You’re disappointed by how someone chooses to give you free stuff.

rglover5 anni fa

I built this to avoid this exact problem: https://github.com/cheatcode/joystick.

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: [email protected].

waterglassFull5 anni fa

Feel free to make your own alternative, the world's your oyster.

mixmastamyk5 anni fa

The framework appears to have an MIT license and lots of contributors so I wouldn't worry too much.

mdoms5 anni fa

(1)

PaulBGD_5 anni fa

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.

throwawayjklalf5 anni fa

svelte + deno should be the perfect combination for the next age of web development.

ergo145 anni fa

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.

uzername5 anni fa

Is this a bet against React or a bet for ecosystem variety and choice? I feel it's the latter right now.

hunterb1235 anni fa

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.

dexwiz5 anni fa

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.

hunterb1235 anni fa

> 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.

BackBlast5 anni fa

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.

hunterb1235 anni fa

> The debugging platform used a different interpreter than in app

What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.

> Odd bugs at boundary layers nobody could (easily) decipher.

I'm not sure I understand, could you provide an example?

> The inability to even catch or do anything with some crashes.

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.

BackBlast5 anni fa

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.

Jcampuzano25 anni fa

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.

penjelly5 anni fa

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?

throwaway17775 anni fa

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.

hunterb1235 anni fa

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.

Just wanted to clear that up.

penjelly5 anni fa

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...)

ativzzz5 anni fa

It's probably because they had a team of experienced iOS/Android engineers, who are significantly more productive in their respective platforms.

leerob5 anni fa

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.

dexwiz5 anni fa

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.

[deleted]5 anni fa

penjelly5 anni fa

react is used so many places professionally that i think someone would just fork or remake react from scratch if they ever did that.

dexwiz5 anni fa

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.

[deleted]5 anni fa

joshgrib5 anni fa

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!

bartq5 anni fa

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.

solarmist5 anni fa

So I'm a backend engineering, but have experience with Vue.js and like it.

Why would I want to rethink that and try out Svelte?

Reading about svelte the main advantage seems to be everything building to raw JS making it faster.

Questions:

Is there typescript support? I would assume, but...

Does this end up with smaller bundles/js files?

Any other major advantages?

From some reading syntax seems pretty similar to Vue as well.

yroc925 anni fa

There is typescript support.

aarpmcgee5 anni fa

The TS ergonomics still have a long way to go, imo. Typing components is a little bizarre -https://github.com/sveltejs/language-tools/issues/442

yroc925 anni fa

Agreed. It's not perfect and can be buggy.

tropix1265 anni fa

1. Yes there is typescript support.

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.

solarmist5 anni fa

> They take full advantage of Svelte being...

They? Libraries?

tropix1265 anni fa

The Svelte core team. All of the features I mentioned are included in the framework without the need of external libs.

[deleted]5 anni fa

ithkuil5 anni fa

I heard about vercel before but this announcement made me try it out.

Oh boy, what an amazing onboarding experience!

seanstrom5 anni fa

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.

stevenpetryk5 anni fa

Vercel's increasing control over the frontend ecosystem worries me a lot.

rglover5 anni fa

There's hope: https://github.com/cheatcode/joystick.

gherkinnn5 anni fa

Interesting. Vercel already hired both the main Webpack and SWC devs.

solarmist5 anni fa

Any Svelte UI component libraries with good i18n and a11y support?

tropix1265 anni fa

Carbon and SMUI are both good.

d1sxeyes5 anni fa

Not Svelte specific but daisyUI is pretty nice. It’s just Tailwind though, so any i18n and a11y are up to you to implement.

[deleted]5 anni fa

sngz5 anni fa

great news. as someone that really dislikes react but is forced to work with it I hope someday I'll be able to use svelte on my project.

arendtio5 anni fa

First time I took a few more minutes to look into svelte. To me it looks like it could be successor of Vue.

Do you know of other high potential candidates?

penjelly5 anni fa

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

midrus5 anni fa

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.

penjelly5 anni fa

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.

HeavyStorm5 anni fa

Excellent news, I love svelte and this could increase adoption

Graffur5 anni fa

Because of redwoodjs, I've gone off Svelte a bit

chovybizzass5 anni fa

fidesomnes5 anni fa

PostThisTooFast5 anni fa

kaddywampus5 anni fa

toastercat5 anni fa

This is awesome. Next.js is garbage so hopefully SvelteKit gets all the love and attention from now on.

_fat_santa5 anni fa

My biggest issue with NextJS is next/image vendor locks you into Vercel.

bradleyg_5 anni fa

You can use netlify-plugin-nextjs - https://github.com/netlify/netlify-plugin-nextjs/blob/v3/doc... to host on Netlify.

And of course any regular NodeJS server works with next/image - https://nextjs.org/docs/deployment#other-hosting-options

leerob5 anni fa

`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!

https://nextjs.org/docs/basic-features/image-optimization#lo...

brailsafe5 anni fa

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.

MisterBastahrd5 anni fa

It'd be more fun if I could do it in something that wasn't in Javascript or one of its Frankenstein cousins.

tempest_5 anni fa

You can!

Elm is interesting, though it's developer is a bit polarizing

Also there are a host of nascent Rust/WASM frameworks starting to pop up. They really like the tree puns. There is Yew, Sycamore and Seed.

tormeh5 anni fa

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.

cutler5 anni fa

Don't forget Clojurescript.

clivestaples5 anni fa

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.

slantyyz5 anni fa

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.

jhgb5 anni fa

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.

rglover5 anni fa

JavaScript-based but plain HTML/CSS/JS. No Mary Shelley: https://github.com/cheatcode/joystick

aogaili5 anni fa

Personally I have mixed feeling about this.

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 :)

aogaili5 anni fa

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.