16 ms·

I'm tired of having to learn yet another templating language without a very compelling reason. Why do I have to learn, what is essentially, a new programming l

I'm tired of having to learn yet another templating language without a very compelling reason. Why do I have to learn, what is essentially, a new programming language for each of these frameworks (Angular, Svelte, Vue, React... Do I really need to learn yet another language construct for stuff like `loops`, `if/else`, event handlers...etc. Why must all of these frameworks re-invent the wheel? At least with React it is most close to the languages we already have learned, JavaScript, and HTML. From what I can tell Svelte looks similar handlebars templating with it's own unique syntax variations... I can't count how many different versions of the same thing I've had to relearn again, and again.

d23 5y ago
As a backend guy who moved away from frontend long ago for these very reasons, I have to ask: why are people downvoting this? Is it wrong? I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.
- SparkyMcUnicorn 5y ago
  I didn't downvote, but I'll speak to my experience. First off, you don't have to go learning every framework out there. Pick one and stick with it, or just go vanilla. That said, The features these frameworks provide gives a boost in productivity that far outweighs the low learning curve. My pick was VueJS and I'm very happy with it. Using Single File Components is pretty similar to vanilla HTML/JS/CSS. Beginners that were under my guidance (with only HTML/CSS/JS experience) usually pick it up and were productive in the same day. I disagree that React (JSX) is most similar to vanilla JS/HTML at all (I don't prefer it, but to each their own). Vue and Svelte are much further on the side of a vanilla-ish approach.
  - spoils19 5y ago
    Frontend developers like to change frameworks every week it seems like, so it's in my best interest to learn every framework (or at least some abstracted part of it) in order to stay employable and up-to-date. The problem is that each framework has their own abstraction and language that you have to learn. Compare it to "old-school" Java frameworks, where things were much simpler and you didn't have to worry about egregious layers of complexity to just render a DOM. Grumble grumble
    - l30n4da5 5y ago
      > Frontend developers like to change frameworks every week it seems like Most of the popular frontend frameworks (Vue, React, Angular, Svelte) have been around for years at this point. It is like arguing Ruby on Rails vs Spring Boot.
    - mikewhy 5y ago
      > Frontend developers like to change frameworks every week it seems like This sentiment is so old and played out.
      - 2muchcoffeeman 5y ago
        Is it false though? If it’s true, then maybe we need to look at why it’s true. It’s not just front end developers though. I think other domains and their frameworks went through the same thing. This is just the time for front end.
        vosper 5y ago
        Yes, it is false. Anyone in the space can tell you how stable things have been for years now. Plus, there are a lot of people writing JS. It’s not a tiny community fracturing itself over different ways of doing things, and becoming destined for obscurity. It’s tens or hundreds of thousands of developers. In a community this big I’d say having a few choices is a sign of health.
        tshaddox 5y ago
        Indeed, it’s false. React is 8 years old, and when React was first released jQuery was only 7 years old. I follow this stuff pretty closely and I can only think of maybe 10 JS UI frameworks that have attracted remotely significant use and active development at any point in the past 15 years.
        2muchcoffeeman 5y ago
        Java is 26. Spring is 19. Struts 2 is 15. Python is 30. Django is 16. I’m just picking a few frameworks and languages I’ve used in the past and are still used. Obviously there are still new frameworks and libraries that come out for these languages. But sometimes the big projects fold those in. Or they write their own or whatever. I can pick the popular names and do pretty much what I need. JavaScript is 25. But most of that time we weren’t doing what we can now. And most frameworks are fairly young. Angular is 11. But most people (and jobs) have jumped ship to React(8) and now there is Svelte(4) which also looks good. And I think there will be more changes to come. These JS frameworks aren’t exactly veterans that are impossible to supplant. Not yet anyway.
- wishinghand 5y ago
  It's a false truth that anyone has to learn yet another one of these. Even Angular 1 and Backbone.js are still in production.
  - sergiotapia 5y ago
    So is Joomla - yet I wouldn't recommend people learn it today. Might as well learn COBOL and Zend Framework too.
    - cutler 5y ago
      Ah, Zend - the only framework to out-boilerplate Spring MVC.
      - DonHopkins 5y ago
        Naw, the Python/Zope/ZODB/CMF/Plone/TAL/MeTAL/TALES stack can out-boilerplate the yin-yang out of Zend. Each of those Dagwood Sandwich layers has its own special purpose object system that leaks abstracts to all of the other layers, and its own domain specific languages for writing boilerplate that sprays those abstraction leaks all over the place. ;) https://en.wikipedia.org/wiki/Dagwood_sandwich https://en.wikipedia.org/wiki/Dagwood_sandwich
- locallost 5y ago
  It might be true, but it's a rant that just barely touches the actual topic, which is mostly: a company will pay somebody to work full time on an open source project that is still independent. And I think it's pretty nice. And also I think Rich Harris has given a lot to people for free and I'm happy for him that he will be paid to work on something that he loves. So all in all it would be nice if we would for once be spared of rants how tiring, immature, half baked whatever whatever the JavaScript world is. Show us maybe how it should be really done, but maybe in a separate post please.
