I got introduced to Rich Harris via a podcast (not personally), but am a big fan of his perspective on JS. I think we can all agree that; if you don't like Svelte, then fine. If you love JSX/TSX - then great! If you're a Vue person, then awesome - its exactly what makes this community great - the diversity & innovation. Not the soap-boxing antics, polarised opinions & vilification of opinions that aren't congruent with your own.
As someone much wiser than me once said - "always bet on Javascript".
Totally agreed that the diversity of technical innovation is how we got here and its fantastic. Hopefully we keep up with more innovations (such as npm alternatives :cough:).
Its easy to see why some folks would get riled up over this crap though. Like, if you don't like React right now, but want to do frontend development professionally, your job prospects get slashed in half or more. Really like Vue? That's awesome! But you might have a small fraction of the options your peers do when interviewing. Like a more exotic solution like Svelte or Elm? Hope you like working remote or are okay with relocating for that, because there's probably not that many places to work at in your area.
So people will try really hard to get the community to rally around their favorite choices. And the tools without cheerleader squads often fade away and die. Rock and a hard place.
I've been keeping all the modern javascript frameworks at arms distance, because I've always preferred to bet on HTML, for the client at least. That said, I've no issues with heavy reliance on JS on the developer machine, but I always prefer pages that can work without the reliance on JS.
So, it seems opportune to ask: Is there a JS framework around that actually compiles to HTML and CSS rather than embedding the HTML in JS/DOM calls? In my rudimentary analysis of React/Vue and others (eg svelte), I can't find out how to have the end result without the framework sitting in there too. Perhaps I keep missing something in my understanding?
It can't 'compile' to HTML, because it doesn't know at compile time what data you're going to give the component. Instead, if you compile with `ssr: true`, the JavaScript it generates is a module that generates HTML through efficient string concatenation. It's very easy to bake out static files as part of a build step, or generate markup dynamically as part of a Node server.
CSS is extracted at build time; typically your styles will be served as static .css files for maximum efficiency.
Some client-side libraries can also perform server-side rendering, giving them the label isomorphic. Most such are ones that use a VDOM, which makes it easy to do (though it becomes a bit harder again if you worry about rehydration, which is strictly optional but normally desirable, so that you can still add things like event handlers on the client side). Svelte is one that does it more efficiently, compiling to a different result: fiddle in its playground and look at what it compiles to depending on whether you ask for the dom target or the ssr (server-side rendering) target.
So this is what Svelte does, the app gets built at build time so you don't need the include any script in the browser for it to run. I remember RH talking about the React Hooks inspiration thing, so whether the API will go more in that direction (and eventually be a runtime thing), I'm not too sure.
I had a similar experience. I wish Ractive would have gained more traction; it was a good balance of "enough functionality that a web UI requires" and "simple enough to avoid cognitive overload and allowed for quick ramp up".
I like playing with different web frameworks, but the article had a bad hype:information ratio, so I googled the Svelte homepage, which I think is really well presented: https://svelte.dev/
The site is hosted on Google Cloud Run, which seems to have been having some intermittent problems for the last couple of days. EDIT: some other people have had the same issue and the Cloud Run team are investigating
Yep — I added our details to it. I mentioned the problems we were having on Twitter and a Cloud Run PM came to help immediately! So I'm hopeful we'll get a resolution before long. (Aside from this glitch, Cloud Run has been great for us, and we're looking forward to it coming out of beta)
Yeah - I wrote https://www.beyonk.com in Nuxt first, and I've now rewritten it in Svelte (Sapper).
There are some things which weren't ready when I started, but I worked around them. The overall experience is that Svelte results in faster pages, less code, more predictability, faster builds... overall, it's a better experience.
Nice. I like the SSR and that subsequent page loads are basically just a 5KB fetch of pure content in JSON.
But if I go to a content page (eg. https://www.beyonk.com/uk/6Gb_Kj/guided-ascent-of-curved-rid...), I see that the response is a 286KB blob, mostly consisting of CSS. If I reload the page, I redownload that 286KB blob. Wouldn't it be better to serve the CSS separately so it can be cached across sessions?
The idea behind svelte is neat, i wonder though what the impact of its approach will be on a developers ability to understand what is happening under the hood. In my experience opaque abstraction layers can really hamper your ability to properly understand what is going on. Traditionally the JS ecosystem has been a frontrunner in this area (e.g. sourcemaps). But I have had terrible experiences in the Java ecosystem, with all its aspect weaving and annotation magic.
I think it's the reverse. If you write pure functional components, React is very understandable. It's easily testable, you know that you'll have the same output if you pass it the same props. Svelte templates just take us back where we've been, with the twist of compiling the templates, which I believe some templating libraries already did.
You can dive down and learn the inner workings, the same as you can dive down and learn how the svelte compiler works, but it's not needed for either one. Understanding the concept is more important.
I'm a huge React fanboy, but if you try and step through the React code with a debugger, we're kind of a far cry from the days of Backbone and even Angular. For the common mortal, it has to be treated as a black box. Fortunately, its fairly stable, so it's rare you have to care, but...
Yeah, the ability to step into Backbone code and back out of it into my own code was one of the things I liked about Backbone.
That said, React's mental model is so powerful that I've almost never needed to actually debug into it to see what's going on. If you've got an issue, tracing the dataflow in your own code is generally sufficient. So, I'm okay treating it as a black box.
I have a table of 100 rows x 10 columns mostly of numbers which change 10 times a second (think trading).
The source data sits in an array of objects.
On each update, I need to update the table cells with the latest values from the source array. The content of each cell can change, possibly it's css class too (from red it become blue for example).
I'm using Vue/Bootstrap-Vue table at the moment, but it's quite slow.
Is Svelte suitable for this? Other options to quickly update a <table> from data in an array of objects, one object per row?
It looks like svelte.dev and the REPL are up and running again, so here's a quick example of a 100x10 table updating every value 100 times per second, with a red/blue class being applied to each cell depending on its value.
It seems to do pretty well! I turned on the FPS meter in Chrome and scrolled around a bunch, and it seems smooth, reporting around ~50fps. It did get my CPU going pretty good, though.
works now, works well for me also, good FPS. looks pretty smooth also.
I would say his next problem is going to be getting the data fast enough to feed the the UI, a nicely packed websocket protocol would work well I'd guess
No matter which framework you describe, this is an iterative approach and will be inefficient. The optimized (or, at least faster) way to handle this would be to have a unique ID attached to a cell and offer a direct callback to it via the data.
E.g. the symbol for "GOOG" stored in a hash table, when GOOG updates; call that hash directly: "symbols[symbol].update(data)" then re-render the cell DOM element.
Svelte keeps a direct reference to DOM elements and mutates them when possible, if you do it right you can probably achieve vanilla-levels of performance.
For a realtime view of stock symbols, it's highly likely they will change. And a hashmap lookup is not free.
You really have to profile the code to figure out what's expensive. Maybe there is no scaling wrt. the number of nodes that change because repainting/relayouting is more expensive than updating the DOM.
They are basically free when you have this little data. 1k cells updates 10 times a second means that you have around 100 micro seconds per cell, you can do thousands of lookups in that time. The only things which could even come close to costing 100 micro seconds are if you accidentally re-flow the html each cell update, re-render the html each cell update, send a http request each cell update or if you go through all the data each cell or the framework you are using is extremely inefficient or other unnecessary work. Each of those are easily fixable by doing the html and javascript by hand instead of using frameworks.
At 10 times a second you might be hitting the browser’s table layout algorithm speed limits. I assume you’ve given it table-layout: fixed, and fixed-width columns?
It would certainly reduce it. With table-layout:fixed, the default behaviour is that every cell is the same width as the others. With the normal table layout algorithm it’ll attempt to rebalance as every new cell’s content is added. That makes for a very flexible layout that automatically scales to best fit the content, but have to flush and redo the layout for the whole table every time a column width is calculated to need to change.
It doesn’t even have to be a problem like that to be a performance problem. For example, imagine a five row table where the last column always has 1 digit in the first row, 2 in the second, 3 in the third etc. When rendering (without table-layout:fixed) the browser will check the last cell, see one digit, and size that column appropriately. It’ll then carry on rendering the second row, see two digits, then work out the new size for the column and rerender the entire table. Repeat for rows three, four and five.
Not a problem for a single layout pass, but a performance problem if the data changes every frame.
Good rec! Perspective was purpose built for this precise use case at JPMC, and has some unique features such as streaming Apache Arrow support, which can pretty easily handle datasets in the low millions of rows, at thousands of updates/second.
Exactly. Stuff like this is extremely simple to write in vanilla js, with a pointer to each of the dom objects you need to interact with. There's no point in using a framework (but of course you can encapsulate your vanilla js in a component to interface with whatever framework you're using).
Isn't the benefit of React/Vue the shadowDOM and not needing to do full page prints with every change? Honest question, I'm just going off what I hear everyone else saying so the vanilla JS, while the code may be more efficient, sounds less efficient since you'll need to re-print the entire page with every change.
> sounds less efficient since you'll need to re-print the entire page with every change.
Huh? No, not at all. As far as I understand, React has algorithms that replace only the html that changed in a dom subtree (and that is called virtual dom, not shadow dom, which is a different concept).
But if you already know exactly what has changed and where to change it in the page, there is no need for more complex algorithms to kick in. Just take the pointer to your div or cell and change the content.
Bottom line: React is written in vanilla Javascript. Can't do better than it.
> React is using Virtual DOM, which is not free. It is fast, but it is not free.
Of course, that's what I meant- maybe it wasn't clear. React can't be faster than vanilla js, it's written in vanilla js after all.
The whole virtual dom's purpose is to calculate the smallest possible update when you don't know (and don't care) what exactly has changed in your view. But that calculation of course has a cost. And if you know very well what changed and where, like in the case of the GP, nothing can be faster than changing it directly.
I am surprised how many people I interview say the same thing - pure JS has to re-render the page and React doesn't, including people who have a lot of JS experience.
Changing the DOM doesn't cause a full re-render, the browser will optimize the repaints to only the parts that have changed.
People don't understand how the DOM works, and its become a great way to filter out people.
"People don't understand how the DOM works" x 1000. Many front end devs I have worked with are not aware that the DOM IS A TREE (and implications of this)!
100 rows x 10 columns is about 1000 elements minimum. HN has an obsession towards the fastest js framework but most of the time its not the JS where the most time is spent, it's the render->paint cycle of the browser.
I bet if those 100 rows aren't even in the viewport you can get a big perf boost by only rendering a subset and rendering more when the user scrolls.
We've gotten ~30x boost on our tables with 100s of rows by using a progressive rendering algorithm.
virtualdom - preact/react/vue/snabbdom e.t.c is usually fast for most things. you can diff about a million things under a 10ms timeframe. Rendering a million things is an entirely different ballgame.
That's what we did too with Vue table library, made our own sorting algorithm and showed the first 100 results async and continued with rest of results in background until user cancels or changes sorting entirely
Just out of interest, what's the reason you need to update the values of the cells 10x per second? I get that that's the frequency the data is updating (maybe even faster) but is it useful for a person to see the data updating at that frequency?
Let's say you slowed it down to 1x per second, you'd increase max possible latency of an updated value being displayed by ~900ms - is that enough time to be important in your application?
Clicking on table cell initiates/closes trades. Even if you can't react in 100ms, is useful to see how fast they change (how volatile the market is). 1s is definitely too slow.
This is also a very good use case to actually dive under the abstraction a little and use hooks or lifecycle methods to directly manipulate the table.
You still gain a lot of benefits from your component framework this way (composability, life cycle management, easy interop with the rest of the app). It’s more work that you wouldn’t want to do all the time, of course.
You probably can implement a more efficient diffing algorithm than the general one for vue. When new data comes in, patch the objects that have changed without overwriting the whole array.
No framework can fully eliminate the underlying performance sinkhole that is the DOM. If you have to mutate, you will pay the price, period. The smartest framework can only help you eliminate redundant mutations.
So I just read about "Choosing Boring Technology" before coming into this thread. I guess React.js is the boring technology (already 5-6 years) one and Svelte is the new and exiting one! :)
It'll be gone in 5 years. It's getting too big and too slow. Also, the react team managed to add hooks and useEffect in a way that makes it very easy to accidentally send your app into an infinite loop and not know why.
> It'll be gone in 5 years. It's getting too big and too slow
Funny, that's what everyone said 5 years ago. I'll bet on React to be here for another decade, no problem - there's just way too much momentum. In a way, it's Rails all over again (that's a positive).
Rails burned out in under 10 years. The reason I say React will be gone in another 5 years is because it's already been popular for 5 and the muttering has started. Do you remember Adobe Flex? React is following a shockingly similar path and timeline.
It may not be the glory days, but Rail's is still going strong 13 years later. React, however, has reached a popularity many times larger than RoR ever did.
There has never been a project (I can think of), other than the Linux kernel, with the resources that companies and developers have put behind React.
> Do you remember Adobe Flex
Flex never came close to either RoR or React popularity, and was propelled mostly by the dying wave of ActionScript programmers from the aughts after cell phones killed the Flash game market.
So is Flex[0]. What's your point? It's not popular anymore and hundreds if not thousands of code bases are being converted from both of these technologies into something else.
I'm not sure this chart is very good evidence of this claim. There are so many other things named "react" -- Nike React shoes, Kids React videos, reactionary politics, and so on -- that it's a bit like claiming Trump.js is the most popular JavaScript library in the world because of this chart: https://trends.google.com/trends/explore?date=all&geo=US&q=r...
Hooks definitely need to be deeply learned, and has one of the steeper learning curves in React. But at its core, its solving a hard problem (lifecycle side-effects), in a way that is more functional, and produces more maintainable code. Thats a fair trade-off imho. And honestly, once you understand them, the infinite loops are deterministic and understandable.
If you want a component-based view library that is written in js, and you are happy to take on the task of assembling a build-system, styling system, routing and of course state-management, I can't see much of an architectural improvement you could make over React.
If you want batteries included - go with Vue.
If you want the Ruby/spring opinion and batteries included go with Ember.
Svelte looks kinda cool. But it seems to sit deep in the browser spec, and in my NAIVE opinion, it doesn't seem hold the component abstraction as something even valuable. It just wants you to script away. Which, is just movement within a trade-off space - if it suits you go for it.
The component abstraction is primary with Svelte. Each file is a component and only one component. This means the only ceremony you need to create a component is to create a new file. It's a perfect solution in my opinion.
I went through the svelte examples and I was exited until I reached the If block example:
{#if user.loggedIn}
<button on:click={toggle}>
Log out
</button>
{/if}
To me such template language is a huge step back from JSX. JSX is JavaScript, thus you get the full power of the language (JS/TS) with the full support from your editor (type checking, auto-completion, etc.).
I hate template languages myself. But in Svelte’s defence, their template language in version 3 seems to be well-designed and streamlined.
It doesn’t have the ad-hoc nature of “oh crap we forgot to add if-then-else” of Angular or “let’s create half-a-dozen incompatible javascript-like DSLs” of Vue.
My daytime job isn't primarily programming anymore, and frontend development has never even been my job. I used to do embedded and backend development, and am now in more of a ops/architect/automation consultant (freelance). I still need to code on a regular basis, and Go and Python are my go-to languages these days.
On a regular basis, I encounter the need for a GUI for some API or backend I write, so I tried to get into a more modern Javascript eco system. I have created websites and even full-on forum software in a long forgotten past, so I have some basic old-school webdev and basic Javascript knowledge (from back when directly manipulating the DOM was still the way to go). So take this as a bit of an outsider look on things, who is confronted with full-time Javascript developers on a daily basis.
When I started looking into react, vue, ... it always overwhelmed me. Whatever I started doing, according to someone, it's bad practice and should just do Y instead of X. Nobody seems to agree on best practices, and there seems to be a whole lot of 'magic' going on in all those frameworks, and knowing where to start is an absolute mess. It's confusing as hell.
Now I quickly went through the tutorial and examples on the Svelte site and it felt pretty simple, I can reason with how it works behind the scenes, and can read the generated Javascript to verify that that's really what's going on. It makes the whole thing seem more manageable in my head.
As far as "the new exciting one" goes - what appeals most to me personally is its simplicity. One of the reasons Go also appealed to me. It was exciting for a while, but ended up being the boring 'it just works' solution which completely replaced C and C++ in my life (that's not a jab at these languages, they have their uses, I just don't need them anymore)
Agreed, JSX/TSX feels so incredibly natural it's hard to imagine giving it up, and starting a significant JS project in 2019 or 2020 without using TypeScript would feel professionally negligent to me.
You don't have to. The beauty of it being a simple JS function is you have flexibility.
function FileList() {
if (!files.length) {
return <EmptyMessage/>;
}
return <List items={files} />;
}
function FileList() {
return files.length
? <List items={files}/>
: <EmptyMessage/>;
}
What feels unnatural is the syntax that these templates pull out of thin air to do things the language can already do. Why should I need to learn another syntax just for templates?
<div>
{items.length === 0 &&
<p>No items.</p>
}
{items.length === 1 &&
<p>Warning: You only have 1 item, at least 2 is required</p>
}
{items.map(...)}
</div>
`false` is not rendered by react, so this code is perfectly fine.
You don't have to, you can create a simple 1 line component to turn it into a declarative style.
It's the benefit of having a full language instead of a template DSL for rendering. Declarative syntax is easy inside of an imperative flow, doing the opposite tends to lead to problems though.
Ok, I should probably edit my comment to "JSX/TSX feels so incredibly natural except for needing to use JS ternaries for conditional rendering" because seriously what were they thinking there?
I looked at the github, and end of last year there was a request for TS support, Rich said S3 was being built with it in mind, but I don't see anything since then
As someone who has built a number of data products w/ React, I decided to give Svelte a try a few months ago. At this point I am using it on some internal projects to great success & ease and probably wouldn't go back to React for newer projects unless there was a compelling reason to (eg collaboration w/ other React devs). As a disclaimer, I admire the React community + devs and think React has made a lot of hard things much, much easier.
A few unvarnished takeaways from a data science / viz point of view that I was thinking of writing up, but will use HN as a sketchpad:
1. I don't really miss the React 3rd party ecosystem as much as I thought I would. Since most of what I do is data viz / data presentations, I really just need a few d3 helper functions, and most other things I can build myself w/ svelte's affordances. The biggest downside, however, is that there aren't any good accessible UX component libraries for Svelte, so I have built my own. This all said, I'm productively code-homesteading and I love it. Animating component lifecycles, component style scoping, and state management are 1st-class citizens, so these pieces are pretty high-quality, usable, and thoughtfully built.
2. my "time to first meaningful render" metric was at an all-time low with Svelte. Getting started on a new idea or project is far, far easier than w/ any React project I've ever done. Substantially less boilerplate means I can get much, much more done in the same amount of time. I feel this every time I jump back into the React projects I work on & maintain.
3. as my apps have grown in complexity, I've found that Svelte really holds up beautifully. The style/layout/behavior colocation strategy keeps the cognitive overhead of working on all the parts of multiple components to a minimum. The performance gains of Svelte, even with complex components and interactions, feels magical. Bundle sizes are bizarrely small.
4. as someone who feels CSS will absolutely outlive all of these frameworks, I think the design of Svelte really feels like the best of both worlds. And that's how it should be – css + markup should be first-class citizens.
5. the testing story isn't fully there yet, so I would say to that end, proceed with caution. I typically try to compartmentalize JS logic from presentation as much as possible, but perhaps you don't.
6. the reactivity parts shine everywhere and are fairly easy to reason about in all cases, but they REALLY shine when you're building complex visualizations.
7. this is an important one to me – building something in Svelte really tickles the same part of the pleasure centers of the brain that JQuery did for a previous generation (and d3 did for early data scientists). You just SEE the thing work, effortlessly, at a low cognitive cost, and everything fits together so nicely. I often start svelte-powered experiments and end with a great, reusable component. I think there is a large group of engineers who remember the JQuery days and sat out the React era because it just seemed like way too much to do simple things. I think Svelte is especially for them.
In sum, really highly recommended to at least try it. I wanted to find evidence to discount Svelte, but haven't found any at this point, despite my best efforts. There is probably a certain class of dev that should be trying it – one without a ton of organizational constraints, probably. But if you do data science and want to level up your data presentation skills, you should be using Svelte imo.
I've been considering svelte for exactly this d3 datavis use case. Are any of your projects publicly available to explore and get a feel for? I'm new to front end and so far have been disappointed with the speed of plotly and dash, which as I understand it are written around react. I'd love to see an example of svelte performance in a more datavis use case.
Unfortunately not – they're all private, internal views at the moment. I do hope to clean up some of my components and write something about some of the cool workflow aspects I've been able to unlock.
In the meantime, I would recommend walking through the tutorials & examples. They're very well written and I go back to them regularly to try out different parts. Try just making a simple line chart! Now make six on one page! Now try to link the rollovers for all of them! You'll probably learn a ton doing just that.
as an aside, Rich made svelte, according to a podcast I was listening to, because he does dataviz for, currently the Times ( previously the Guardian ). So it should work well for that use case.
I also read that Imba can be used with other frameworks like React and Vue. That’s why Scrimba has courses on those where you can edit code while learning.
Imba can also be used to make desktop applications it seems. The team behind it also released GitSpeak, a Github client that works really well.
It does look great. I’m concerned though, few years ago I used to use rivets [1] for two-way data binding in html. It worked very well. Unfortunately, it’s abandoned. Same fate as coffeescript, backbonejs, etc.
Now I primarily use react. Vue looks great, but I don’t want to introduce yet another framework.
I could use some insights/view points from hn. I don’t feel using/learning the now-abandoned frameworks is useless though — the things I built are still working. But good luck to anyone who’d want to maintain that codebase (unlikely in my case).
Rivets is kinda simiar to Vuejs(although has some pain points). I have code that automatically ports templates to React with jscodeshift. I was able to port "logic" to MobX easily.
Interesting that the custom element appears to just take a single JavaScript object as a parameter:
<Board {game} />
In JSX this would be either:
<Board game={game} />
or:
<Board {...{game}} />
This is almost as ergonomic as JSX except for attributes like checked where the value is omitted. It might encourage some refactoring, compared with React, because the thought of putting attributes in a variable and adding them as a spread might occur more often when seeing an object being passed in.
At any rate, I recommend looking at the code example linked in the post, or watching the video. Otherwise the post is pretty low in information, as the top comment at the time of writing this suggested. https://github.com/jesseskinner/svelte-tic-tac-toe
Well you might like Hyperscript or Elm, those are two approaches that work quite well using simple function calls.
The thing with JSX is introduces a syntax that is familiar to the rendered output (which is the status quo), and there's a relatively clear visual separation between the declarative and imperative parts; which is hard to enforce in pure JS.
I'm struggling to think what kind of control flow you're looking for when specifying a document consisting of a tree of components. If all you want is a way to render one nodeset over a different nodeset at runtime then you can easily do that by setting that behavior in the relevant component.
Not sure how that's a preference without any further context about how you plan on writing the rest of the client. For all we know, both of those functions return <Board {game} />.
Well, that's kind of my point. Making a superficial aesthetic change doesn't explain what you're actually preferring over JSX. Nor do you seem interested in explaining it.
How would it scale for a bigger app ? Shipping a library with the app like react creates poor performance for small components for sure, but abstractions must become worth it beyond a certain scale no ? I guess the compiler could also create abstractions when it becomes worth using them ?
Yep, having some problems this week with Google Cloud Run (which hosts the site). I guess that's what happens when you use a platform that's still in beta...
Svelte is strikingly similar to Marko.js [1] which predates it by few good years I believe.
Sadly the latter is still under the radar despite bringing in many interesting innovations to the space: its server-side approach being one of my favorite features.
Svelte is so great... so were react, angular, ember, meteor, and vue. I'm sorry, but I've got trouble seeing how having one more framework to learn is going to help any thing.
There's a webcomic of some sort to which I can't find the link, which talks about this. Some one is sick of the bloat of x framework/tool/whatever, and decides to build it better. He works hard, and finally version 1.0 is released to dramatic music. But there's a problem - it hits the real world and starts running into edge cases, bugs, and other things that can't be predicted in design and testing, necessarily. Features creep, and over time, it becomes just as bad as that which it sought to replace. Then, some bright young soul gets the idea that he can do it better...
This is not to discourage innovation. It doesn't appear it's been battle-tested like other frameworks, and I don't see many major operations on the list of users. If it ends up better, great, but I can't say I'm optimistic.
It's just more options. Svelte is new in that it actually compiles the components and logic into plain low-level JS code instead of having a "runtime".
It's something most of these frameworks should have already done by now considering they need build steps but maybe it needed a new project to make it happen. It's a brand new release though so it'll take more time for uptake, and by people who think the opposite of what you typed.
You're right that it's more options, but it's also one more box a "competent JS dev" is expected to tick. One of the best and worst things about the JS ecosystem is the plethora of choices available.
On compilation, nope. Riot.js did it first, and this is literally the entire premise of typescript (I know typescript is a different language, but I see little difference here as it can mix with JS between writing only some stuff in TS).
You're right, they probably should have done it, and I'm excited to see it. But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
> But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
I see this sentiment a lot in open source. When I made Rollup — which is now used to build the most popular libraries in the JavaScript ecosystem, including some you just mentioned! — people asked why I didn't just submit a PR to webpack?
I understand why people ask that. But it just doesn't work like that. Very often, to take a step forward, you can't simply make incremental changes to an existing project — you need to create new foundations altogether. When Svelte 1 came out in 2016 I was already responsible for a different framework (Ractive), and it wasn't possible to make the changes I wanted there. If you can't do what you need to do by making a PR to your own project, then imagining that you can do it in a PR to someone else's is a fantasy.
It's a shame that the site's down. Until then, you can (and I heartily recommend doing so) watch the "Rethinking reactivity" video here: https://www.youtube.com/watch?v=AdNJ3fydeao
FWIW I did a project with Ractive before React became popular, and I liked it. I guess for many problems it would still be enough if only it were more popular.
> You're right that it's more options, but it's also one more box a "competent JS dev" is expected to tick.
Is that really true? React and/or Angular is something I would expect. If one uses anything more exotic then one should have a "they'll figure it out on the job" attitude.
> But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
Do you honestly believe one can just leave a "here's a full static compiler for X" at the doorstep of these projects with some expectation of it actually being accepted?
That would basically be an entirely separate program to be maintained alongside the runtime and any design considerations on either side will affect the other side.
Oddly, it's a lot like Vue.js, except pre-compiled with a simpler syntax. Vue3 is about to make some syntax changes which will make Vue.js a lot like Svelte... :)
We should probably settle. Other platforms afford a new UI framework maybe once a decade.
The Web Frontend, already running on top of an apparently inadequate framework called "HTML5", somehow needs to be reinvented every year and it's a huge cost factor.
No it's not, no one is rewritting their front ends every year to change frameworks. React was released 6 years ago, Angular fully released about 3 years ago. Just because some person decided to build something that solved their problem and may help others doesn't mean you need to adopt it and change everything. This argument that everyone needs to slow down because some people don't like hearing about change is ridiculous.
No other platform is as widespread and accessible as the web. There's more developers able to target sites that fit a massive range of uses, more than any other platform ever. So ofcourse there are going to be different needs for different use cases.
> No it's not, no one is rewritting their front ends every year to change frameworks.
Maybe not quite every year, but the dominant frameworks have changed a lot in the past decade and if you're still running some of the "next big things" of yesteryear the developer pressure to switch is strong. The churn is real.
> React was released 6 years ago, Angular fully released about 3 years ago.
In my opinion, React being quite stable over that timeframe is a big factor in it becoming the dominant player. Angular being scrapped and rewritten is exactly what I'm talking about, lots of development effort wasted there.
> This argument that everyone needs to slow down because some people don't like hearing about change is ridiculous.
If the kids want to keep playing with the latest toys, that's fine. Just don't expect the people paying the bills to buy into them.
You have misunderstood the point. I'm not saying "stop creating new frameworks". Create anything you want, I don't care.
When I am talking about "settling down", I'm talking about the people that implement real systems for businesses to use. Those people have to make decisions on the technology they're pushing.
If those people can't settle on a stack and keep changing their minds on how to implement a user interface, somebody has to pay for that. This is akin to a "little fire" in a very real sense - it's burning money that could be used otherwise.
So telling me that "I don't have to use it" is besides the point. I don't run the whole show by myself. Developers need to be reasonably comfortable with their stack. If you are using <outdated stack X> but the whole industry is shifting towards <shiny new stack Y>, people will just quit on you.
Businesses pay to solve business problems, not change frameworks. The majority of software dev requires long-term decision making, commitment and support. Developers who can't solve problems because they're too busy chasing the latest framework aren't going to be getting much work.
People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
> Developers who can't solve problems because they're too busy chasing the latest framework aren't going to be getting much work.
That's not really how hiring works. Nobody is going to put "I failed to get anything done because we re-wrote everything in Svelte" on their resume.
> People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
If you're switching a tech stack, by definition, you don't really know what you're doing. You're treading in unknown territory. You're spending real money for the promise of hopefully increasing productivity in the future. You are speculating.
I'm not saying this is a risk you should never take, there's a downside to never switching stacks too. The idea that you just need the right team and everything will be fine is a fantasy.
I'm saying that people dont constantly switch. It's not that common at all, despite what you might hear in online discussions. And it's usually because most of these projects have real timelines and deliverables, along with a team of people who aren't interested in rewriting everything either.
Of course there are a few teams (even in praised companies) that chase the fad, but they're the sames ones that do things like use CQRS and Kafka for a basic CRUD app.
You're saying people don't constantly switch, but even if they did, it wouldn't be much of a problem unless they don't know what they're doing.
Well, fair enough. I never claimed that businesses switch stacks "constantly" anyway. Still, at the industry level, there is constant flux - much more so than on other platforms. Unless you use one of the big players like React, chances are your framework of choice won't last and become legacy software quite soon.
I got introduced to Rich Harris via a podcast (not personally), but am a big fan of his perspective on JS. I think we can all agree that; if you don't like Svelte, then fine. If you love JSX/TSX - then great! If you're a Vue person, then awesome - its exactly what makes this community great - the diversity & innovation. Not the soap-boxing antics, polarised opinions & vilification of opinions that aren't congruent with your own.
As someone much wiser than me once said - "always bet on Javascript".