Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming

Svelte Origins: a JavaScript Documentary (youtube.com) 48

Svelte Origins: The Documentary tells the story of how Svelte came to be, what makes Svelte different, and how it changes the game as a JavaScript framework. From the description of the documentary, which was recommended by several Slashdot readers: Filmed in locations throughout Europe and the US, it features Svelte's creator Rich Harris and members from the core community who contributed to making Svelte what it is today. Svelte Origins was filmed in late 2021, produced by OfferZen and directed by Dewald Brand, with shoots in the USA, the UK, Ireland, Sweden and Germany.
This discussion has been archived. No new comments can be posted.

Svelte Origins: a JavaScript Documentary

Comments Filter:
  • No. (Score:4, Funny)

    by nightflameauto ( 6607976 ) on Monday June 27, 2022 @03:15PM (#62655376)

    It's bad enough that people are convinced big frameworks are the only way to ever program anything functional web or otherwise. Now they're making documentaries about them? No. "The line must be drawn hereTHIS far, NO further!"

    • But Rich Harris is so dreamy.

    • by Tablizer ( 95088 )

      people are convinced big frameworks are the only way to ever program anything functional web or otherwise. Now they're making documentaries about them? No.

      Jack Dawson: "I'm King of the bloated ship!" ... [CRUNCH] *bloop* *bloop* *bloop*

    • Re:No. (Score:4, Informative)

      by K. S. Kyosuke ( 729550 ) on Monday June 27, 2022 @03:44PM (#62655492)
      It's not a "framework", it's a compiler. Yep. Javascript people *finally* discovered compilers after two decades.
      • It's not a "framework", it's a compiler. Yep. Javascript people *finally* discovered compilers after two decades.

        Why can't it be both, the compiler being part of the framework to make it run faster?

      • The Slashdot summary clearly says otherwise, so... you're probably correct.

      • This is actually been extremely common for years now as far as JS is concerned.

        The standards in use are kind of a mess (for package management for example not having a global cache of packages to save on disk space)
        But generally what folks do is write stuff in sudo languages such as Typescript / CommonJS / ESM Modules which are then compiled or "transpiled" down to bare JS the browser can understand.
        CommonJS was sort of the old standard introduced by node for separating out code modules into different files

      • by znrt ( 2424692 )

        It's not a "framework", it's a compiler. Yep. Javascript people *finally* discovered compilers after two decades.

        well, javascript people have been creating and using all kinds of compilers, transpilers and even assemblers extensively for a long while now, in great part to cope with the huge variability (nothing as substandard as a web standard, mind you), and the performance challenges of the environment.

        you'd knew if you weren't so busy ranting from your imaginary high horse because you heard some people write shitty webapps in javascript. like you never have seen a shitty c program. ever!!!

        other than that you might

      • by narcc ( 412956 )

        Yep. Javascript people *finally* discovered compilers after two decades.

        Umm... you know that every major JS engine uses JIT, right?

      • Scripting exists for a reason and that reason is the opposite of compiling languages!

        You script to automate on a macro level and to glue components together. Scripting is like duct tape. It's powerful stuff and flexible and quick but it's also sloppy. It is not supposed to scale it's supposed to glue!

        Today's scripting is like people trying to build something out of 100% duct tape. It can be done but it's an ugly hack; maybe humorous except people are too serious about insisting upon this. So now we are t

        • The problem is that the JS language when it was invented was poorly thought out and had multiple browser vendors all trying to set what the standard should be.
          The end result is a mess of a language in the browser, which isn't fixible without breaking all the webpages on the internet.
          Typically example is having global variables everywhere, or not checking types when you put an integer in some place where it's expecting a string.

          The only workaround currently in JS land is to "transpile" so you write in someth

          • Javascript is just fine as a scripting language; many languages with more thought put into them came out worse. The problem today is JS is more than fixing flaws, they are turning it into the C++ of scripting.

            Global variables are not a problem (far more of an issue for incompetent programmers) and having no type checking is not a big problem either. Your problem is that you want a Java like language. Just because JS is like C turned into scripting does not mean JS should be more like C. The real flaws in

            • > Global variables are not a problem (far more of an issue for incompetent programmers)

              They will be if you have no form of seperation of code and you're including lots of libraries from npmjs all with dependencies
              It's the reason CommonJS was invented as a way of namespacing / seperating code, now ESM has replaced it and has just recently made it's way into modern browsers

              > Your problem is that you want a Java like language.

              Personally I think Java is pretty dire, but I understand where you're coming fr

              • Oh, I didn't say there was anything perfect out there today. I've yet to see anything good that works well. But scripting is for high level glue-- which is part of the balance between flexible and fully planned.

                One doesn't need a solution to complain or prevent foolish feature creep. We should be working towards niche solutions instead of morphing everything into one tool to rule all software engineering.

              • I've taught web app dev for decades and enjoy parts of it.

                C++ gives a lot of freedom to make missteps or foolish decisions. One can direct blame at the language for allowing so much human error... or.... I am aware that complexities create problems and the need for abstractions... as well as over abstractions and coupling nightmares.

                JIT is an optional addition to an interpreter; it is NOT required. It is not the same as forced compiling and build tools. Again, a browser is a multimedia app and JS merely a

    • by dyfet ( 154716 )

      Indeed, my first thought is how absurd that is, like the Golgafrinchan's making a self documentary...

    • Didn't you read the name? It's called "Svelte" how can it possibly be big?

    • Most Frameworks are small and tiny.

      Unfortunately most people think if they code for the bare metal or bare OS that they are better coders than people that use frameworks :P

      30 years later they pop up in TV shows and explain how "they invented their own framework".

  • Never heard of. I'm keeping it that way.

  • I could get one for JS itself, but for a framework?
    Especially one and the other 2 in here have not heard of.
  • It's something I've discovered myself recently. One of the big differences is that it compiles down to js without the use of a virtual dom.
    Another is that is syntax is a lot simpler and easier to work with (it feels like it has the best bits of react and vue combined)

    You have svelte itself which can be used with webpack or vite (vite being a newer faster equivilent of webpack written in golang).
    Then you have sveltekit which is more of an opinionated layer on top of svelte / vite with a router and endpoints

    • by imidan ( 559239 )
      I honestly cannot tell whether all that stuff you typed is true things about Svelte, or just a magnificent stream of techno-bullshit.
      • We learned that programming can have "opinionated layers".

        • Opinionated means I'm going to force you to do something the way I want instead of being flexible and allowing you to do it any old way you'd like.
          This can be good in some ways as it makes life simpler, but bad in other ways if you want it to do something in a way if doesn't want.

          Sveltekit is opinionated because it assumes you want to use it's own router and it's own endpoints for it's api, you can sort of force it to use a different router but it's a bit of a pain. Also it forces you to use vite.
          In the cas

      • A virtual dom is something typically react and vue use instead of the normal dom (document object model) inside the browser.
        It's something used to track the state of how all the components are joined together (think of it as a virtual window). The problem is you've got one dom sitting on top of another which has a performance impact.

        Svelte compiles down to javascript without a virtual dom, this makes it somewhat faster in some places since it doesn't have the overhead of trying to manage it's own dom, but i

        • by imidan ( 559239 )
          Thanks for the lesson. I don't do a whole lot of front-end JS development, and when I do I usually favor a relatively lightweight framework. But most of what I do recently is science programming, data munging and analysis type tasks.
    • by ndykman ( 659315 )

      Huh. Silly me, I'm just waiting for developers to catch on to what people learned from ASP pages. Mixing code with markup is a bad thing. Just because Facebook gets away with, doesn't mean you will.

      • It is only a bad thing if you do it wrong.

        There are actually no real alternatives to do it. Or do yo have one?

        The mistake is to have business code in the GUI layer.

        No code int GUI lyer is impossible. Or you have to generate the whole GUI with ... oh, CODE. Then you have UI in the code. What is the difference of having CODE in the GUI layer versus having GUI in the CODE layer? I see none. And one of both you have to do, or you need a magic framework that magically moves data from your data model (which is c

  • Not sure exactly why it got a documentary, thou am looking forward to checking it out. As a long-time Java developer, Svelte & SvelteKit are the first front-end framework that I actually enjoy using, TBH. Using it with TypeScript, Prisma, Vitest, so far it's pretty nice. It's a bit weird - I keep finding in project after project it's the UI stuff that's much, much harder nowadays that the backend. Was using HTMX + Alpine.js for a bit with Thymeleaf because I didn't want to switch to front-end tools. S
  • by Petersko ( 564140 ) on Monday June 27, 2022 @04:58PM (#62655706)

    My last two engagements have been based in React and Angular. And as far as I care, both can take a long walk off a very short pier. I don't care if you wrap it in a pretty bow (i.e. TypeScript), javascript for complex projects is just... gross. I've spent the last couple of years giving them the benefit of the doubt, but I give up. I've never been a Microsoft guy when it comes to dev - my roots are heavily in UNIX / Linux stretching all the way back to the 90s on Solaris / SPARC. But I'll take C# and .Net any day over the mess that is JS. Mind you, whatever the job is, that I shall do. I'm above all a pragmatist.

    • by Anonymous Coward
      React and Angular are are an incredibly bloated way to develop for the web. They're very gross!

      They're mostly hype, with lots of buzzwords -- like virtual dom woo -- for people that are ignorant to vanilla-JS and think they need a framework just to make a button.

      Just stick with the basics and avoid these bloated frameworks. Most of what I've seen done with them is more about egos being stroked than beneficial for projects. I've had to suffer through working with this crap and never again, as it's
      • Re: (Score:3, Informative)

        The features that frameworks bring to the table over vanilla JS is binding, reactivity and re-usable components that slot inside one another.
        So for example I create a variable on a page, create a text box then "bind" that text box to the variable.

        If it's two way binding if I change the variable at any point the text box changes.
        If the text box changes the variable auto updates.
        Where it gets interesting is if I use that variable as part of another control.
        So only enable a checkbox if the variable length is g

        • by pjt33 ( 739471 )

          The last real web project I did, back in 2015, used web components, and they were fairly new then. By web technology standards, I'm surprised they're not obsolete by now.

    • Personally if it's a business app of some form as a C# developer myself I'd aim for blazor as an option.
      In it's webassembly mode, you have two lumps of code, one that runs server side (C#) and a second that runs client side (C#)
      The client side code only currently has access to limited API's I think (I think they're using the mono web assembly compiler), but it's easier to write for from a C# background. Also you can set it up as a desktop app using webview2

      The one downside to blazor may be the load time on

      • You can't interact with the DOM at all though which defeats the purpose as far as I'm concerned. You might as well just ask your users to download a compiled app and run it.
        • Blazor uses it's own virtual dom similar to react or vue, not ideal but it means it can manipulate it's own section / it's own part of the dom.

          • Right, but if you don't need access to the actual DOM or things like cookies / fetch, then why not just have them download it? Maybe for games this has some value, but mostly I would rather run that as a desktop app.
            • The actual DOM just means the part you put controls into (the display part), not all of the javascript environment.
              You can still do things like fetching / cookies etc.

              Typically its for people who want to write a user interface on a website that's written in C# instead of Javascript.
              So for example if I'm a company and I have C# developers and what to write some interfaces to some services sitting in the cloud that can be accessed via a mobile phone or laptop on any platform.

              Apps that are downloaded still nee

  • There is nothing dramatic or interesting about code development in general. But, coding yet another JavaScript framework. That's a incredible ego trip. No, I don't need to watch yet another set of crap, entitled programmers ^@^() up the MVC paradigm yet again because objects, inheritance and actual components are too scary (they call it inflexible, whatever) to them.

    There's no documentary on how C was created, and I'd argue that's way more interesting and impactful (there is C code in everything).

    I'm old,

    • Thanx for the information, so we all know we can spare our time to invite you for a job interview :P

      • by ndykman ( 659315 )

        Well, I am not working for health reasons. But, I'm not going into front end web development jobs anyway even if I could work. I just would pickup the occasional C# or Java contract programming, consulting or software architecture gig.

        Wouldn't be too worried about it, my PhD in Computer Science (from a fairly well regarded US school) usually opens the door enough for interviews, even if it is to ask why I am looking for a job.

        I won't bore anybody with the details of why I am not in academia (again, health s

    • It has components and all that stuff, I just took a quick look. It looks like it might be interesting but I probably won't ever use it.

When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. - Edmund Burke

Working...