- rglover 5y ago
  No, it's not wrong, it's absolutely correct. There's a lot of flexing around who can come up with the most elegant abstraction which ignores the important point: making sure what's necessary to understand the framework, use it long-term, and move away from it after is focusing on the core technologies of the web (HTML, CSS, and JavaScript). The abstractions are cool, but completely unnecessary (see link to my framework above where I circumvent that problem entirely).
  - jessaustin 5y ago
    The parenthetical makes the comment!
    - rglover 5y ago
      I applaud your sarcasm and award it 10 points.
- sam0x17 5y ago
  Well in this case, it's more that svelte is the least of all evils when it comes to this. React and Vue have way more boilerplate and React in particular has the most framework-specific stuff of them all. Svelte is much closer to pure html/css, or so I'm told.
- ramesh31 5y ago
  > I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community. Perhaps not in the "frontend community", no it hasn't slowed down. There will always be new frameworks coming and going, and people will work on them as fun open source projects or use them in their side projects or whatever. But people doing real work are almost unanimously settled upon React as an industry standard at this point. There's still a decent sized faction of contrarian Vue holdouts, but by and large the JS framework wars are over.
- lowbloodsugar 5y ago
  Didn't downvote either. Almost consider upvoting for visibility of the hilarity displayed. "There are too many frameworks! Why does everyone keep re-inventing the wheel? Why can't everyone just use the one that I like?"
  - cphoover 5y ago
    I never asked anyone not to use svelte... I said why should I be compelled to learn this new language, other than it being the hot new UI framework of the day. It doesn't have a virtual DOM? It doesn't have synthetic events? Ok why not just use web components which provide their own encapsulation and vanilla JS. I don't have to learn a new language which may or may not be around/supported a few years from now... Also I'm continuing to grok web standards.
    - d1sxeyes 5y ago
      You’re right, you don’t have to! Who is forcing you to? Rich Harris is going to work for Vercel, who are arguably most famous for Next.js, which is… React.
- tshaddox 5y ago
  I don’t know about “wrong,” but my opinion on the overall theme of that first comment is that the requirement to learn is not at all a bad thing. I enjoy learning new things even when that is in some sense a “requirement.”
- winphone1974 5y ago
  I assume because there's no value to it. What's the opposite side of the argument? You have an area with a lot of growth and many problems with the way we're solving these problems and something like svelte is not"completely reinventing the wheel" as the OP positions it, by nature it's try to solve specific problems using our existing tooling whenever possible. The original post is a shallow, feel-good rant
- fendy3002 5y ago
  I've used react for some years now and it's very very hard to do animation and event-driven operations with pure react render. You'll need extensive lifecycle events or hooks and refs to get animation or handle focus, etc well. It's due to how react render the components. It doesn't make react bad but I guess some newer frameworks (vue, svelte, I haven't learned those yet) try to tackle this from different approach.
- ratww 5y ago
  It is wrong because it has slowed down to a crawl compared to what we had from 2010-2014. Most companies have settled on either React or Vue, which are extremely similar. Angular is used in some niches, almost always because teams already knew it. Those three are responsible for almost 99% of the frontend positions you'll see. Svelte is getting popular but so far it's still niche. It's more of an inspiration for others, but also a contender. And really, what's so wrong about having more options and more competition? Even if you want to stop learning new things, there'll be no shortage of job vacancies for the three frameworks above. Also, since you're a backend dev, there are much more backend languages in use today than frontend frameworks, to give an example. And it's not hard to find companies using more than one.
- cutler 5y ago
  It sounds like you'd be better off with something like Ruby's Hotwire/Stimulus, ASP.Net Core/Blazor or Elixir/Phoenix Live View.
- rk06 5y ago
  The comment is negative and incorrect all of the js frameworks mentioned are view layer libraries. i.e. they create html. Hence they need a DSL for writing templated html, which will be used for generating final html Hence, it is completely natural for them to offer a custom DSL as html does not have standard way of expressing those concepts. Since each js framework has its own idiosyncrasies and motivations, custom DSLs reflect it. If you were to go around and make a new js framework, you too are going to create a new DSL
RoboticWater 5y ago
For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code. And the reason these things change is because that's what needed changing. One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't think unfamiliarity is that damning a criticism. Maybe I'm just used to switching up languages on a regular basis, but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.
- fron 5y ago
  > but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task. I agree. As long as you understand the basic concepts, it's only a matter of learning the syntax, which is really not as big of a deal as the person you replied to is making it out to be.
  - cphoover 5y ago
    It's not a herculean task... I agree, until you've learned 10+ (angular, vue, svelte, wordpress/php, jade templates, laravel, underscore/lodash, handlebars/mustache, hugo, etc..) of these "super simple templating languages"! And keep them all straight. I have no problem learning a new language if there is a compelling reason. But If it's just additional shit I have to remember for no clear reason... No thanks... We can have a debate on unidirectional data flow vs 2-way binding, how each framework manages state changes, how opinionated each framework is... How mature and vibrant each developer community is... etc. These are all another discussion though. My question is why must we reinvent the wheel again and again.
    - bryans 5y ago
      You need to stop insisting that a wheel has been reinvented with Svelte. It shares 95% of the same DNA as other frameworks, with multiple improvements over them. So with that in mind, what you're actually suggesting is that the existing offerings were somehow perfect, and we don't ever need to improve on anything again. That is an absurd notion, especially given that the other frameworks have gone through MASSIVE changes since launch -- sometimes even complete rewrites, because they acknowledged they got it wrong the first time.
