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 haven't used Elm yet.
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.
I'm sure you are a very nice person but it is possible someone out there thinks you're a jerk despite that.
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've not used Elm so maybe that is better. React has good support for type checking. I would use that.
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.
"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.
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 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.
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.
> 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?
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?
I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language.
> 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.
A linter and a type system are two extremely different things. The only thing they have in common is that they statically analyse code.
Navigating through code, refactoring, or simply figuring out what to pass as function input can become a challenge in the absence of types.
It is still worthwhile imo to have something that catches mistakes even great people make.
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?
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.
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.
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
I like your choice of words, but no. I disagree with that assumption.
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.
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.
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.
>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.
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.
Give me an example of a sound type system.
Software Testing Life Cycle? That is not a type system, that is a software development methodology. Thought you'd mention atleast TypeScript or Elixir, but no, you went for the a whole software development methodology. Which kind of puts you in a bind now, since you also said: "..it is guaranteed to be free of type errors provided the type system is sound". So where does that leave us if you cannot confidently give an example of a sound type system?
> That level of confidence in types is just not possible in a dynamic language.
Not possible with static languages either, unless ofcourse you use the whole "Software Testing Life Cycle". Do you know what I like most about STLC? It advocates what I have been saying all along: discipline and best practice!!!
And you can use STLC with dynamic languages to and get the same benefits.
>> Software Testing Life Cycle?
Ok. Since you were saying things like "..that’s enabled by an extensive test suite, as well as type specs" I assumed it must be something to do with testing. Must be a programming language I've never heard about then.
Though evancz now works at NoRedInk.