8 ms·

> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bu

by ng12 7y ago

> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. JSX is fine, the real power is building your HTML in pure JavaScript. I'll never go back to a template language, in my mind they're a fundamentally flawed design. They necessitate introducing extra concepts and implementing some magic rendering voodoo -- for what? So I can write my code twice, once in the JavaScript and once in whatever weird template directive language the framework uses. So for me the only real alternative to JSX is to do elm-html style nested function calls which tends to be much uglier. JSX isn't perfect but it's the best we have by a mile.

cljs-js-eval 7y ago
You should check out CLJS's reagent. It mixes the best of both worlds, everything is a plain CLJS object without special syntax, but it's also obviously HTML/CSS: [:div {:style {:display "flex", :flex-direction "row"}} [:label {:for "email"}] [:input {:type "text"}]]
- rhaksw 7y ago
  is this much different than JSX? <div style="display: flex; flex-direction: row"> <label for="email"/> <input type="text"/> </div> I definitely want to try CLJS some time. edit Oh I see. You don't need the extra {} to jump into JS mode. And, CLJS requires : to denote keys. I think as long as my editor colors the syntax appropriately I'm okay with either.
  - cljs-js-eval 7y ago
    Not really - and that's why I like it. I like JSX too.
  - rafd 7y ago
    The difference is that in the cljs version you are writing clojure at all times using clojure data structures and types (vector, map, keyword, string) which lets you manipulate and generate things easily, and, you don't have to jump between "jsx" mode and "JS" mode.
    - sli 7y ago
      This is a major reason why I've left JS behind for CLJS. Reagent code is really just data. It acts like data, you can treat it like data. Sure, it's all well and good to say "code is data and data is code," but in reality doesn't usually work that way quiet so simply. But it does work that way in Lisp. Compare to alternatives like Om, where the code looks like, well, code. Except in reality it's just Lisp sequences instead of Lisp vectors, so you still get all the same abilities to treat code like data. I don't think I'll ever willingly go back to JS. Maybe Purescript once of these days, but never JS. Additionally, re-frame is absolutely wonderful and I cannot believe I waited as long as I did to switch to CLJS considering how much I prefer re-frame (and reagent) it over Redux (and React). Writing JS for immutability feels like such a chore now (Immer helps), since that part already just works in Clojure.
  - sooheon 7y ago
    Also the CLJS you see is using the vectors and hashmaps of the language, meaning much more direct manipulation the same way you'd program any other datastructure.
  - cljs-js-eval 7y ago
    The :display is a keyword, which works like keywords in Ruby or Erlang; it's a special, never-garbage-collected string for when you use the same string over and over. Though I'm not sure whether the implementation is the same when compiling to Javascript instead of the JVM.
- benbristow 7y ago
  That looks really ugly IMHO, compared to JSX which is more HTML-like. Perhaps it might look better if there's a bigger example?
  - pcr910303 7y ago
    > That looks really ugly IMHO, compared to JSX which is more HTML-like. The point of this is not of asthetics, (IMO it’s not that ugly :-)) but more that it just consists of common data structures that is easy to manipulate. If you’re a React person, think of directly writing JSON instead of using indirect React.createElement calls. Writing components in JSON would be impractical; (actually it might not be - I think I’ve seen blogposts using React without JSX) but writing components in cljs data structures are practical and less tooling is needed!
kylecordes 7y ago
I totally get the preference for the JSX approach. Also echoing other commenters, CLJS/reagent and similar tools did a pretty amazing job of this some years ago. But I think it is wise to consider that there are advantages and trade-offs to a compiled template approach as used by Angular, Svelte, and probably some others I’m forgetting. * potentially more concise syntax * potentially more familiar syntax * do more of the work at compile time, less of it at runtime in downloaded code * avoid the GC pressure and other overhead of VDOM
dahfizz 7y ago
Server side rendering has one big advantage - it's fast. Client side rendering frameworks may be easier and sexier, but serving html is always going to be faster.
- briantakita 7y ago
  Sapper & Next.js support server side rendering.
  - leadingthenet 7y ago
    So does Nuxt.js (for Vue).