adamnemecek 5y ago
The templating language is the easiest thing to learn. The hardest is architecture.
tpict 5y ago
JSX is syntactic sugar for `React.createElement(...)` (most commonly), so React pretty much is plain JavaScript.
- kall 5y ago
  Yeah, It‘s my favorite templating abstraction because I could convert it by hand and so I don‘t really need to mentally model it as an additional layer.
rglover 5y ago
You'd like https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick. No special languages or syntax. Plain HTML, CSS, and JavaScript with the same reactive UI stuff in all the other frameworks. It's also part of a full-stack framework so you can whip up lightweight, fast apps. The best part is your skills are transferrable as I'm not introducing any domain-specific abstractions. You can go from learning HTML, CSS, and JS to this without any "gotcha" in the process.
tootie 5y ago
Any new language/framework trying to sell me on it's improved ergonomics should not bother showing me syntax and instead show me a stack trace. Vue is really concise and expressive but seeing a pile of node internals on every typo is infuriating.
- cphoover 5y ago
  Very true... How can I debug this thing when it breaks that's a great question. I wonder how sourcemaps work with svelte
hijodelsol 5y ago
For me Vue 3 with <script setup> get's pretty close to pure JavaScript/TypeScript. 90% of the code will be exactly like JS code, the only difference being the use of computed(), ref() and reactive() to achieve (something JS simply doesn't provide but is necessary for every non-trivial application). Your HTML code and CSS code are not mixed with JS and look and feel like the real thing as well. Other than the reactivity indication and the occasional onMounted(), etc. Vue 3 with <script setup> does away with all boilerplate and unidiomatic parts of Vue 2 and imo is the framework that most closely resembles pure HTML/CSS/JS while allowing for far greater productivity.
- kall 5y ago
  Are we still taking about vue <template>? I don‘t see how that is any way close to html when it has: custom conditional and loop syntax and semantics, arbitrary js expressions and a unique concept of scope?
  - Drew_ 5y ago
    It does have extra non-native features but the overarching <template /> <script /> <style /> format for single file components is plain HTML which makes it feel closer to vanilla than React.
    - kall 5y ago
      Yeah I never really understood this benefit. The file structure is irrelevant to me after 15 minutes, the nitty-gritty semantics of my code are causing me headaches and bugs forever. (I like working with all 3 current frontend frameworks btw, not trying to start a flamewar)
      - Drew_ 5y ago
        I like it because it separates layout, styling, and scripting while still collating them in the same file.
deleted 5y ago
[deleted]
brundolf 5y ago
I don’t love that aspect myself, but I have to point out that in Svelte’s case it is definitely not “without a very compelling reason”. The special build-time processing is the entire point of Svelte. Though personally I’d almost prefer it was a whole new language than a “kind of JS but with some (necessarily) new syntax”
- deleted 5y ago
  [deleted]
- cphoover 5y ago
  100% no more js frankensteins... Id prefer to learn a new language altogether
bryans 5y ago
This is very overdramatic and isn't actually based on reality. Svelte is far closer to vanilla JS/HTML than any other framework, while also using extremely similar patterns from the other modern frameworks. Yeah, it has some sugar, but it's not just some templating system any more than React is just some templating system, and the only "unique syntax" you could be referring to is the auto-subscription to stores using $, which is super convenient. You're acting incredibly disinformative, and have no legitimate basis for your assertions.
gherkinnn 5y ago
You don't need to know every framework. And that little bit of custom syntax is peanuts compared to how the rest of these differ. Even if Angular and React shared the same templating syntax, you'd still be left with 95% of work ahead of you.
block_dagger 5y ago
This is why I have focused on backend for the last decade.
Tarks 5y ago
Agreed, I thought we were past this with the 4th generation of these frameworks, this is like knockoutjs all over again. The moment the penny dropped for me was when I read something like this about React: "We realised that inventing our own Yet Another Binding Language that was less expressive than javascript was harder and worse than doing the work to put the relatively simple HTML constructs into Javascript"
- timeon 5y ago
  And then you have ended up with shadow DOM.
