Hacker News Reader

Comment by ng12 | Hacker News Reader

> 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.

View on HN

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.

>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,

Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers, I can't see how the industry will migrate back to server-side rendering in 3 years.

The unavoidable technical issue is the round-trip latency of the network. The same delays from the speed-of-light will still be there in 3 years. Most of the world is accessing the web through mobile phones which has worse latency than desktops. Server-side rendering (which means painful page reloads) is user hostile on slow network connections.

You didn’t mention all of the new features coming to HTTP 2 that will alleviate network performance issues (prefetch, multiplex connections, etc.)

I’ve found many sites that use frameworks like react to be much more user hostile, particularly from a performance and accessibility standpoint. The reddit redesign comes to mind. It’s so much slower now than it used to be on a browser (perhaps they’re intentionally doing this to push people to their mobile app), that it’s noticeably reduced the quality of the experience.

I guess I just don’t understand how people see page reloads with proper caching as unacceptable from a performance standpoint compared some JavaScript app maintaining a virtual DOM, which is also likely regularly communicating with a server.

Same with TechCrunch, every time I visit I am reminded how frustrating react sites can be compared to server rendered pages with all the flicker, slow page reveal, and odd navigation it introduced.

Late loading artifacts is all the fault of JS, not server-side rendering. Not sure what you mean by "odd navigation."

To close an article there is a x button and back swipe is disabled. I agree that flicker is introduced by Javascript. That is what I was saying. Might be ok for an app, but a content driven site seems like it should stick to the concept of pages where navigation is like turning a page. Just seems like server rendering fits that mental model better. Not sure why react even makes sense for a blog.

It doesn't, but blogs aren't built to present content they're built to sell advertisements and collect data. That's much easier with an SPA than a SSR app.

they're built to sell advertisements and collect data. That's much easier with an SPA than a SSR app

How easier? By dint of additional JS that an SSR doesn't have/need? Not sure how pulling a header nav (or any cell/element) from a server on pageload plays into that, but even today I've watched sites (plural) loading, pushing loaded parts all over the page for 30sec until everything settles down. Maybe blogs aren't quite so affected by this set of popular dark- and anti-patterns, but even so the post is almost always the last thing to load. Presumably, the monetization and data collection takes precedence over all else.

>Server-side rendering (which means painful page reloads) is user hostile on slow network connections.

So is downloading an entire app when you only want to read one page.

I believe in a mix of these two. It's going to be server rendered JS app that will download itself on the background and install itself as a PWA. The best of both worlds.

So you mean universal application? That's how nuxt.js/next.js works

Yes I am aware of these technologies, and it's basically what I mean, in an abstract way

That is what we have today.

It is not nearly as polished and as widespread as it could be.

So parallelism after one initial slow load is the cure all? I also propose that front end will rediscover that parallelism is hard and isn't always the best fit.

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.

SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).

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.

That and for the bots, that cannot run javascripts, but do render the page thumbnail for others (facebook et al).

This supports the argument you're replying to.

This already happened. Frameworks like Next.js, Vue and Gatsby do server-side rendering out of the box.

Svelte also extremely promising. It brings a brilliant hybrid solution to the table.

...and then they'll hit POST-redirect-GET and all the problems with the back button and holding state on the server.

So, basically video-streaming, but with websites instead of tv shows?

Basically what most web frameworks have been doing since we moved beyond CGIs.

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"}]]

That looks really ugly IMHO, compared to JSX which is more HTML-like.

Perhaps it might look better if there's a bigger example?

> 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!

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.

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.

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.

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.

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.

Not really - and that's why I like it. I like JSX too.

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

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.

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.

I don’t think you’re a weird minority. I work for a Danish city and we operate around 500 different IT systems. They are all slowly migrating to web, with some backend typically JAVA or C# and a JavaScript MVVM front. Only one of them uses Vue, all the others use React or Angular.

If you look at the job market around here, it’s 70% react and 30% angular with almost no Vue jobs right now. The ones listing Vue as a requirement almost all use React, who are willing to retrain Vue developers. It used to be more evenly distributed between angular and react, but it would seem that react won the front end war.

This is HN though, it’s not very representative of what goes on outside of Silicon Valley. Right now there isn’t a single Rust job in my country as an example, at least not in any of our major jobbanks. There are thousands of PHP jobs though. But if you took HN to be representative for languages, you’d think it was the opposite.

JSX feels like PHP and ASP all over again.

Apparently they aren't that bad after all.

I hesitate to tell people. They are doing it wrong but if you write JSX like how we all wrote PHP back in the day then you are doing it wrong.

So how do you modularize content in separate files?

How can you say that? PHP and ASP were dumb text template processors. JSX creates object graphs. They are almost nothing alike at all.

Mixed content on the same file, looks pretty much the same, regardless how it is implemented.

The problem with ASP/PHP (or at least, the one we are addressing here) always mixing presentational logic with business logic. Something you still shouldn't do, and React doesn't advocate doing so at all.

I totally disagree. VueJS and AngularJS feel like PHP/ASP but I never got that feeling from JSX.

I fail to see how proper component based frameworks, with clean separation of concerns, provide such experience.

JSX is the one mixing echo like statements with proper JavaScript.

That is pretty impossible since JSX is just JavaScript, including all of its scope separation. It might be that you're not well versed in using it.

JSX let's us define components, usable with the usual HTML syntax. PHP does not. That's why Facebook developed XHP (XML fragments in PHP), which inspired JSX.

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.

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/we...

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.

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.

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.

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.

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.

Sapper & Next.js support server side rendering.

So does Nuxt.js (for Vue).

So what alternatives?

I don't want to program iOS and Android and web.

Then just focus on one platform.

Plenty of gigs available.

I'm beyond gigs

Reply on news.ycombinator.com