- onion2k 7y ago
  If you need custom data in the page on a per request basis then SSR is usually the fastest method to generate the final HTML but it isn't the fastest method of getting something on the user's screen. Its "time to render" that counts, and that means doing as little work as possible to send something to the user. Serving the same static, "prerendered" HTML file with no customization to every user is always going to be the fastest method of getting something to display in the user's browser, so perceptually it's much faster to serve a static html file and then hydrate it with any custom data using frontend JS.
  - dahfizz 7y ago
    I hear this often, but I am unconvinced. This just leads to jittery pages that keep moving when I try to do something to them. Just seeing the skeleton of the web page doesn't make it fast. The page will be unresponsive for longer and will visually stutter while rendering. It's a much worse user experience imo.
    - onion2k 7y ago
      Just seeing the skeleton of the web page doesn't make it fast. I didn't say it does. Skeleton loading is slower. It feels faster though, and that perceptive improvement is more important than the actual time something takes. If you ask users which they think is faster they usually say the skeleton version regardless of the facts. When your key metric is user satisfaction rather than raw download speed that's important. The page will be unresponsive for longer and will visually stutter while rendering. That doesn't have to be the case though. There are plenty of techniques for writing client side code that doesn't block user interaction.
zbentley 7y ago
I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in-javascript metalanguages are being discovered now as a cure for spaghetti frontend-plus-backend-rendered code.
- ng12 7y ago
  I don't think so, at least not for the kinds of apps I build. My biggest problem is largely around interactivity -- shuffling lots of data back-and-forth between the client and the server. If I'm going to have a SSR app with lots of AJAX code running on the client, I might as well just go all-client.
  - kangoo1707 7y ago
    SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).
    - sooheon 7y ago
      Isn't that use case just to save time on initial load? An SPA with SSR for load times is different from a webapp structured to have logic mostly in the server.
      - vetinari 7y ago
        That and for the bots, that cannot run javascripts, but do render the page thumbnail for others (facebook et al).
    - skrebbel 7y ago
      This supports the argument you're replying to.
- magicnubs 7y ago
  So, basically video-streaming, but with websites instead of tv shows?
shareIdeas 7y ago
So what alternatives? I don't want to program iOS and Android and web.
- pjmlp 7y ago
  Then just focus on one platform. Plenty of gigs available.
  - shareIdeas 7y ago
    I'm beyond gigs
tuesdayrain 7y ago
I was initially a pretty big fan of JSX, but after using Vue it just feels like extra overhead. In my experience, parsing complex JSX in my head results in constant context switches depending on whether the specific parts I'm looking at are closer to HTML or closer to JS. And for the tasks I've generally been doing at work, there rarely seems to be a good reason to combine the two. If I'm trying to fix a bug for example, it's almost always clearly restricted to either HTML, JS, or CSS. And I really appreciate how Vue minimizes the amount of code I need to search through in those situations.
- ergothus 7y ago
  I keep hearing all of these "Vue just makes more sense than React" converts, and I'm baffled. I recently did some Vue after doing React for a few years, and it felt like a major step backward. It felt very JSP - here was a different syntax that was HTML except when it chose not to be - managing data was done in a custom expression language, and I was left to figure out what scope a given value had. Need to loop something ten times? It's one tag with a special "v-for" property. Want do to that loop with a condition? Special "v-if" property, and is that evaluated in the scope of a variable created by v-for or not? No idea! And that's not even getting into the various parts a Vue component object has. JSX is just javascript. It's HTML looking, but is ALL (not some) a wrapper to write a JS function that outputs HTML. Need to have a loop? Loop in JS. Need to have a conditional? Condition in JS. What scope? This is all a JS function, so the scope rules are all JS scope rules. I have no idea if I'm a weird minority, or if I'm just running into more people that felt better with Vue than React, but I really don't understand why.
  - pjmlp 7y ago
    JSX feels like PHP and ASP all over again. Apparently they aren't that bad after all.
    - efdee 7y ago
      How can you say that? PHP and ASP were dumb text template processors. JSX creates object graphs. They are almost nothing alike at all.
Existenceblinks 7y ago
After doing Elm or PhoenixLiveView, I'll never go back to React stuff. Every time people trying to re-invent html, it will end up pretty much HTML. It's simple and powerful. The sad part is developer resources spent on optimizing for JS instead of joining force improving HTML standard.
dsego 7y ago
Extra concepts in templates aren't that difficult, it's usually just binding directive, conditionals and loops. You know, the bread and butter of every programmer. How hard is that? I'd say not harder than learning the many nuances of JSX. And the magic rendering voodoo enables you to do compile-time optimizations, because of the limited set of directives supported by this magical templating engine.
bwindels 7y ago
I think you can get pretty close to the comfort of JSX with plain JS, without needing a preprocessor. Local development is so much nicer without webpack, babel, source maps, ... I've been trying trying this out [1] with a thin 300-line DOM wrapper, and works wonderfully well so far. There are also libraries like lit-html but I prefer to construct html as an object tree, and not a string. 1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/web/login/LoginView.js https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...