jitix 5y ago
I used to be full stack before the re-invention of wheel phenomenon got way out of hand in the js world. Keeping up with what’s going on with the ecosystem and employing the best practices became a huge chore that took time away from solving actual business problems. Turning away from front end let me concentrate time on learning devops, cloud, ml and other things that aren’t as volatile in terms of design patterns and that lets me design more high level solutions to problems and create more overall value. Maybe people just differ in how wide or deep information they could handle but I certainly can’t keep up with such a wide array of patterns and tools that do the same thing.
travisl12 5y ago
My solution is pretty easy to this problem: I don't.
dbbk 5y ago
React is a free for all, you can render pretty much anything you want at any time. With templating languages, the DOM output can be statically analyzed at build time, so the amount of work needed to diff the HTML output when things change at runtime can be dramatically shortened.
unclebucknasty 5y ago
The problem with each of these frameworks is that they make the mistake of surfacing the underlying standards like HTML and the DOM. This is why they look remarkably similar and can only possibly be incrementally better, at best. HTML and the DOM are still essentially modeled on static documents. Building apps that deal directly with these standards is an impedance mismatch that, remarkably, people keep trying to solve by adhering to those same standards, but in a slightly different way. Why should we know or care about HTML or the DOM? A robust, event-driven, component-based framework that manages the low level Web standards could offer true advancement.
- kall 5y ago
  What would that look like for you? Something like SwiftUI or Flutter (which feel React inspired) or a totally different thing?
  - unclebucknasty 5y ago
    Yes, these are moving in the right direction, but have a ways to go and are heavy for what they do. Visual Basic of old may actually be a better example. Even reactive models are built around matching data to the DOM, essentially. And there's still too much wiring that's required. I think where we'll see the innovation here is in the no-code and low-code platforms, which will move away from the model of code frameworks to better componentize and abstract away the low-level details. They'll surface high-level interactions via an elegant event model, and automatically handle reactivity through easy to specify component-to-database bindings. The concept of a lower-level code framework will be replaced by that of a simplified abstract "environment" in which devs work.
    - kall 5y ago
      I like the database-to-component binding idea. If you squint, that‘s what a GraphQL/React app simulates (with mountains of boilerplate). I‘m not so sure about moving up the level of abstraction in the direction of no code tools. You can make it super easy to build the 1000s of CRUD apps we need today, but a dominant UI toolkit needs to be low-level enough so we can also build the kinds of apps we don‘t know about yet and the no code tools to make those apps. I think the component model popularized by react is here to stay for a while, especially because it fits in perfectly with the low/no-code tools, but everything around I can see improving.
chrbp 5y ago
No one says you have to learn new languages or frameworks. It's really your own choice.
danny_taco 5y ago
I completely agree with you, and I've yet to see a compelling argument against this. I've been doing this since the rise of the SPA, all the way from vanilla, jQuery, Backbone, Angular 1.0, Ember and React and after reading your comment all I can think of is "great, we're going back to handlebars templating again". There is no net-gain in re-inventing the wheel. It just becomes yet another thing to master to stay relevant. In a decade of doing JS front-end applications things have only gotten more complex and more time-consuming. Thankfully I've found a sweet spot where complexity, velocity and quality are in balance using technologies considered no longer cool and that's fine with me. I get to focus on the actual problem at hand instead of trying to figure out the inner workings of this new shiny thing.
- ratww 5y ago
  The youngest framework of your list is 8 years old already. Svelte itself is gonna be 5 years old in a couple weeks, and there's absolutely no need to pick it up right now. The meme that there are new frontends daily is extremely tired and has been totally false for several years now. Also the only thing those baseless complaints achieve are flamewars and shitting in other people's work.
  - kall 5y ago
    We moved on. Now there is a new javascript build tool written in a faster language daily (and I love them all).
- cutler 5y ago
  I think the pendulum may be swinging back with options like Rails/Hotwire, ASP.Net Core/Blazor and Elixir/Phoenix Live View. Let's hope so.
gaws 5y ago
You're getting flamed on Twitter for this comment lol: https://twitter.com/dancow/status/1458906853488967684 https://twitter.com/dancow/status/1458906853488967684
joppy 5y ago
Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.
- richeyryan 5y ago
  SolidJS[https://www.solidjs.com/ https://www.solidjs.com/] does exactly that. That ability is more about fine grained reactivity than it is about templates. The use of templates and single file components is a stylistic choice by the Svelte team. You could argue Solid has poor ergonomic compared to Svelte I guess.
- Aeolun 5y ago
  > I don't know how you could implement such a thing (with good ergonomics) without a template language. Parse Javascript? I don’t see how it would be any different, except you have more constructs to work through.
  - tshaddox 5y ago
    The "more constructs to work through" is precisely the problem. Without restricting JavaScript to some subset, you're not going to be able to statically determine the behavior of any given program.
miohtama 5y ago
Because if we do not keep constantly learning and get better, we would be stuck writing COBOL and BASIC.
- cphoover 5y ago
  haha fair enough! But I think, I'd rather learn an entirely new technology or language instead of every year having to learn a JS Frankenstein language! I kind of regret posting my OP now... as its turned into a bit of a flame war. It was not my intent. And I applaud people try and build anything new. I'm just ranting a bit about how it feels like UI development has a new framework/language/ecosystem every year or that is touted as the next big thing to supersede the rest! But then ends up reinventing much of the same constructs only with subtly different syntaxes.
intrasight 5y ago
They are all just trying to replicate XSLT - but by mixing imperative with declarative syntaxes.
deleted 5y ago
[deleted]
lhorie 5y ago
IMHO, syntax is the easiest part. Semantics are the tricky part. One very clear example of this is how Svelte and React deal with async stuff. The Svelte approach follows the handlebar approach of having semantics be represented by DSL constructs - which is a very reasonable approach IMHO. The Suspense semantics are so far off left field that someone literally wrote a whole framework specifically in response to its complexity[0]. And that complexity permeates every language construct used within a React component. Why can't we call hooks from inside if statements? Aren't if statements just JS? If you have to bring up React's internal implementation to explain, that's no longer "just Javascript", it's also a healthy chunk of very React-specific knowledge that you need to be aware of. Vue is another example that provides a successful story of a very large algorithmic migration from a reactive system to virtual dom with virtually no disruption to consumers, thanks to the abstraction provided by its DSL. In contrast, try telling my wife (who's learning about class components in her React course) that functional components and hooks "are just JS, what's the big deal", and see how far that takes you :) [0] https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
midrus 5y ago
I just don't get people complaining of trivial or superficial stuff such as how to do ifs, loops or binding handlers. When the most important part of these tools are the architecture, the trade offs, the state managements, the tools, the libraries and the ecosystem. Complaining just because of the syntax is just trying to convince yourself you don't like it. It's like when people just discard tailwind because they don't like how ugly many classes together look on the html, ignoring everything behind it which is what really matters (and that you can still like or dislike).

