Earlier quoted context omitted.
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
Front-end design, React, and a bridge over the great divide
111–120 of 137 posts
Re: Front-end design, React, and a bridge over the great divide
#112"everything is a component"
That is a major misconception. In reality, that is simply not the case. (see all those 'container' like components trying to tame underlying components and the awful state juggling dance we are now accustomed to.)
And most JS frameworks confuse the logical structure of an app with the 'physical' structure of the DOM.
Components are in the end rendered sub-trees in the DOM. But that forces you to lay out your app logic along these lines.
It's limiting, it's wrong and there is a very good reason why there's a C in MVC. It stands to argue we dismissed the C part in the front-end world way too easily.
Re: Front-end design, React, and a bridge over the great divide
#113Earlier quoted context omitted.
>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…
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…
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.
Re: Front-end design, React, and a bridge over the great divide
#114> Crafting semantic HTML markup with a strong focus on accessibility, in order to make experiences that are friendly to browsers, assistive technologies, search engines, and other environments that can consume HTML. > Creating CSS code that control the look and feel of the web experience, tackling colors, typography, responsive layout, animation, and any other visual aspect of the UI. Frontend designers architect res…
It's not that 95% of frontend designers don't care about accessibility...
It's that 95% of project managers just won't place accessibility concerns on the top of their Jira backlogs.
It took me six years of full-time and freelancing work to finally end up a company that does this. It's a rare thing in the industry to find a company that cares about, what is essentially, this usually untapped source of potential revenue.
Re: Front-end design, React, and a bridge over the great divide
#115"everything is a component" That is a major misconception. In reality, that is simply not the case. (see all those 'container' like components trying to tame underlying components and the awful state juggling dance we are now accustomed to.) And most JS frameworks confuse the logical structure of an app with the 'physical' structure of the DOM. Components are in the end rendered sub-trees in the DOM. But that forces…
> And most JS frameworks confuse the logical structure of an app with the 'physical' structure of the DOM.
Because that's what JavaScript does. How is it any different than document.getElementById or the window event handling system?
The point is if we're going to do it we might as well do it well.
Re: Front-end design, React, and a bridge over the great divide
#116Earlier quoted context omitted.
is this much different than JSX? 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.
Re: Front-end design, React, and a bridge over the great divide
#117> 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 nev…
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.
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.
Re: Front-end design, React, and a bridge over the great divide
#118Earlier quoted context omitted.
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 somet…
JSX feels like PHP and ASP all over again. Apparently they aren't that bad after all.
I totally disagree. VueJS and AngularJS feel like PHP/ASP but I never got that feeling from JSX.
Re: Front-end design, React, and a bridge over the great divide
#119I already loved the productivity of Vue and after using React for a while it makes me appreciate Vue even more.
I genuinely think picking React for a new project over Vue is a mistake.
Re: Front-end design, React, and a bridge over the great divide
#120Earlier quoted context omitted.
JSX feels like PHP and ASP all over again. Apparently they aren't that bad after 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.