27 Matching Annotations
- Sep 2022
-
twig.symfony.com twig.symfony.com
-
- Mar 2021
-
rawgit.com rawgit.com
- Nov 2020
-
github.com github.com
-
But I always thought that if Svelte will change its syntax to something new, it will more look like ES6 Template Literals
-
Btw, I also personally like Dust-syntax: https://github.com/linkedin/dustjs/wiki/Dust-Tutorial
-
-
github.com github.com
- Oct 2020
-
-
hyperscript is much simpler to refactor and DRY up your code than with JSX, because, being vanilla javascript, its easier to work with variable assignment, loops and conditionals.
Tags
- template language: bad: by not reusing existing language constructs; forced to reinvent equivalents which are inferior and unfamiliar
- JSX
- reuse existing language constructs
- javascript
- it's just _
- making it easy for later refactoring
- hyperscript
- template language vs. reusing existing language constructs
- comparison with:
Annotators
URL
-
-
facebook.github.io facebook.github.io
-
Why not just use that instead of inventing a syntax that's not part of ECMAScript?
-
-
medium.com medium.com
-
I know that it is the matter of taste and a debatable thing, I find JSX and regular javascript flow operators a lot more readable than any sort of {#blocks} and directives.
-
Yes, you cannot fully express a modern app through templates without sacrificing flexibility and code reusability.
-
Because templates are not Turing-complete, and if they were, they would require vDOM.
-
-
tech.ebayinc.com tech.ebayinc.com
-
that does not mean that I am advocating the other extreme–i.e., a templating language that allows a lot of logic. I find such templating languages, especially those that allow the host programming languages to be used inside the template, to be hard to read, hard to maintain, and simply a bad choice.
-
-
github.com github.com
-
Solid supports templating in 3 forms JSX, Tagged Template Literals, and Solid's HyperScript variant.
-
-
-
Templates are prone to unnoticed runtime errors, are hard to test, and are not easy to restructure or decompose.
-
In contrast, Javascript-made templates can be organised into components with nicely decomposed and DRY code that is more reusable and testable.
-
In contrast, React apps shun templates and require the developer to create their DOM in Javascript, typically aided with JSX.
-
- Sep 2020
-
github.com github.com
-
In a similar vein to (#33), it is arguably just something that compensates for the lack of power in the template language relative to JavaScript.
-
-
github.com github.com
-
The complaint is that by choosing less powerful languages, template-based frameworks are then forced to reintroduce uncanny-valley versions of those constructs in order to add back in missing functionality, thereby increasing the mount of stuff people have to learn.
-
In general, I'm unpersuaded by these arguments (learning curve is determined not just by unfamiliar syntax, but by unfamiliar semantics and APIs as well, and the frameworks in question excel at adding complexity in those areas).
-
One of the arguments that's frequently deployed in favour of JSX-based frameworks over template-based ones is that JSX allows you to use existing language constructs:
Tags
- don't create a new syntax
- template language: bad: by not reusing existing language constructs; forced to reinvent equivalents which are inferior and unfamiliar
- reuse existing language constructs
- learning curve
- familiar syntax
- React
- javascript
- it's just _
- unpersuaded
- complexity
- template language
- prefer plain code over new template language
- familiar semantics
- template language vs. reusing existing language constructs
Annotators
URL
-
-
markojs.com markojs.comMarko1
-
github.com github.com
-
Proposes a syntax similar to JSX.
My question would instead be, why not just use JSX for Svelte templates?
-
Compared to JSX it looks way better (IMO)
-
-
github.com github.com
Tags
Annotators
URL
-
-
svelte.dev svelte.dev
-
if the idea of using a template language makes you shudder — your fears are misplaced, but that's a topic for another day
-
- Jun 2020
-
stackoverflow.com stackoverflow.com
-
What would be nice is if JavaScript had a built-in way to do what I can do in Ruby with:
> I18n.interpolate('Hi, %{name}', name: 'Fred') => "Hi, Fred"But to be fair, I18n comes from i18n library, so JS could just as easily (and I'm sure does) have a library that does the same thing.
Update: Actually, you can do this in plain Ruby (so why do we even need
I18n.interpolate?):main > "Hi, %{name}" % {name: 'Fred'} => "Hi, Fred"main > ? String#% From: string.c (C Method): Owner: String Visibility: public Signature: %(arg1) Number of lines: 9 Format---Uses str as a format specification, and returns the result of applying it to arg. If the format specification contains more than one substitution, then arg must be an Array or Hash containing the values to be substituted. See Kernel::sprintf for details of the format string. "%05d" % 123 #=> "00123" "%-5s: %016x" % [ "ID", self.object_id ] #=> "ID : 00002b054ec93168" "foo = %{foo}" % { :foo => 'bar' } #=> "foo = bar"I guess that built-in version is fine for simple cases. You only need to use
I18n.translateif you need its more advanced features likeI18n.config.missing_interpolation_argument_handler.
-
-
-
clean and understandable markup template without the help of 3rd party
-
-
medium.com medium.com
-
I really do not like writing templates in a file, such as #each , #if. I do not like to prefer using new approaches for which i can do it with purely in JavaScript.
-