d23 5y ago

As a backend guy who moved away from frontend long ago for these very reasons, I have to ask: why are people downvoting this? Is it wrong? I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.

SparkyMcUnicorn 5y ago
I didn't downvote, but I'll speak to my experience. First off, you don't have to go learning every framework out there. Pick one and stick with it, or just go vanilla. That said, The features these frameworks provide gives a boost in productivity that far outweighs the low learning curve. My pick was VueJS and I'm very happy with it. Using Single File Components is pretty similar to vanilla HTML/JS/CSS. Beginners that were under my guidance (with only HTML/CSS/JS experience) usually pick it up and were productive in the same day. I disagree that React (JSX) is most similar to vanilla JS/HTML at all (I don't prefer it, but to each their own). Vue and Svelte are much further on the side of a vanilla-ish approach.
- spoils19 5y ago
  Frontend developers like to change frameworks every week it seems like, so it's in my best interest to learn every framework (or at least some abstracted part of it) in order to stay employable and up-to-date. The problem is that each framework has their own abstraction and language that you have to learn. Compare it to "old-school" Java frameworks, where things were much simpler and you didn't have to worry about egregious layers of complexity to just render a DOM. Grumble grumble
  - l30n4da5 5y ago
    > Frontend developers like to change frameworks every week it seems like Most of the popular frontend frameworks (Vue, React, Angular, Svelte) have been around for years at this point. It is like arguing Ruby on Rails vs Spring Boot.
  - mikewhy 5y ago
    > Frontend developers like to change frameworks every week it seems like This sentiment is so old and played out.
    - 2muchcoffeeman 5y ago
      Is it false though? If it’s true, then maybe we need to look at why it’s true. It’s not just front end developers though. I think other domains and their frameworks went through the same thing. This is just the time for front end.
      - vosper 5y ago
        Yes, it is false. Anyone in the space can tell you how stable things have been for years now. Plus, there are a lot of people writing JS. It’s not a tiny community fracturing itself over different ways of doing things, and becoming destined for obscurity. It’s tens or hundreds of thousands of developers. In a community this big I’d say having a few choices is a sign of health.
      - tshaddox 5y ago
        Indeed, it’s false. React is 8 years old, and when React was first released jQuery was only 7 years old. I follow this stuff pretty closely and I can only think of maybe 10 JS UI frameworks that have attracted remotely significant use and active development at any point in the past 15 years.
        2muchcoffeeman 5y ago
        Java is 26. Spring is 19. Struts 2 is 15. Python is 30. Django is 16. I’m just picking a few frameworks and languages I’ve used in the past and are still used. Obviously there are still new frameworks and libraries that come out for these languages. But sometimes the big projects fold those in. Or they write their own or whatever. I can pick the popular names and do pretty much what I need. JavaScript is 25. But most of that time we weren’t doing what we can now. And most frameworks are fairly young. Angular is 11. But most people (and jobs) have jumped ship to React(8) and now there is Svelte(4) which also looks good. And I think there will be more changes to come. These JS frameworks aren’t exactly veterans that are impossible to supplant. Not yet anyway.
wishinghand 5y ago
It's a false truth that anyone has to learn yet another one of these. Even Angular 1 and Backbone.js are still in production.
- sergiotapia 5y ago
  So is Joomla - yet I wouldn't recommend people learn it today. Might as well learn COBOL and Zend Framework too.
  - cutler 5y ago
    Ah, Zend - the only framework to out-boilerplate Spring MVC.
    - DonHopkins 5y ago
      Naw, the Python/Zope/ZODB/CMF/Plone/TAL/MeTAL/TALES stack can out-boilerplate the yin-yang out of Zend. Each of those Dagwood Sandwich layers has its own special purpose object system that leaks abstracts to all of the other layers, and its own domain specific languages for writing boilerplate that sprays those abstraction leaks all over the place. ;) https://en.wikipedia.org/wiki/Dagwood_sandwich https://en.wikipedia.org/wiki/Dagwood_sandwich
locallost 5y ago
It might be true, but it's a rant that just barely touches the actual topic, which is mostly: a company will pay somebody to work full time on an open source project that is still independent. And I think it's pretty nice. And also I think Rich Harris has given a lot to people for free and I'm happy for him that he will be paid to work on something that he loves. So all in all it would be nice if we would for once be spared of rants how tiring, immature, half baked whatever whatever the JavaScript world is. Show us maybe how it should be really done, but maybe in a separate post please.
rglover 5y ago
No, it's not wrong, it's absolutely correct. There's a lot of flexing around who can come up with the most elegant abstraction which ignores the important point: making sure what's necessary to understand the framework, use it long-term, and move away from it after is focusing on the core technologies of the web (HTML, CSS, and JavaScript). The abstractions are cool, but completely unnecessary (see link to my framework above where I circumvent that problem entirely).
- jessaustin 5y ago
  The parenthetical makes the comment!
  - rglover 5y ago
    I applaud your sarcasm and award it 10 points.
