Seems like MediaRecorder (https://developer.mozilla.org/en-US/docs/Web/API/MediaRecord...) is the standard API to record the screen, it takes a video format during setup, and then `recorder.requestData()` will give you the raw bytes for your format of choice when you're done, ready to download and save or do whatever with. Web standards do a lot of heavy lifting for you nowadays!
I'm really excited to see further development and use of Svelte. I develop both Vue and React front ends (both have their strengths and weaknesses) and Svelte is a breath of fresh air. I'm not saying Svelte is _better_, but I am enjoying It's approach a bit more.
Definitely still in the camp of thinking it's the next big thing. In my experience, Svelte does a great job of just getting out of the way and letting you start coding.
The ecosystem isn't there yet, and I probably wouldn't try to use it in a work project. For my personal projects though, I use it for everything front-end. More than that - I've stopped making desktop apps and just default to using svelte instead.
Happy to answer any specific questions you've got! Bottom line - given the opportunity, I will use Svelte.
I'm not a frontend developer, but absent svelte, the next easiest thing to develop is a full on desktop application (easier than some other frontend web framework)?
Until they solve https://svelte.dev/faq#how-do-i-test-svelte-apps and the ecosystem matures a little (Sapper -> svelte) I wouldn't recommend using it for any production applications. I
do currently use it for PoCs since it's easy to spin up and be productive quickly.
As someone who’s been recently doing front-end dev work full-time the question below it is also a little triggering. “Is there a router?” Not an official one but they list like 6 alternatives, two of which are apparently “very similar”.
The JS ecosystem’s penchant for giving you small components that you have to choose individually and then glue together can get a little exhausting. Hopefully the library whose approach you prefer has decent documentation, keeps up with changes to svelte, doesn’t get abandoned, etc.
Edit: apparently Sapper is a Next.js like framework that provides all the components you need for svelte in one package. Someone else said on this thread it’s eventually getting deprecated by the svelte team’s own thing called SvelteKit. Not ideal, but at least they’re working on something more integrated.
They also don't have an answer for error handling. You can't catch them with Sentry, you can't catch then to handle them, and when they happen your app just freezes.
We've switched to Svelte for new projects at work, from React. It feels like a significant improvement, especially regarding unnecessary complexity and verbosity. The UI component libraries for Svelte are still lacking in maturity, that's the one drawback I can think of.
> It feels like a significant improvement, especially regarding unnecessary complexity and verbosity.
> The UI component libraries for Svelte are still lacking in maturity
The typical counterargument usually made at this point would be "those two points are related" (to paraphrase Bjarne Stroustrup: "every ship gets barnacles as it ages").
So let's anticipate that: do you have any reasons to believe that Svelte will avoid adding accidental complexity/verbosity to it as it/the surrounding ecosystem matures, and if so, how do you think that will be mitigated?
I really like it. Replaced Vue with Svelte and things have been great so far. Smaller bundles, and much lighter components. Built-in state management is very handy.
The initial pages are Go templates which are hydrated with Svelte components. It took a bit of trial and error to get the flow right so that I don't have to write double the code.
I don't know if it's the next big thing or not but it works really well for me.
> The initial pages are Go templates which are hydrated with Svelte components. It took a bit of trial and error to get the flow right so that I don't have to write double the code.
What is the advantage of doing this over using http.FileServer to serve html which imports your svelte generated javascript directly ?
Are you using Svelte in a part of your application instead of the entire application?
I think this is the next leap in web UI development on the same level as jQuery, React and Vue.
I've used React, HyperApp and Flutter and Svelte (with Tailwind for CSS) is in my opinion clearly superior. But I also know someone who thinks Flutter is better.
I recently gave it a try and it generally feels nice starting out, but I started running into rough edges pretty quickly, enough that I don't think I would want to build a large app using it. Main complaint is how it handles styles, it does not allow you to apply styles to the edge of a component without doing one of several workarounds, all of which have downsides. Means it's very hard to create a set of generic styled components and then apply layout to them using a parent, which makes it a bit of a pain to reuse things, which is kinda the point of component based libraries.
I also get the feeling that the Svelte maintainers do not particularly care what the community wants and are building what they want, which is totally cool, but unfortunately I disagree with a lot of their choices so I guess it's not for me.
Still in the next big thing camp myself, also. Of course, there are the noted drawbacks, but for our use case: putting a library of UI components across a handful of app stacks (.NET, asp, Angular, etc) - Svelte is the solution.
We have faced the usual wild west frontier situations where nobody really had an answer for something we wanted to do, but we have worked out solutions without a huge deal of frustration.
And it's important to mention that the development and maintenance experience of Svelte is very pleasant.
I've been converting my massive Vue 2 application to smaller "micro front-ends" written in Svelte/Sapper. For some reason I just feel it's faster to write in Svelte than it is in Vue 3, and these are all in production. But we're a tiny startup and I'm the only developer so...
I wouldn’t use it for big commercial projects because the ecosystem isn’t very big (ie I wouldn’t build a b2b saas app with it) but for small projects and side projects it’s great.
Here's my general thought, in a year we will all be singing the praises of something else, and my fellow webdevs will continue to mistake "different" for "better".
I enjoy writing in Svelte more than using React. I like the concept that the output doesn't contain the actual library. I think testing tools is a must have though otherwise it will just be for my personal projects.
Looking forward to SvelteKit - I don't care for TS though.
Can I use svelte as an alternative to nuxt.js? I want to create a simple website where most of the content is written in markdown, that is rendered to static html (that can be hosted on e.g. netlify).
As it is kind of a hobby project, might as well learn the next hot thingg? Is Svelte suitable for these kind of applications? Some of the features of nuxt.js that i like: content module (put some markdown files in a folder and the routes, write a template and then all the html rendering etc is all taken care of) extensions for image resizing so images are resized to multiple resolutions as part of the build process, hot reloading in development
My "blog" (HR bait really) is exactly such a thing(using Sapper), but I had to integrate the markdown->html library by myself, I don't resize images and hit reload doesn't work.
So basically it's possible, put you have to put the thing together by yourself.
One minor nitpick: "strongly typed" is not very meaningful. "statically typed" (or just "typed") conveys the intended meaning much better, since it has a clear definition.
Anyway adding proper support for TS sealed the deal for me - Svelte itself might never reach mainstream adoption but the idea of having a framework-compiler is something that I hope will, since it retains all the advantages of alternative approaches without introducing any significant disadvantages.
"Strongly typed" and "statically typed" are not synonymous. Yes, SvelteComponentTyped is statically typed, but that's somewhat implicit (and irrelevant) here. What they're referring to in that particular sentence is ease of strong typing. Static typing is a separate thing.
That's true, but GP's point about how nobody really agrees on what "strongly typed" means still holds up.
It might be worthwhile to frame it as "static and strongly¹ typed" with a footnote expanding on what "strongly" means to the svelte developers, just to get everyone to agree what we are even talking about in the first place.
Strongly typed is meaningful and has a real definition, but it is used incorrectly here. Strongly typed means that invalid runtime types result in invalid programs...which can actually be true for both static typed languages (like Rust or OCaml) and dynamic typed languages (like Python, which throws errors on invalid types).
Typescript is statically typed but it is also weakly typed. Types are validated at compile time, but they do not prevent you from using invalid types at runtime.
1. Open standards. There is no one entity to control what frameworks are "standard". Need for back compatibility of the web standards make them too simple and minimalistic. So you inevitably have a demand for power tools.
2. Many players are trying to capture demand for power tools. Of course their reasoning and approach differ. Often it becomes less about technology, but more about audience perception of the tool. Then we see more blogposts, podcasts, meetings, "see how easy to create and app" posts.
3. Web frontend is hard environment to model UX because too many moving parts. You have inherentedly stateful programm which should communicate asynchronously with at least 2 inputs-outputs: web server and user. Not speaking that it's not enough to have framework with proper building blocks to model your UX, you have bunch of issues with dependencies, debugging and integrations with existing tools.
This makes hard to come up with a solution which can satisfy many people. Some people are infiltrated with ideas which are incompatible with particular framework ideology, and bam, you have 2 camps which "push" against each other.
Now you have demand for tools, but tools shitty in some ways, and it's shitiness is covered with hype, brands and other forms of forming opinion.
This creates a demand for a new thing after people get disillusioned via own experience. And we get yet another framework. Repeat every 4-5 years.
JS front-end frameworks are born from ad hoc application architecture or from difficulty applying an existing framework to an application. The progenitor applications had different feature and development requirements, which is reflected in the varying frameworks.
While it may seem a plethora of frameworks exist, a few have most of the market share. That is not too far from the situation with other programming languages and framework types.
There are also old frameworks that have essentially been obsoleted but continue to stick around due to project inertia, the needs of legacy code, or marketing needs of the maintaining organizations.
Some people prefer FP. Some prefer OOP. Some need just a sprinkling of interactivity. Some need to build complex UIs. Some need to run on underpowered devices while others don’t. Some dislike too much abstraction. Some prefer it.
In short, we have a plethora of frameworks for the same reason we have a plethora of languages, sodas, beers, coffees, tools, products, novels, etc. Humans are messy.
"Can someone explain to me why we have so many programming languages?"
Different strokes for different folks. People are trying to make new things that solve what they think are pain points in previous approaches.
There really isnt "so many" frontend frameworks. React is the clear leader, with Vue and Angular trailing behind. Svelte is a bit more of an experimental/innovative thing.
There is quite a long tail of small/niche frameworks, but for most folks there aren't many major ones, really it's 3; React/Angular/Vue. There's probably another 5-10 in the next cohort, including Svelte
Readit News
Wait, is this thing entirely client-side, in only 17.5 KiB? I know browsers can capture video frames, but how does it export it afterwards?
[0] https://vippet.netlify.app/
Export code is here: https://github.com/mattorchard/vippet/blob/master/src/helper....
Seems like MediaRecorder (https://developer.mozilla.org/en-US/docs/Web/API/MediaRecord...) is the standard API to record the screen, it takes a video format during setup, and then `recorder.requestData()` will give you the raw bytes for your format of choice when you're done, ready to download and save or do whatever with. Web standards do a lot of heavy lifting for you nowadays!
The entire app bundle [1] is roughly the size of a library adapter like react-redux [2], which is just glue code.
[1] https://vippet.netlify.app/build/bundle.js
[2] https://unpkg.com/react-redux@7.2.2/dist/react-redux.min.js
As a point of reference, just this week I saw someone on Observable experiment with WASM-compiled encoder packages for that exact reason[0][1].
Svelte seems really nice and lean though, I do agree with that
[0] https://www.npmjs.com/package/h264-mp4-encoder
[1] https://observablehq.com/@rreusser/h264-mp4-encoder
[0] https://developer.mozilla.org/en-US/docs/Web/API/MediaStream...
(And also ts-liveview is inspired from s-js and Phoenix Liveview)
Anyone use it then go back to the traditional frameworks? Anyone love it and still think it’s the next big thing?
The ecosystem isn't there yet, and I probably wouldn't try to use it in a work project. For my personal projects though, I use it for everything front-end. More than that - I've stopped making desktop apps and just default to using svelte instead.
Happy to answer any specific questions you've got! Bottom line - given the opportunity, I will use Svelte.
Deleted Comment
The JS ecosystem’s penchant for giving you small components that you have to choose individually and then glue together can get a little exhausting. Hopefully the library whose approach you prefer has decent documentation, keeps up with changes to svelte, doesn’t get abandoned, etc.
Edit: apparently Sapper is a Next.js like framework that provides all the components you need for svelte in one package. Someone else said on this thread it’s eventually getting deprecated by the svelte team’s own thing called SvelteKit. Not ideal, but at least they’re working on something more integrated.
> The UI component libraries for Svelte are still lacking in maturity
The typical counterargument usually made at this point would be "those two points are related" (to paraphrase Bjarne Stroustrup: "every ship gets barnacles as it ages").
So let's anticipate that: do you have any reasons to believe that Svelte will avoid adding accidental complexity/verbosity to it as it/the surrounding ecosystem matures, and if so, how do you think that will be mitigated?
The initial pages are Go templates which are hydrated with Svelte components. It took a bit of trial and error to get the flow right so that I don't have to write double the code.
I don't know if it's the next big thing or not but it works really well for me.
What is the advantage of doing this over using http.FileServer to serve html which imports your svelte generated javascript directly ?
Are you using Svelte in a part of your application instead of the entire application?
https://undefined.fm/radio/vue-vs-svelte-with-evan-you-and-r...
I've used React, HyperApp and Flutter and Svelte (with Tailwind for CSS) is in my opinion clearly superior. But I also know someone who thinks Flutter is better.
I love it and will slowly be replacing my React/Vue/(old angularJS) projects with it.
The nice thing is, you can read the entire docs and just follow the interactive tutorial in a few hours and get up to speed incredibly fast.
I also get the feeling that the Svelte maintainers do not particularly care what the community wants and are building what they want, which is totally cool, but unfortunately I disagree with a lot of their choices so I guess it's not for me.
We have faced the usual wild west frontier situations where nobody really had an answer for something we wanted to do, but we have worked out solutions without a huge deal of frustration.
And it's important to mention that the development and maintenance experience of Svelte is very pleasant.
Svelte has been around for "a while" and seems to be hanging around and people are enjoying it.
I'm still really comfortable with React, and would love to know how people have found the transition between the two and how Svelte compares.
Looking forward to SvelteKit - I don't care for TS though.
As it is kind of a hobby project, might as well learn the next hot thingg? Is Svelte suitable for these kind of applications? Some of the features of nuxt.js that i like: content module (put some markdown files in a folder and the routes, write a template and then all the html rendering etc is all taken care of) extensions for image resizing so images are resized to multiple resolutions as part of the build process, hot reloading in development
So basically it's possible, put you have to put the thing together by yourself.
Anyway adding proper support for TS sealed the deal for me - Svelte itself might never reach mainstream adoption but the idea of having a framework-compiler is something that I hope will, since it retains all the advantages of alternative approaches without introducing any significant disadvantages.
It might be worthwhile to frame it as "static and strongly¹ typed" with a footnote expanding on what "strongly" means to the svelte developers, just to get everyone to agree what we are even talking about in the first place.
Off the top of my head there's also "strong", as in "the type system is sound" or "not allowing pointer arithmetic".
It's not that clear cut.
Typescript is statically typed but it is also weakly typed. Types are validated at compile time, but they do not prevent you from using invalid types at runtime.
1. Open standards. There is no one entity to control what frameworks are "standard". Need for back compatibility of the web standards make them too simple and minimalistic. So you inevitably have a demand for power tools.
2. Many players are trying to capture demand for power tools. Of course their reasoning and approach differ. Often it becomes less about technology, but more about audience perception of the tool. Then we see more blogposts, podcasts, meetings, "see how easy to create and app" posts.
3. Web frontend is hard environment to model UX because too many moving parts. You have inherentedly stateful programm which should communicate asynchronously with at least 2 inputs-outputs: web server and user. Not speaking that it's not enough to have framework with proper building blocks to model your UX, you have bunch of issues with dependencies, debugging and integrations with existing tools.
This makes hard to come up with a solution which can satisfy many people. Some people are infiltrated with ideas which are incompatible with particular framework ideology, and bam, you have 2 camps which "push" against each other.
Now you have demand for tools, but tools shitty in some ways, and it's shitiness is covered with hype, brands and other forms of forming opinion.
This creates a demand for a new thing after people get disillusioned via own experience. And we get yet another framework. Repeat every 4-5 years.
While it may seem a plethora of frameworks exist, a few have most of the market share. That is not too far from the situation with other programming languages and framework types.
There are also old frameworks that have essentially been obsoleted but continue to stick around due to project inertia, the needs of legacy code, or marketing needs of the maintaining organizations.
In short, we have a plethora of frameworks for the same reason we have a plethora of languages, sodas, beers, coffees, tools, products, novels, etc. Humans are messy.
Different strokes for different folks. People are trying to make new things that solve what they think are pain points in previous approaches.
There really isnt "so many" frontend frameworks. React is the clear leader, with Vue and Angular trailing behind. Svelte is a bit more of an experimental/innovative thing.
Dead Comment