The Svelte Compiler Handbook(lihautan.com)
lihautan.com
The Svelte Compiler Handbook
https://lihautan.com/the-svelte-compiler-handbook/
128 コメント
This is very useful. I have just started contributing to svelte and it was a bit overwhelming even though the bugs were very well isolated in the codebase.
I like Svelte very much. My biggest struggle is with tooling, especially the lack of proper IDE support. I know there are several IDEs with plugins for Svelte, but they're either obsolete or lacking essential features. That's why I won't use it for me next project, just not worth it going against the wind.
Now, I am looking at Flutter. Seems to match my needs, and it's also actively maintained.
Never underestimate the power of proper tooling and abundance of documentation, better be productive rather than cool.
Now, I am looking at Flutter. Seems to match my needs, and it's also actively maintained.
Never underestimate the power of proper tooling and abundance of documentation, better be productive rather than cool.
Flutter web support is in beta. I've never heard of anyone using it. Don't you think you are swimming upstream there too?
For applications it's actually quite good, if you use the WASM renderer instead of the DOM based one. I say for applications and not websites as this method will not have any SEO since it renders onto a canvas element. It does have accessibility as Flutter constructs a separate semantic tree on top that accessibility devices can read.
So Flutter Web is pretty nice if you're not making a forum for example but moreso any type of CRUD or business app where text is not a big factor. Of course, since it's Flutter you can then build mobile and desktop apps as well from your application for those who want more control.
So Flutter Web is pretty nice if you're not making a forum for example but moreso any type of CRUD or business app where text is not a big factor. Of course, since it's Flutter you can then build mobile and desktop apps as well from your application for those who want more control.
I felt like there was a sort of sea change when JetBrains started producing multiple IDEs. IDEA always struggled to handle supporting everything at once and third party plugins are always incomplete. They don’t support all of the functionality and you have to keep that active in your mind while developing, which saps resources for solving hard problems.
I just wish they could support more languages and tool chains, and I wish an IDEA subscription entitled you to all other versions of the editor. I want to buy one but use Webstorm because it’s a little less resource intensive than IDEA. And I want them to make like five more IDEs, which I feel they could fund through IDEA-specific revenue.
I just wish they could support more languages and tool chains, and I wish an IDEA subscription entitled you to all other versions of the editor. I want to buy one but use Webstorm because it’s a little less resource intensive than IDEA. And I want them to make like five more IDEs, which I feel they could fund through IDEA-specific revenue.
> I wish an IDEA subscription entitled you to all other versions of the editor.
They do offer that; it's called the All Tools subscription. It costs more than the IntelliJ subscription, but you get all the IDEs, ReSharper, etc.
They do offer that; it's called the All Tools subscription. It costs more than the IntelliJ subscription, but you get all the IDEs, ReSharper, etc.
[deleted]
Svelte support in the Jetbrains family of tools is great (IDEA, Webstorm etc). There are a few issues, but they're all minor. Started using Svelte for serious work a few months ago, very happy with it, best frontend framework I've worked with thus far.
I'm just starting to play with Svelte, but have very little JS background. Which flavor of the jetbrains tools are you actually using; webstorm or IDEA? I have the all-tools sub, so could use either but is one better than the other?
Webstorm. I use the different tools mostly to naturally categorize all the different kinds of projects that I work on, even though I think IDEA brings (most of?) the relevant features from the other IDEs.
How did Rich Harris, a "graphics editor," write Svelte? So many designers hardly know JavaScript at all. This one wrote one of the most advanced JavaScript frameworks I've ever seen. It's not just JavaScript. He wrote a compiler that takes a custom, declarative syntax and converts it to imperative JavaScript to surgically update the DOM.
I have a theory that Svelte originated from his work with Rollup.
He was already a great developer when he started Rollup, but writing it brought him to a new level.
Rollup is super clever: most bundlers back then would treat JS modules like giant strings and concatenate them. It was just plain string concatenation, similar to require.js's "define()", so you needed a runtimes that answered to "require()". Modules were assembled during runtime. [1]
Rollup, instead, uses an algorithm to transform the AST of multiple modules into a single AST, inlining all modules and turning them into variables [2], and renaming duplicate identifiers. The final code looks like something that a human would do if asked to put everything in a single file. [3]
This is done by manipulating the AST returned by the Acorn parser, something he seems to have become an expert on.
I'm pretty sure that it was during the development of Rollup that he had other ideas for crazy optimizations, but unable to apply them to a Bundler, he created Svelte.
--
[1] https://requirejs.org/docs/api.html#deffunc
[2] https://github.com/rollup/rollup/blob/1e1a11107dbee11636dcf9... and https://github.com/rollup/rollup/blob/1e1a11107dbee11636dcf9...
[3] https://risanb.com/posts/bundling-your-javascript-library-wi...
He was already a great developer when he started Rollup, but writing it brought him to a new level.
Rollup is super clever: most bundlers back then would treat JS modules like giant strings and concatenate them. It was just plain string concatenation, similar to require.js's "define()", so you needed a runtimes that answered to "require()". Modules were assembled during runtime. [1]
Rollup, instead, uses an algorithm to transform the AST of multiple modules into a single AST, inlining all modules and turning them into variables [2], and renaming duplicate identifiers. The final code looks like something that a human would do if asked to put everything in a single file. [3]
This is done by manipulating the AST returned by the Acorn parser, something he seems to have become an expert on.
I'm pretty sure that it was during the development of Rollup that he had other ideas for crazy optimizations, but unable to apply them to a Bundler, he created Svelte.
--
[1] https://requirejs.org/docs/api.html#deffunc
[2] https://github.com/rollup/rollup/blob/1e1a11107dbee11636dcf9... and https://github.com/rollup/rollup/blob/1e1a11107dbee11636dcf9...
[3] https://risanb.com/posts/bundling-your-javascript-library-wi...
The NYT graphics team is one of, if not THE, best graphics teams in journalism. You need a significant amount of JavaScript to work on the team. Yes, the team does have designers, but there are many developers on the team, including Harris.
If you look at the Svelte repo, the project didn't appear overnight. The first commit dates to 2016, and since then there have been many contributers. Don't think Harris solely built the project to where it's been. He's had help.
If you look at the Svelte repo, the project didn't appear overnight. The first commit dates to 2016, and since then there have been many contributers. Don't think Harris solely built the project to where it's been. He's had help.
He probably was interested in it. Not everyone has a traditional background or even day job in the area they're passionate about. One of our neighbours growing up in a small village was a nice old retired man who barely had any formal education, years later I found out he was publishing original maths research online. There's also a guy from Finland who IIRC was a bus driver who is putting great C++ low level graphics and retro programming content on Youtube.
Lots of under-recognised talent is eveywhere.
Lots of under-recognised talent is eveywhere.
The bus driver is bisqwit https://www.youtube.com/watch?v=3bIcbnDXSRg
that guy works as a school bus driver so, after work he codes all day
Funny you mention this, Evan You, the author of VueJS was a graphic designer before writing VueJS
I wonder if they have more interest in UX than most people, and that gave their frameworks the edge.
Lot of smart people who are not selling their soul to empower companies to:
- track people and systematically destroy privacy forever
- trick kids into clicks via what should be illegal recommendation algorithms
- use their insanely talented minds to work in advertising
Need more diversity in tech. This should be encouraged vs gulping down the big fat framework FB tells you to
- track people and systematically destroy privacy forever
- trick kids into clicks via what should be illegal recommendation algorithms
- use their insanely talented minds to work in advertising
Need more diversity in tech. This should be encouraged vs gulping down the big fat framework FB tells you to
He have also written Ractive.js and Rollup.js. From what I've seen Harris doesn't only "know JavaScript" but have a better _vision_ about its future than most, a lot of cool ideas and the skills to try them.
Harris has started a few notable projects outside of Svelte as well, including Rollup (alternative bundler) and buble (alternative es2015 compiler).
Programming is not a particularly difficult skill. During the 1980s, it was taught in grade schools. JavaScript may be a worse and more difficult language than the ones you could find in the micros scattered across schools, but it's not an order of magnitude more difficult to use effectively.
In a field that goes hand-in-hand with programming, which includes pretty much every artistic one, it shouldn't be all that surprising that people know how to use/are at least curious enough to learn the tools available to them.
In a field that goes hand-in-hand with programming, which includes pretty much every artistic one, it shouldn't be all that surprising that people know how to use/are at least curious enough to learn the tools available to them.
Actually JS is better: try writing a compiler in BASIC. In 2020 a graphic designer can do LISP style metaprogramming because of a number of subtle properties of the module system.
More complex ≠ better.
There are Lisps that are almost universally seen to be great. There are absolutely terrible Lisps as well.
There are Lisps that are almost universally seen to be great. There are absolutely terrible Lisps as well.
I was missing a resource like this. Also, I'm looking forward to the next "Compiling Svelte in your head" article.
I'm surprised Apprun nor Solid have been mentioned yet.
Are there any TypeScript reactive frameworks? I know you can use TS with the others, but finding tutorials can be a pain since it all these are JS first frameworks.
Are there any TypeScript reactive frameworks? I know you can use TS with the others, but finding tutorials can be a pain since it all these are JS first frameworks.
I'm actually working on one. I don't know what will come out of it, but it's an interesting endeavor. As soon as it's shareable I will share it on Github.
I'm basically trying to do a superset of typescript where you create elements so:
Was that what you meant?
I'm basically trying to do a superset of typescript where you create elements so:
const root = c({
el: 'div',
children: [
`hello, ${store.user.name}`
],
attr: {
class: 'bold smart',
id: 'abc',
bla: true,
},
evts: {
click: () => {
console.log("Clicked")
}
}
});
Was that what you meant?
What you’ve written there couldn’t possibly be reactive without compilation or wrapping it in a function. Is there something else wrapping it (a function), or is it being compiled into a different form? If it’s being compiled (so that the code means something other than it seems to), then I see no particular advantage to using TypeScript syntax, given it’s more verbose than need be.
For reference, in Svelte that’d be something like this, which is shorter and more obvious:
For reference, in Svelte that’d be something like this, which is shorter and more obvious:
<div class="bold smart" id="abc" bla={true} on:click={() => { console.log("Clicked") }>
hello, {store.user.name}
</div>Yes, that's currently what I'm experimenting with.
This is very early stages and completely experimental.
The idea I'm experimenting is to compile typescript to another form, I completely see your point about too verbose though, but I'm also toying around with jsx.
Basically what I'm trying to do is a svelte where instead of this:
Again, this is completely in the early stages and just playing around until something feels right.
Any recommendations appreciated.
This is very early stages and completely experimental.
The idea I'm experimenting is to compile typescript to another form, I completely see your point about too verbose though, but I'm also toying around with jsx.
Basically what I'm trying to do is a svelte where instead of this:
{#each cats as { id, name }, i}
<li>
<a target="_blank" href="https://www.youtube.com/watch?v={id}">
{i + 1}: {name}
</a>
</li>
{/each}
Again, this is completely in the early stages and just playing around until something feels right.
Any recommendations appreciated.
That is awfully verbose.
I'll hopefully add jsx eventually that will help with the visual aspect of the verbosity.
What's wrong with being verbose?
You need to write more, you need to read more, and whoever maintains your code will need to read more. More chances for typos. That means more time wasted for everyone.
Why do you think we have async/await now instead of manually typing out all the promise syntaxic mess every time?
Why do you think we have async/await now instead of manually typing out all the promise syntaxic mess every time?
because handling a promise using .then/.catch creates a new block? verbosity isn’t an issue as much as being too terse, especially with macros
lit-html is written in TypeScript, so has great typings.
There are TypeScript plugins to statically analyze the templates, like lit-analyzer and the lit-plugin VS Code extension.
LitElement provides TypeScript decorators for declaring reactive properties and more.
There are TypeScript plugins to statically analyze the templates, like lit-analyzer and the lit-plugin VS Code extension.
LitElement provides TypeScript decorators for declaring reactive properties and more.
While it is writen in typescript, it's still aimed towards JS first.
I'm not exactly sure what you mean then.
TypeScript doesn't in general change its emit based on types, so its runtime feature set is exactly the same as JavaScript.
lit-html has a TypeScript compiler plug-in which provides template type=-checking, and LitElement provides decorators, like I said. How would something be more aimed at TypeScript, and not JavaScript?
TypeScript doesn't in general change its emit based on types, so its runtime feature set is exactly the same as JavaScript.
lit-html has a TypeScript compiler plug-in which provides template type=-checking, and LitElement provides decorators, like I said. How would something be more aimed at TypeScript, and not JavaScript?
^ why you shouldn't use supersets
Having a hard time choosing between Svelte and Elm. For a lone in house dev, any recommendations?
I used Svelte 3 for a fairly complex side project last year (rewrote it from React), and it's my favorite JS framework so far. I do wish the TypeScript story was better though.
I've also used Elm for another little side project, and it was super fun to learn, but it was a bit mind-bending at first.
I think Svelte is a fairly safe choice because it's actively developed and because it's not too different from Angular/React/Vue.
If there's any possibility that you'll have to hand this code over to someone else, I think Elm is a much less safe choice.
So, to echo tomerbd's reply: Elm for fun; Svelte for profit.
I've also used Elm for another little side project, and it was super fun to learn, but it was a bit mind-bending at first.
I think Svelte is a fairly safe choice because it's actively developed and because it's not too different from Angular/React/Vue.
If there's any possibility that you'll have to hand this code over to someone else, I think Elm is a much less safe choice.
So, to echo tomerbd's reply: Elm for fun; Svelte for profit.
Just a reminder that Svelte, in Rich Harris's own words, is a language and not a framework. It technically isn't JavaScript, just an incredibly similar syntax.
Try F#. Has good tooling and its possible to use the ELM arch. See https://zaid-ajaj.github.io/the-elmish-book
Thank you this looks great. Okay now another tool to try. This is tricky business when you're looking for the tool set you want to invest in for the next 2 to 5 years and there are so many promising options.
Plug Elm compiler into Svelte to create a monster, ensure your name will be cursed by those who follow you.
I picked up Svelte recently and I am happy with it. There is good documentation and examples and any questions I had were already answered online.
I haven't used Elm yet.
I haven't used Elm yet.
I'd say Svelte is much closer to "regular" programming. You will have to bend your thinking a bit with Elm.
Svelte seems great, but it seems to be developed by one person primarily. Also, that person lives in NY and the project looks paused at the moment.
Svelte seems great, but it seems to be developed by one person primarily. Also, that person lives in NY and the project looks paused at the moment.
Looking at the Github commits I’d say neither statement is true? Seems to be plenty of contributors that have contributed recently:
https://github.com/sveltejs/svelte/commits/master
https://github.com/sveltejs/svelte/commits/master
It just had a major release :P any faster and people would be complaining about churn !
What makes you say it looks paused? There’s been a very steady stream of releases since the big 3.0 launch last spring. There’s certainly more than one active contributor, although the core team is just a few people.
By "regular" programming do you mean JavaScript?
p.s. Svelte is great, and I can't wait to start working more actively with it.
arkanciscan(1)
While I primarily use Elm for all my front end side projects, I do think it's worthwhile to try both.
I'm currently writing a blog about trying as many front end frameworks/languages as I can. I'm going with this approach because I want to see what I can learn from each of them. For example, I've learned from Elm that compilers can be much friendlier. I've learned from Svelte that people are more willing to accept what appears to be familiar.
You may learn something completely different.
I'm currently writing a blog about trying as many front end frameworks/languages as I can. I'm going with this approach because I want to see what I can learn from each of them. For example, I've learned from Elm that compilers can be much friendlier. I've learned from Svelte that people are more willing to accept what appears to be familiar.
You may learn something completely different.
The problem with Svelte is it doesn't support Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs. Vue has a similar problem (it sort of supports Typescript, but not properly and templates aren't type checked).
I've not used Elm so maybe that is better. React has good support for type checking. I would use that.
I've not used Elm so maybe that is better. React has good support for type checking. I would use that.
I’ve had success with extracting as much logic as I can out of .svelte files and putting them in .ts and importing. At this point the JS logic in my svelte files is almost exclusively view lifecycle stuff. It’s not perfect but it works well enough for me, and I prefer the output to what I’d get with React.
> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs
I'd say it depends on your teams skill set and level of disciple. The best defence against a buggy codebase isn't a programming language or framework, its good all fashioned discipline.
I'd say it depends on your teams skill set and level of disciple. The best defence against a buggy codebase isn't a programming language or framework, its good all fashioned discipline.
I think we all agree on this, but we don't all agree that "just be disciplined" works in practice.
"Just don't write bugs", "just write perfect code", etc
Given that you and your team has all the discipline you need, you could still argue that type checking the codebase in your head is time consuming and is better spent on higher level concepts.
A typesystem can get in the way and slow down development if it's too strict of course, but I feel typescript does a good job of keeping it optional enough.
There is no clear answer here, but at least refactoring is much easier and safer given that your types are sound.
"Just don't write bugs", "just write perfect code", etc
Given that you and your team has all the discipline you need, you could still argue that type checking the codebase in your head is time consuming and is better spent on higher level concepts.
A typesystem can get in the way and slow down development if it's too strict of course, but I feel typescript does a good job of keeping it optional enough.
There is no clear answer here, but at least refactoring is much easier and safer given that your types are sound.
> "Just don't write bugs", "just write perfect code", etc
You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code.
> you could still argue that type checking the codebase in your head is time consuming
This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familliar with C#, while CoffeeScript fits very well to those comfortable with python/ruby, ClojureScript for those who like clojure, ESLint for those comfortable with JS ... etc
You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code.
> you could still argue that type checking the codebase in your head is time consuming
This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familliar with C#, while CoffeeScript fits very well to those comfortable with python/ruby, ClojureScript for those who like clojure, ESLint for those comfortable with JS ... etc
> I do not believe that you can write perfect code or avoid bugs.
I don't think anyone (including you) does. I don't think typescript pretends to be a perfect programming language that magically creates clean code either, but I think it gets us closer to that unrealistic goal.
> This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familiar with C#.
I very much disagree with this.
If you want to compare Typescript with another language, you have to remember that its typesystem is optional. So all you are left with basically Javascript. How much of the typesystem you want to use is up to you and your team.
Personally I try to let typescript infer the types as much as possible. I only explicitly annotate function arguments and foregin data. Sometimes there are cases where the typesystem won't work. Usually it's because I want to dynamically create something instead of verbosely defining everything. If the dynamic way is easier to maintain I choose that way and may lose some type information. (often you can tell the typesystem that "this dynamic blob" results in "this explicit type" though)
I'm not very fond of C# but I enjoy Typescript. I think the reason I don't like C# is because it forces you to make classes of everything which to me adds a lot of friction.
I don't think anyone (including you) does. I don't think typescript pretends to be a perfect programming language that magically creates clean code either, but I think it gets us closer to that unrealistic goal.
> This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familiar with C#.
I very much disagree with this.
If you want to compare Typescript with another language, you have to remember that its typesystem is optional. So all you are left with basically Javascript. How much of the typesystem you want to use is up to you and your team.
Personally I try to let typescript infer the types as much as possible. I only explicitly annotate function arguments and foregin data. Sometimes there are cases where the typesystem won't work. Usually it's because I want to dynamically create something instead of verbosely defining everything. If the dynamic way is easier to maintain I choose that way and may lose some type information. (often you can tell the typesystem that "this dynamic blob" results in "this explicit type" though)
I'm not very fond of C# but I enjoy Typescript. I think the reason I don't like C# is because it forces you to make classes of everything which to me adds a lot of friction.
TS may compile down to JS, but that does not make it the same language. TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way. How you structure your code using a dynamic, functional language should be very different from how you structure your code in a static, object oriented language. If your code structure looks more or less just the same between the two, then you are doing one of them wrong.
> you have to remember that its type system is optional
Doesn't opting out of the type system defeat the purpose of using TYPE-script in the first place?
> you have to remember that its type system is optional
Doesn't opting out of the type system defeat the purpose of using TYPE-script in the first place?
> TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way.
Where do you get the idea that Typescript code should be structured like a static object oriented language? Is it because it's a Microsoft product?
Letting Typescript try and figure out the types while coding in a "dynamic and functional way" is what works best for me. Is this wrong?
Where do you get the idea that Typescript code should be structured like a static object oriented language? Is it because it's a Microsoft product?
Letting Typescript try and figure out the types while coding in a "dynamic and functional way" is what works best for me. Is this wrong?
As a “life long” web/JavaScript developer, ESLint is nowhere near comparable to Typescript. One is a language, and the other is an (overused and over configured) linter. They’re two different things.
I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language.
Typescript is a superset of JavaScript, and is remarkably close. If you know JavaScript, typescript will be exceptionally similar because it’s literally the same, just with types added on top.
I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language.
Typescript is a superset of JavaScript, and is remarkably close. If you know JavaScript, typescript will be exceptionally similar because it’s literally the same, just with types added on top.
I have worked with two compile to JS languages, CoffeeScript and TypeScript.
> One is a language, and the other is an (overused and over configured) linter.
You could also say that one is an extremely opinionated linter and the other is just a linter.
> One is a language, and the other is an (overused and over configured) linter.
You could also say that one is an extremely opinionated linter and the other is just a linter.
No, I would not say that a type system is an "extremely opinionated" linter because TypeScript is about proving correctness and safety, not enforcing style guidelines.
A linter and a type system are two extremely different things. The only thing they have in common is that they statically analyse code.
A linter and a type system are two extremely different things. The only thing they have in common is that they statically analyse code.
It's not just about bugs. Static typing is crucial for productivity whenever the codebase overflows your brain's working memory.
Navigating through code, refactoring, or simply figuring out what to pass as function input can become a challenge in the absence of types.
Navigating through code, refactoring, or simply figuring out what to pass as function input can become a challenge in the absence of types.
That's why god invented comment blocks. But some people view them as code smell, which i find very strange. And no, good naming is not always enough.
So you're saying it's a good idea to write what your types are in your code, but rather than writing them in a form that can be automatically checked by a computer and used for code completion and refactoring, you prefer to write them in a comment?
No, I said no such thing. If you happen to be in a dynamic environment, then yes, I see no foul in describing inputs to a function inside a comment above function declaration. Use comments to describe your intents on non trivial parts of your code. There is no amount of code readability that will help your colleague, if she doesn't understand your thought process at the time of writing the code.
"not always enough" is still better than "none". This feels like a classic "good being the enemy of the perfect" issue.
Don’t need to catch bugs if you just don’t write them! taps head.
It is still worthwhile imo to have something that catches mistakes even great people make.
It is still worthwhile imo to have something that catches mistakes even great people make.
I completely agree. That something is a linter, of which TypeScript is just one of the many options available. This whole idea of you cannot write a big app in JS is just peddled by those who do not understand, or hate JS. A good linter, proper programming practices, discipline will get you there. Anytime someone peddles a language or framework as a magic bullet to clean code, they're either selling you some snake oil or have drunk too much of some koolaid, imho.
This is the kind of attitude that has resulted in a million code vulnerabilities in C because the idea that it's inherently unsafe is just an idea 'peddled by people unskilled in its application' (to re-express nicely). It's the kind of attitude which will ignore the many inconsistencies in languages which were the result of historical accident instead of good design because it's just a blind acceptance of the way things turned out to be rather than what they _could_ be. Many who go on about 'discipline' are often creating error prone applications and, ironically, peddling 'discipline' as that very magic bullet to cure all ills.
I don't know if I've even seen discipline defined beyond some self-referential 'avoid doing these bad things that our language/environment allows by knowing that they're bad before you make the mistakes that show you they're bad'. Do developers just shrug and accept it as a fundamental design constraint to good programming languages when their booleans add with their integers and concatenate with their strings and give essentially random results? Do they not wonder: is there a system, more fundamental than linting, which can solve many of these issues in a general case?
I don't know if I've even seen discipline defined beyond some self-referential 'avoid doing these bad things that our language/environment allows by knowing that they're bad before you make the mistakes that show you they're bad'. Do developers just shrug and accept it as a fundamental design constraint to good programming languages when their booleans add with their integers and concatenate with their strings and give essentially random results? Do they not wonder: is there a system, more fundamental than linting, which can solve many of these issues in a general case?
The idea that "A good linter, proper programming practices, discipline will get you there" has resulted in "a million code vulnerabilities in C" !!
That is a surprising jump in cause-and-effect logic right there. I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. But, picking a whole new programming language instead is just lying to yourself, because there is no perfect programming language.
None! Zero. Not one, no matter how much in love you are with it. They all have their warts, strengths and weaknesses, and if you are not aware of any in your language of choice, and actively working to avoid and mitigate against them (aka discipline and best practice) then you have fallen prey to exactly what I was talking about: the idea that a framework or language is a magical silver bullet to writing clean code. If you thought I was saying JS (or C, TypeScript, Haskel etc) is this perfect, wonderful language, you completely misunderstood me.
That is a surprising jump in cause-and-effect logic right there. I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. But, picking a whole new programming language instead is just lying to yourself, because there is no perfect programming language.
None! Zero. Not one, no matter how much in love you are with it. They all have their warts, strengths and weaknesses, and if you are not aware of any in your language of choice, and actively working to avoid and mitigate against them (aka discipline and best practice) then you have fallen prey to exactly what I was talking about: the idea that a framework or language is a magical silver bullet to writing clean code. If you thought I was saying JS (or C, TypeScript, Haskel etc) is this perfect, wonderful language, you completely misunderstood me.
> I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest.
And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities.
It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should be disciplined enough to not make mistakes in the first place!".
In an ideal world they would be, but in this world, they're not and never will be.
Not being able to admit this is how you end up with surgery on your left knee when it was meant to be your right.
Accept that no-one is 100% perfect, 100% of the time - let alone you - and mould your development around these (very human) failings. "Disciplined programming" will never be as safe as "disciplined programming with guard-rails built into the language". Weigh up the trade-offs - sometimes the performance gain is worth the risk, sometimes it's not.
And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities.
It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should be disciplined enough to not make mistakes in the first place!".
In an ideal world they would be, but in this world, they're not and never will be.
Not being able to admit this is how you end up with surgery on your left knee when it was meant to be your right.
Accept that no-one is 100% perfect, 100% of the time - let alone you - and mould your development around these (very human) failings. "Disciplined programming" will never be as safe as "disciplined programming with guard-rails built into the language". Weigh up the trade-offs - sometimes the performance gain is worth the risk, sometimes it's not.
> And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities.
This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?!
good practice and discipline ≠ misplaced confidence
This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?!
good practice and discipline ≠ misplaced confidence
You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.
> You appear to assume
I like your choice of words, but no. I disagree with that assumption.
I like your choice of words, but no. I disagree with that assumption.
Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.
You're making a false dichotomy here. There's a lot of light between something being a magical silver bullet that solves all your problems and every programming language being equally bad. If that weren't the case we would probably have never progressed from unstructured programming.
In general the greatest progress in software engineering practice at the level of programming languages is made when something that was previously left up to human discipline is made automatic so we don't have to struggle with it anymore: memory safety, type checking, and at the beginning, returning from subroutines at a structured location back to a structured location instead of control flowing wildly throughout a program with jumps.
Yes, it's theoretically possible to do all these things well without the assistance of a computer, but in practice, it's more work than any human can handle. The problems that newer programming languages have are an argument for fixing those problems, not reintroducing ones we've already solved.
In general the greatest progress in software engineering practice at the level of programming languages is made when something that was previously left up to human discipline is made automatic so we don't have to struggle with it anymore: memory safety, type checking, and at the beginning, returning from subroutines at a structured location back to a structured location instead of control flowing wildly throughout a program with jumps.
Yes, it's theoretically possible to do all these things well without the assistance of a computer, but in practice, it's more work than any human can handle. The problems that newer programming languages have are an argument for fixing those problems, not reintroducing ones we've already solved.
> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs.
This is the original grandparent comment I was responding to. To me, this sounds like the belief that only one language can solve a problem which I disagree with. TypeScript is not a silver bullet. They are all just tools. Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana.
> ...and every programming language being equally bad.
I simply did not say that.
This is the original grandparent comment I was responding to. To me, this sounds like the belief that only one language can solve a problem which I disagree with. TypeScript is not a silver bullet. They are all just tools. Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana.
> ...and every programming language being equally bad.
I simply did not say that.
>I simply did not say that.
No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong.
>To me, this sounds like the belief that only one language can solve a problem which I disagree with.
I disagree with that interpretation too, but the argument they were actually making was about static type systems, as evidenced by their comment about React and the importance of type checking. TypeScript is merely the most popular typed JavaScript variant.
>TypeScript is not a silver bullet.
Sure, I would actually prefer a much stronger type system than it provides, but it's certainly better than nothing.
>They are all just tools.
Sure, but some tools work better than others.
>Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana.
I didn't see the grandparent preaching about "code nirvana" at all. They were making a pretty typical argument about the outsize effectiveness of static types in large codebases. It's entirely possible that programming in a large codebase with TypeScript sucks, but that programming in a large codebase with JavaScript sucks more. There is no perfect programming languages, but there are definitely better ones.
No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong.
>To me, this sounds like the belief that only one language can solve a problem which I disagree with.
I disagree with that interpretation too, but the argument they were actually making was about static type systems, as evidenced by their comment about React and the importance of type checking. TypeScript is merely the most popular typed JavaScript variant.
>TypeScript is not a silver bullet.
Sure, I would actually prefer a much stronger type system than it provides, but it's certainly better than nothing.
>They are all just tools.
Sure, but some tools work better than others.
>Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana.
I didn't see the grandparent preaching about "code nirvana" at all. They were making a pretty typical argument about the outsize effectiveness of static types in large codebases. It's entirely possible that programming in a large codebase with TypeScript sucks, but that programming in a large codebase with JavaScript sucks more. There is no perfect programming languages, but there are definitely better ones.
I get it. You like TypeScript, it works for you. You like and firmly believe in static types, also great. No one is asking you to stop using them, or suggesting that they are bad. They are all just tools, use the ones that work for you. Personally, I do not need TypeScript, ESlint gets me there, but then again I'm not you. Just like I'm not going to assume your code is completely perfect and bug free because you use tool X, you should not assume mine is bad and buggy because I use tool Y.
I’m not assuming it’s bad and buggy code. My day job is writing Elixir, albeit with full type spec coverage, and the code is fine. But that’s enabled by an extensive test suite, as well as type specs. Do we need these things, strictly speaking? No. But we don’t really need any of the tools we build and use, yet we build them because they make certain things easier and more reliable.
My code is not perfect and bug free when I write it in a strongly typed language, however it is guaranteed to be free of type errors provided the type system is sound. That level of confidence in types is just not possible in a dynamic language.
My code is not perfect and bug free when I write it in a strongly typed language, however it is guaranteed to be free of type errors provided the type system is sound. That level of confidence in types is just not possible in a dynamic language.
Typescript is not a product for teams of low skill of disciple, and it's pretty insulting to suggest it is.
That is certainly not what I was suggesting.
You literally said "[Whether you need Typescript or not] depends on your teams skill set and level of disciple".
level of discipline ≠ low discipline
I think you mean “old fashioned”... which goes to show that even skilled, disciplined, knowledgeable folks can make simple mistakes. When the stakes are high, it’s important to use tools to augment human judgement.
I'd say Elm has support for types, yes =D
IIRC, Vue 3 uses Typescript.
Prezi, the original company that backed Elm, laid-off the maintainer and then deprecated Elm in their codebase.
I wasn't aware of that context.
Though evancz now works at NoRedInk. https://www.noredink.com/about/team
Though evancz now works at NoRedInk. https://www.noredink.com/about/team
Their approaches and style are completely different. Try both.
If you haven't yet, find and read the lengthy "why I'm leaving elm" post; there's a big discussion here also. May provide some impetus one way or the other for you.
Use Elm for fun and React/Svelte for Profit
I skimmed through it, but couldn't find a description of the distinguishing feature of svelte, i.e. how the incremental updates are performed.
From the same author, you may find this useful:
https://lihautan.com/compile-svelte-in-your-head-part-1/
I think the idea is to provide the programming model that React allows via its virtual DOM, but compile all that code away, so you end up with code das works without a virtual DOM.
Direct DOM interactions are faster and you don't have to bring a whole VDOM library.
Direct DOM interactions are faster and you don't have to bring a whole VDOM library.
It's actually really easy to read the svelte compiler output! You'll see exactly how it works :P
I assume people downvoting this comment are not familiar with Svelte?
You can in fact see how it works by looking at the output. Go to the REPL at https://svelte.dev/repl/hello-world and select “JS output”.
You can in fact see how it works by looking at the output. Go to the REPL at https://svelte.dev/repl/hello-world and select “JS output”.
I really like that Svelte does compiler time dependency analysis such that there is less work to do runtime.
Can we bring this ideas to react and Vdom based frameworks? I imagine Babel/typescript can analyze jsx to find which attribute are bound to a variable and which are just static. The static ones don’t need to be diffed, only the dynamic ones.
Can we bring this ideas to react and Vdom based frameworks? I imagine Babel/typescript can analyze jsx to find which attribute are bound to a variable and which are just static. The static ones don’t need to be diffed, only the dynamic ones.
You don't need a compiler to do that. lit-html does this at runtime, and the benefit from not diffing static content is large.
at compiler time, you can type check and statically validate. Doing things at runtime with lit-html where things are in a string, quickly falls apart in a large project. One of my biggest griefs with Angular was that you could miss an ending tag in the template and it would work fine until it blows up in production when a customer accesses that specific scenario.
I stay away from magic templates compiled at runtime. I've been bitten way too many times. Plus it's not good for load performance when you have to ship a string compiler with your code.
I stay away from magic templates compiled at runtime. I've been bitten way too many times. Plus it's not good for load performance when you have to ship a string compiler with your code.
How do you think lit-html templates would fall apart? There's nothing magic about them. They has as defined semantics as HTML or JavaScript - both of which are languages written as strings.
We use lit-html in thousands of components at Google with very strict type-checking and linting. You simply aren't allowed to miss an end tag, or bind to a non-existent attribute or property. The performance and code size are excellent, beating every major framework including those using compilers. The "compiler" we use is simply the HTML <template> element and a tree-walk. It's very, very fast and very, very small.
We use lit-html in thousands of components at Google with very strict type-checking and linting. You simply aren't allowed to miss an end tag, or bind to a non-existent attribute or property. The performance and code size are excellent, beating every major framework including those using compilers. The "compiler" we use is simply the HTML <template> element and a tree-walk. It's very, very fast and very, very small.
Very clear and crisp overview of the compilation process!
Nice to see excalidraw.com used for the illustrations!
Your article on it is great!
https://blog.vjeux.com/2020/uncategorized/reflections-on-exc...
https://blog.vjeux.com/2020/uncategorized/reflections-on-exc...
Yes! it's very nice and easy to draw illustrations with it!
Great work on the tool!
I’ve been working on a side-project, that allows recording and playing back interactive, guided walkthroughs of a codebase. This seems like an excellent “test case“ for that experience, which I might have to experiment with :)
https://aka.ms/codetour.