sam0x17 5y ago
Well in this case, it's more that svelte is the least of all evils when it comes to this. React and Vue have way more boilerplate and React in particular has the most framework-specific stuff of them all. Svelte is much closer to pure html/css, or so I'm told.
ramesh31 5y ago
> I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community. Perhaps not in the "frontend community", no it hasn't slowed down. There will always be new frameworks coming and going, and people will work on them as fun open source projects or use them in their side projects or whatever. But people doing real work are almost unanimously settled upon React as an industry standard at this point. There's still a decent sized faction of contrarian Vue holdouts, but by and large the JS framework wars are over.
lowbloodsugar 5y ago
Didn't downvote either. Almost consider upvoting for visibility of the hilarity displayed. "There are too many frameworks! Why does everyone keep re-inventing the wheel? Why can't everyone just use the one that I like?"
- cphoover 5y ago
  I never asked anyone not to use svelte... I said why should I be compelled to learn this new language, other than it being the hot new UI framework of the day. It doesn't have a virtual DOM? It doesn't have synthetic events? Ok why not just use web components which provide their own encapsulation and vanilla JS. I don't have to learn a new language which may or may not be around/supported a few years from now... Also I'm continuing to grok web standards.
  - d1sxeyes 5y ago
    You’re right, you don’t have to! Who is forcing you to? Rich Harris is going to work for Vercel, who are arguably most famous for Next.js, which is… React.
tshaddox 5y ago
I don’t know about “wrong,” but my opinion on the overall theme of that first comment is that the requirement to learn is not at all a bad thing. I enjoy learning new things even when that is in some sense a “requirement.”
winphone1974 5y ago
I assume because there's no value to it. What's the opposite side of the argument? You have an area with a lot of growth and many problems with the way we're solving these problems and something like svelte is not"completely reinventing the wheel" as the OP positions it, by nature it's try to solve specific problems using our existing tooling whenever possible. The original post is a shallow, feel-good rant
fendy3002 5y ago
I've used react for some years now and it's very very hard to do animation and event-driven operations with pure react render. You'll need extensive lifecycle events or hooks and refs to get animation or handle focus, etc well. It's due to how react render the components. It doesn't make react bad but I guess some newer frameworks (vue, svelte, I haven't learned those yet) try to tackle this from different approach.
ratww 5y ago
It is wrong because it has slowed down to a crawl compared to what we had from 2010-2014. Most companies have settled on either React or Vue, which are extremely similar. Angular is used in some niches, almost always because teams already knew it. Those three are responsible for almost 99% of the frontend positions you'll see. Svelte is getting popular but so far it's still niche. It's more of an inspiration for others, but also a contender. And really, what's so wrong about having more options and more competition? Even if you want to stop learning new things, there'll be no shortage of job vacancies for the three frameworks above. Also, since you're a backend dev, there are much more backend languages in use today than frontend frameworks, to give an example. And it's not hard to find companies using more than one.
cutler 5y ago
It sounds like you'd be better off with something like Ruby's Hotwire/Stimulus, ASP.Net Core/Blazor or Elixir/Phoenix Live View.
rk06 5y ago
The comment is negative and incorrect all of the js frameworks mentioned are view layer libraries. i.e. they create html. Hence they need a DSL for writing templated html, which will be used for generating final html Hence, it is completely natural for them to offer a custom DSL as html does not have standard way of expressing those concepts. Since each js framework has its own idiosyncrasies and motivations, custom DSLs reflect it. If you were to go around and make a new js framework, you too are going to create a new DSL

RoboticWater 5y ago

For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code. And the reason these things change is because that's what needed changing. One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't think unfamiliarity is that damning a criticism. Maybe I'm just used to switching up languages on a regular basis, but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.

fron 5y ago
> but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task. I agree. As long as you understand the basic concepts, it's only a matter of learning the syntax, which is really not as big of a deal as the person you replied to is making it out to be.
- cphoover 5y ago
  It's not a herculean task... I agree, until you've learned 10+ (angular, vue, svelte, wordpress/php, jade templates, laravel, underscore/lodash, handlebars/mustache, hugo, etc..) of these "super simple templating languages"! And keep them all straight. I have no problem learning a new language if there is a compelling reason. But If it's just additional shit I have to remember for no clear reason... No thanks... We can have a debate on unidirectional data flow vs 2-way binding, how each framework manages state changes, how opinionated each framework is... How mature and vibrant each developer community is... etc. These are all another discussion though. My question is why must we reinvent the wheel again and again.
  - bryans 5y ago
    You need to stop insisting that a wheel has been reinvented with Svelte. It shares 95% of the same DNA as other frameworks, with multiple improvements over them. So with that in mind, what you're actually suggesting is that the existing offerings were somehow perfect, and we don't ever need to improve on anything again. That is an absurd notion, especially given that the other frameworks have gone through MASSIVE changes since launch -- sometimes even complete rewrites, because they acknowledged they got it wrong the first time.

adamnemecek 5y ago

The templating language is the easiest thing to learn. The hardest is architecture.

tpict 5y ago

JSX is syntactic sugar for `React.createElement(...)` (most commonly), so React pretty much is plain JavaScript.

kall 5y ago
Yeah, It‘s my favorite templating abstraction because I could convert it by hand and so I don‘t really need to mentally model it as an additional layer.