by ng12 7y ago

cljs-js-eval 7y ago

You should check out CLJS's reagent. It mixes the best of both worlds, everything is a plain CLJS object without special syntax, but it's also obviously HTML/CSS: [:div {:style {:display "flex", :flex-direction "row"}} [:label {:for "email"}] [:input {:type "text"}]]

rhaksw 7y ago
is this much different than JSX? <div style="display: flex; flex-direction: row"> <label for="email"/> <input type="text"/> </div> I definitely want to try CLJS some time. edit Oh I see. You don't need the extra {} to jump into JS mode. And, CLJS requires : to denote keys. I think as long as my editor colors the syntax appropriately I'm okay with either.
- cljs-js-eval 7y ago
  Not really - and that's why I like it. I like JSX too.
- rafd 7y ago
  The difference is that in the cljs version you are writing clojure at all times using clojure data structures and types (vector, map, keyword, string) which lets you manipulate and generate things easily, and, you don't have to jump between "jsx" mode and "JS" mode.
  - sli 7y ago
    This is a major reason why I've left JS behind for CLJS. Reagent code is really just data. It acts like data, you can treat it like data. Sure, it's all well and good to say "code is data and data is code," but in reality doesn't usually work that way quiet so simply. But it does work that way in Lisp. Compare to alternatives like Om, where the code looks like, well, code. Except in reality it's just Lisp sequences instead of Lisp vectors, so you still get all the same abilities to treat code like data. I don't think I'll ever willingly go back to JS. Maybe Purescript once of these days, but never JS. Additionally, re-frame is absolutely wonderful and I cannot believe I waited as long as I did to switch to CLJS considering how much I prefer re-frame (and reagent) it over Redux (and React). Writing JS for immutability feels like such a chore now (Immer helps), since that part already just works in Clojure.
- sooheon 7y ago
  Also the CLJS you see is using the vectors and hashmaps of the language, meaning much more direct manipulation the same way you'd program any other datastructure.
- cljs-js-eval 7y ago
  The :display is a keyword, which works like keywords in Ruby or Erlang; it's a special, never-garbage-collected string for when you use the same string over and over. Though I'm not sure whether the implementation is the same when compiling to Javascript instead of the JVM.
benbristow 7y ago
That looks really ugly IMHO, compared to JSX which is more HTML-like. Perhaps it might look better if there's a bigger example?
- pcr910303 7y ago
  > That looks really ugly IMHO, compared to JSX which is more HTML-like. The point of this is not of asthetics, (IMO it’s not that ugly :-)) but more that it just consists of common data structures that is easy to manipulate. If you’re a React person, think of directly writing JSON instead of using indirect React.createElement calls. Writing components in JSON would be impractical; (actually it might not be - I think I’ve seen blogposts using React without JSX) but writing components in cljs data structures are practical and less tooling is needed!

kylecordes 7y ago

I totally get the preference for the JSX approach. Also echoing other commenters, CLJS/reagent and similar tools did a pretty amazing job of this some years ago. But I think it is wise to consider that there are advantages and trade-offs to a compiled template approach as used by Angular, Svelte, and probably some others I’m forgetting. * potentially more concise syntax * potentially more familiar syntax * do more of the work at compile time, less of it at runtime in downloaded code * avoid the GC pressure and other overhead of VDOM

dahfizz 7y ago

Server side rendering has one big advantage - it's fast. Client side rendering frameworks may be easier and sexier, but serving html is always going to be faster.

briantakita 7y ago
Sapper & Next.js support server side rendering.
- leadingthenet 7y ago
  So does Nuxt.js (for Vue).