rglover 5y ago

You'd like https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick. No special languages or syntax. Plain HTML, CSS, and JavaScript with the same reactive UI stuff in all the other frameworks. It's also part of a full-stack framework so you can whip up lightweight, fast apps. The best part is your skills are transferrable as I'm not introducing any domain-specific abstractions. You can go from learning HTML, CSS, and JS to this without any "gotcha" in the process.

tootie 5y ago

Any new language/framework trying to sell me on it's improved ergonomics should not bother showing me syntax and instead show me a stack trace. Vue is really concise and expressive but seeing a pile of node internals on every typo is infuriating.

cphoover 5y ago
Very true... How can I debug this thing when it breaks that's a great question. I wonder how sourcemaps work with svelte

hijodelsol 5y ago

For me Vue 3 with <script setup> get's pretty close to pure JavaScript/TypeScript. 90% of the code will be exactly like JS code, the only difference being the use of computed(), ref() and reactive() to achieve (something JS simply doesn't provide but is necessary for every non-trivial application). Your HTML code and CSS code are not mixed with JS and look and feel like the real thing as well. Other than the reactivity indication and the occasional onMounted(), etc. Vue 3 with <script setup> does away with all boilerplate and unidiomatic parts of Vue 2 and imo is the framework that most closely resembles pure HTML/CSS/JS while allowing for far greater productivity.

kall 5y ago
Are we still taking about vue <template>? I don‘t see how that is any way close to html when it has: custom conditional and loop syntax and semantics, arbitrary js expressions and a unique concept of scope?
- Drew_ 5y ago
  It does have extra non-native features but the overarching <template /> <script /> <style /> format for single file components is plain HTML which makes it feel closer to vanilla than React.
  - kall 5y ago
    Yeah I never really understood this benefit. The file structure is irrelevant to me after 15 minutes, the nitty-gritty semantics of my code are causing me headaches and bugs forever. (I like working with all 3 current frontend frameworks btw, not trying to start a flamewar)
    - Drew_ 5y ago
      I like it because it separates layout, styling, and scripting while still collating them in the same file.

deleted 5y ago

[deleted]

brundolf 5y ago

I don’t love that aspect myself, but I have to point out that in Svelte’s case it is definitely not “without a very compelling reason”. The special build-time processing is the entire point of Svelte. Though personally I’d almost prefer it was a whole new language than a “kind of JS but with some (necessarily) new syntax”

deleted 5y ago
[deleted]
cphoover 5y ago
100% no more js frankensteins... Id prefer to learn a new language altogether

bryans 5y ago

This is very overdramatic and isn't actually based on reality. Svelte is far closer to vanilla JS/HTML than any other framework, while also using extremely similar patterns from the other modern frameworks. Yeah, it has some sugar, but it's not just some templating system any more than React is just some templating system, and the only "unique syntax" you could be referring to is the auto-subscription to stores using $, which is super convenient. You're acting incredibly disinformative, and have no legitimate basis for your assertions.

gherkinnn 5y ago

You don't need to know every framework. And that little bit of custom syntax is peanuts compared to how the rest of these differ. Even if Angular and React shared the same templating syntax, you'd still be left with 95% of work ahead of you.

block_dagger 5y ago

This is why I have focused on backend for the last decade.

Tarks 5y ago

Agreed, I thought we were past this with the 4th generation of these frameworks, this is like knockoutjs all over again. The moment the penny dropped for me was when I read something like this about React: "We realised that inventing our own Yet Another Binding Language that was less expressive than javascript was harder and worse than doing the work to put the relatively simple HTML constructs into Javascript"

timeon 5y ago
And then you have ended up with shadow DOM.

jitix 5y ago

I used to be full stack before the re-invention of wheel phenomenon got way out of hand in the js world. Keeping up with what’s going on with the ecosystem and employing the best practices became a huge chore that took time away from solving actual business problems. Turning away from front end let me concentrate time on learning devops, cloud, ml and other things that aren’t as volatile in terms of design patterns and that lets me design more high level solutions to problems and create more overall value. Maybe people just differ in how wide or deep information they could handle but I certainly can’t keep up with such a wide array of patterns and tools that do the same thing.

travisl12 5y ago

My solution is pretty easy to this problem: I don't.

dbbk 5y ago

React is a free for all, you can render pretty much anything you want at any time. With templating languages, the DOM output can be statically analyzed at build time, so the amount of work needed to diff the HTML output when things change at runtime can be dramatically shortened.

unclebucknasty 5y ago

The problem with each of these frameworks is that they make the mistake of surfacing the underlying standards like HTML and the DOM. This is why they look remarkably similar and can only possibly be incrementally better, at best. HTML and the DOM are still essentially modeled on static documents. Building apps that deal directly with these standards is an impedance mismatch that, remarkably, people keep trying to solve by adhering to those same standards, but in a slightly different way. Why should we know or care about HTML or the DOM? A robust, event-driven, component-based framework that manages the low level Web standards could offer true advancement.