onion2k 7y ago
If you need custom data in the page on a per request basis then SSR is usually the fastest method to generate the final HTML but it isn't the fastest method of getting something on the user's screen. Its "time to render" that counts, and that means doing as little work as possible to send something to the user. Serving the same static, "prerendered" HTML file with no customization to every user is always going to be the fastest method of getting something to display in the user's browser, so perceptually it's much faster to serve a static html file and then hydrate it with any custom data using frontend JS.
- dahfizz 7y ago
  I hear this often, but I am unconvinced. This just leads to jittery pages that keep moving when I try to do something to them. Just seeing the skeleton of the web page doesn't make it fast. The page will be unresponsive for longer and will visually stutter while rendering. It's a much worse user experience imo.
  - onion2k 7y ago
    Just seeing the skeleton of the web page doesn't make it fast. I didn't say it does. Skeleton loading is slower. It feels faster though, and that perceptive improvement is more important than the actual time something takes. If you ask users which they think is faster they usually say the skeleton version regardless of the facts. When your key metric is user satisfaction rather than raw download speed that's important. The page will be unresponsive for longer and will visually stutter while rendering. That doesn't have to be the case though. There are plenty of techniques for writing client side code that doesn't block user interaction.

zbentley 7y ago

I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in-javascript metalanguages are being discovered now as a cure for spaghetti frontend-plus-backend-rendered code.

ng12 7y ago
I don't think so, at least not for the kinds of apps I build. My biggest problem is largely around interactivity -- shuffling lots of data back-and-forth between the client and the server. If I'm going to have a SSR app with lots of AJAX code running on the client, I might as well just go all-client.
- kangoo1707 7y ago
  SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).
  - sooheon 7y ago
    Isn't that use case just to save time on initial load? An SPA with SSR for load times is different from a webapp structured to have logic mostly in the server.
    - vetinari 7y ago
      That and for the bots, that cannot run javascripts, but do render the page thumbnail for others (facebook et al).
  - skrebbel 7y ago
    This supports the argument you're replying to.
magicnubs 7y ago
So, basically video-streaming, but with websites instead of tv shows?

shareIdeas 7y ago

So what alternatives? I don't want to program iOS and Android and web.

pjmlp 7y ago
Then just focus on one platform. Plenty of gigs available.
- shareIdeas 7y ago
  I'm beyond gigs

tuesdayrain 7y ago

I was initially a pretty big fan of JSX, but after using Vue it just feels like extra overhead. In my experience, parsing complex JSX in my head results in constant context switches depending on whether the specific parts I'm looking at are closer to HTML or closer to JS. And for the tasks I've generally been doing at work, there rarely seems to be a good reason to combine the two. If I'm trying to fix a bug for example, it's almost always clearly restricted to either HTML, JS, or CSS. And I really appreciate how Vue minimizes the amount of code I need to search through in those situations.

ergothus 7y ago
I keep hearing all of these "Vue just makes more sense than React" converts, and I'm baffled. I recently did some Vue after doing React for a few years, and it felt like a major step backward. It felt very JSP - here was a different syntax that was HTML except when it chose not to be - managing data was done in a custom expression language, and I was left to figure out what scope a given value had. Need to loop something ten times? It's one tag with a special "v-for" property. Want do to that loop with a condition? Special "v-if" property, and is that evaluated in the scope of a variable created by v-for or not? No idea! And that's not even getting into the various parts a Vue component object has. JSX is just javascript. It's HTML looking, but is ALL (not some) a wrapper to write a JS function that outputs HTML. Need to have a loop? Loop in JS. Need to have a conditional? Condition in JS. What scope? This is all a JS function, so the scope rules are all JS scope rules. I have no idea if I'm a weird minority, or if I'm just running into more people that felt better with Vue than React, but I really don't understand why.
- pjmlp 7y ago
  JSX feels like PHP and ASP all over again. Apparently they aren't that bad after all.
  - efdee 7y ago
    How can you say that? PHP and ASP were dumb text template processors. JSX creates object graphs. They are almost nothing alike at all.

Existenceblinks 7y ago

After doing Elm or PhoenixLiveView, I'll never go back to React stuff. Every time people trying to re-invent html, it will end up pretty much HTML. It's simple and powerful. The sad part is developer resources spent on optimizing for JS instead of joining force improving HTML standard.

dsego 7y ago

Extra concepts in templates aren't that difficult, it's usually just binding directive, conditionals and loops. You know, the bread and butter of every programmer. How hard is that? I'd say not harder than learning the many nuances of JSX. And the magic rendering voodoo enables you to do compile-time optimizations, because of the limited set of directives supported by this magical templating engine.

bwindels 7y ago

I think you can get pretty close to the comfort of JSX with plain JS, without needing a preprocessor. Local development is so much nicer without webpack, babel, source maps, ... I've been trying trying this out [1] with a thin 300-line DOM wrapper, and works wonderfully well so far. There are also libraries like lit-html but I prefer to construct html as an object tree, and not a string. 1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/web/login/LoginView.js https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...