kall 5y ago
What would that look like for you? Something like SwiftUI or Flutter (which feel React inspired) or a totally different thing?
- unclebucknasty 5y ago
  Yes, these are moving in the right direction, but have a ways to go and are heavy for what they do. Visual Basic of old may actually be a better example. Even reactive models are built around matching data to the DOM, essentially. And there's still too much wiring that's required. I think where we'll see the innovation here is in the no-code and low-code platforms, which will move away from the model of code frameworks to better componentize and abstract away the low-level details. They'll surface high-level interactions via an elegant event model, and automatically handle reactivity through easy to specify component-to-database bindings. The concept of a lower-level code framework will be replaced by that of a simplified abstract "environment" in which devs work.
  - kall 5y ago
    I like the database-to-component binding idea. If you squint, that‘s what a GraphQL/React app simulates (with mountains of boilerplate). I‘m not so sure about moving up the level of abstraction in the direction of no code tools. You can make it super easy to build the 1000s of CRUD apps we need today, but a dominant UI toolkit needs to be low-level enough so we can also build the kinds of apps we don‘t know about yet and the no code tools to make those apps. I think the component model popularized by react is here to stay for a while, especially because it fits in perfectly with the low/no-code tools, but everything around I can see improving.

chrbp 5y ago

No one says you have to learn new languages or frameworks. It's really your own choice.

danny_taco 5y ago

I completely agree with you, and I've yet to see a compelling argument against this. I've been doing this since the rise of the SPA, all the way from vanilla, jQuery, Backbone, Angular 1.0, Ember and React and after reading your comment all I can think of is "great, we're going back to handlebars templating again". There is no net-gain in re-inventing the wheel. It just becomes yet another thing to master to stay relevant. In a decade of doing JS front-end applications things have only gotten more complex and more time-consuming. Thankfully I've found a sweet spot where complexity, velocity and quality are in balance using technologies considered no longer cool and that's fine with me. I get to focus on the actual problem at hand instead of trying to figure out the inner workings of this new shiny thing.

ratww 5y ago
The youngest framework of your list is 8 years old already. Svelte itself is gonna be 5 years old in a couple weeks, and there's absolutely no need to pick it up right now. The meme that there are new frontends daily is extremely tired and has been totally false for several years now. Also the only thing those baseless complaints achieve are flamewars and shitting in other people's work.
- kall 5y ago
  We moved on. Now there is a new javascript build tool written in a faster language daily (and I love them all).
cutler 5y ago
I think the pendulum may be swinging back with options like Rails/Hotwire, ASP.Net Core/Blazor and Elixir/Phoenix Live View. Let's hope so.

gaws 5y ago

You're getting flamed on Twitter for this comment lol: https://twitter.com/dancow/status/1458906853488967684 https://twitter.com/dancow/status/1458906853488967684

joppy 5y ago

Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.

richeyryan 5y ago
SolidJS[https://www.solidjs.com/ https://www.solidjs.com/] does exactly that. That ability is more about fine grained reactivity than it is about templates. The use of templates and single file components is a stylistic choice by the Svelte team. You could argue Solid has poor ergonomic compared to Svelte I guess.
Aeolun 5y ago
> I don't know how you could implement such a thing (with good ergonomics) without a template language. Parse Javascript? I don’t see how it would be any different, except you have more constructs to work through.
- tshaddox 5y ago
  The "more constructs to work through" is precisely the problem. Without restricting JavaScript to some subset, you're not going to be able to statically determine the behavior of any given program.

miohtama 5y ago

Because if we do not keep constantly learning and get better, we would be stuck writing COBOL and BASIC.

cphoover 5y ago
haha fair enough! But I think, I'd rather learn an entirely new technology or language instead of every year having to learn a JS Frankenstein language! I kind of regret posting my OP now... as its turned into a bit of a flame war. It was not my intent. And I applaud people try and build anything new. I'm just ranting a bit about how it feels like UI development has a new framework/language/ecosystem every year or that is touted as the next big thing to supersede the rest! But then ends up reinventing much of the same constructs only with subtly different syntaxes.

intrasight 5y ago

They are all just trying to replicate XSLT - but by mixing imperative with declarative syntaxes.

deleted 5y ago

[deleted]

lhorie 5y ago

IMHO, syntax is the easiest part. Semantics are the tricky part. One very clear example of this is how Svelte and React deal with async stuff. The Svelte approach follows the handlebar approach of having semantics be represented by DSL constructs - which is a very reasonable approach IMHO. The Suspense semantics are so far off left field that someone literally wrote a whole framework specifically in response to its complexity[0]. And that complexity permeates every language construct used within a React component. Why can't we call hooks from inside if statements? Aren't if statements just JS? If you have to bring up React's internal implementation to explain, that's no longer "just Javascript", it's also a healthy chunk of very React-specific knowledge that you need to be aware of. Vue is another example that provides a successful story of a very large algorithmic migration from a reactive system to virtual dom with virtually no disruption to consumers, thanks to the abstraction provided by its DSL. In contrast, try telling my wife (who's learning about class components in her React course) that functional components and hooks "are just JS, what's the big deal", and see how far that takes you :) [0] https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank

midrus 5y ago

I just don't get people complaining of trivial or superficial stuff such as how to do ifs, loops or binding handlers. When the most important part of these tools are the architecture, the trade offs, the state managements, the tools, the libraries and the ecosystem. Complaining just because of the syntax is just trying to convince yourself you don't like it. It's like when people just discard tailwind because they don't like how ugly many classes together look on the html, ignoring everything behind it which is what really matters (and that you can still like or dislike).