Front-end design, React, and a bridge over the great divide
bradfrost.com
bradfrost.com
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.
[:div {:style {:display "flex", :flex-direction "row"}}
[:label {:for "email"}]
[:input {:type "text"}]] <div style="display: flex; flex-direction: row">
<label for="email"/>
<input type="text"/>
</div>
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.
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.
Perhaps it might look better if there's a bigger example?
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!
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
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.
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.
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.
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.
So is downloading an entire app when you only want to read one page.
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.
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.
Svelte also extremely promising. It brings a brilliant hybrid solution to the table.
I don't want to program iOS and Android and web.
Plenty of gigs available.
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.
Apparently they aren't that bad after all.
JSX is the one mixing echo like statements with proper JavaScript.
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.
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...
Imagine being a designer at a place like Netflix. Your product is among the most ubiquitous in the world - if there's a device with any kind of screen, Netflix has an app for it.
Now imagine developing a skillset, as a designer, that totally locks you into one platform (the web in this case). It makes absolutely no sense. I don't care how "easy" React makes things, or how "easy" layout now is with CSS Grid. It takes serious time and effort to develop these skills.
So I ask myself, why would a designer do this? It's one thing to have domain-specific knowledge (iOS design is _very_ different from web, for example). It's another to have implementation-specific knowledge, which IMO a designer really doesn't need.
This is great and all for Netflix's web designers, but what about iOS, Android, Apple TV, Playstation, Xbox, Roku, etc etc etc?
I'm not opposed to individual designers learning how to code, but my fear is that the industry will come to an expectation that designers should be able to build UI's. I think that's a very very bad idea.
JSX makes a lot of sense for those writing components but makes little sense for a designer to be forced to think in that way. Using vue with html templates allows designers to copy and paste html.. it's not that easy with jsx..
> 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 resilient CSS code with a focus on modularity, flexibility, compatibility, and extensibility.
> Optimizing the performance of frontend code in order to create lightweight, fast-loading, snappy, jank-free experiences.
I can't help but chuckle at this. I admit that good frontend designers do this, but they are extremely rare. Judging solely by the top Google results, 95% of frontend designers don't do any of this: they don't care about accesibility, friendly experience, compatibility or anything like that.
I applaud the author for caring about these things. His website is the biggest evidence that he does, but most designers don't do these things.
I’m not even going to be prescriptive about how much time. If you have 5 minutes, fine, good.
And then usually you pile up thousands of kludges before someone blows a whistle and says “Hey, none of this is accessible!”, and then you look back at a mountain of inaccessible garbage you wrote and claim it’s too hard.
So long as design and webdev are learned informally, this will always be an issue. Especially because unless you yourself need the assistance of accessibility software, it’s not obvious that things are broken, because they look good.
As an aside, I also feel like this is because webdev and design are taken less seriously by the world of programming. My college offered only one course on webdev and it mostly involved teaching PHP and jQuery. So no one takes it seriously and then they half-ass learning it.
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.
I have the say, after getting the hang of typescript, react, Vue and the tooling in general, I don't exactly hate it as much as I was led to believe I would. Also, typescript is very nice.
You don't need to use <new framework on reddit>! You don't need JSX! You don't need <CSS alternative>! Surely you still don't need to support <version of IE released in 1997>!? Vanilla JS is fine! Most modern browsers have rich enough feature sets that you don't even need transpilers like babel or dozens of polyfills (or Webpack, which almost nobody needs unless you're averaging 10M+ views a month...)
Or maybe you do, or think you do. Maybe your bosses made these choices in the past. Maybe you had to compromise in a team. In which case, I get it. You call the shots or you're working for someone who does.
But don't blame the language, the frameworks, or the ecosystem. JavaScript stepped up to the plate because nobody else did. Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications. Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations. And there's so much stuff on NPM because everyone who works in this space for a few years always gets a brilliant idea for some abstraction that could fix everyone's lives. Many people who make packages on NPM have only a few months experience programming in general, which is why (1) we have so many dumb problems that "professional" software organizations avoid and (2) there are so many new frameworks all the damn time.
And that's a good thing! The whole point of our field has been to make computers more helpful to humans. A dumb little language like JavaScript (or Python if that's your cup of tea) is the perfect candidate to take any normal person and get them working on critical business problems, whether those require web dev skills or data science or anything in between.
For most of computer history, the role of today's pioneers has always been to offer up their shoulders for the pioneers of tomorrow to stand on. I'm sure bare metal logic electricians made fun of COBOL developers when it first came out, and COBOL developers made fun of C developers, and C developers made fun of Java developers, and Java developers made fun of Python developers...JavaScript is neatly filling the need for a "stepping stone" language that gives everyone the power to build their own applications, as opposed to using someone else's application which previously cemented the wall between "users" and "developers."
I'm excited to unleash a world where everyone has the power and know-how to develop their own applications, social networks, data processing services, etc. It sure beats a world where only an elite few have the power to manipulate society and capitalism to such a large degree.
-
Full disclosure: I'm currently writing a web service back end for my small business in Racket, so I'm not just a JS developer. However, I have 4+ years of Node experience professionally and recreationally, having built Express/React/Mongo web apps, Electron desktop apps, and React Native mobile apps, so I've experienced most of the ecosystem at this point I think. It's really not that bad.
That said, you lose some of the advantages that come with modern tooling and frameworks such as easily breaking things down into components, using the latest language features before browsers ship them (I'm looking at you mobile safari) and handling things like minification, tree-shaking etc.
BUT that is OK, if you are happy with the tradeoff.
The biggest difference is: Before React/Vue, you usually told the UI how to change based on some action. Which is fine, but gets complex really quickly. Take something simple like a login form. Assume for a moment that there is a REST API for logging you in, so there’s no server-side rendered version of your login form. Now you want to make things a bit nicer for the user:
Obviously, the login form needs to be send via AJAX, because the REST API response delivers JSON and you don’t want to display raw JSON to the user.
There are two error states: no account with that email, wrong password. Assuming you take advantage of browser capabilities such as <input type="email" required> so you don't have to check this stuff in JS (although you might for styling reasons).
Your login form has 2 labels, 2 input boxes and a submit button.
Of course, while your send your login request via AJAX, you want to disable the login button, show a loading spinner, change the color of the button to the "disabled state". If there was an error, you want to re-enable the button, change its color and hide the loading spinner. Depending on the login error, you want to update the label text, the label color, the input border color. If the user enters something, you might want to update these three again so that it doesn't look like the new input still has an error. If the user entered the correct email, but a wrong password, you now need to: update all three to its original non-error state: the email label color, email label text, email input border color. You also want to update all three of the password field.
Futhermore, later you might introduce a toggle "show password", because people on mobile make mistakes when they enter their password. This turns the <input type="password"> into an <input type="text"> (or reverts it). If you click the toggle button, you also want to change the icon or the text of the button. Futhermore, if you submit the form, you might want to hide the password again. Whatever.
See, all of this can be done traditionally with server-side rendering. Some parts would be just fine, other parts are simply less convenient for the user. Sometimes, you don't get to decide to do it on the server, so you have to do it on the client in JS.
Now, do you want to tell the UI which part needs to update depending on what state you have? That is the traditional jQuery-style DOM manipulation way of writing UI code. In this very simple case of a login form, you usually have to update 6-8 elements for a very simple change in the state. This gets messy very fast.
What React/Vue/etc. solve is that you don't tell the UI how to update the DOM elements. You just say: newState = { emailError: 'Account does not exist', 'passwordError': null, formIsSubmitting: false } and write your UI so that it reacts to the state change.
Can you write this reactive code without a framework? Yes, you could, but honestly, give it a try. The fundamental question would be: Do you "hook" your code to the existing DOM or do you create all DOM elements on the fly in JS? Assuming the latter, you now have to write a lot of "document.createElement" calls. But do you want to re-create all elements when the state updates? You might lose stuff like the caret position in an input field. You might have to re-assign event listeners or whatever.
Thing is: Writing UI code that offers a great experience to the end user was never super easy to begin with.
A frontend designer's job is to manage the state of the visible UI controls. There are lots of requirements which evolve and change during the lifetime of the project. You need to encode the application state and transition the controls according to the state. Before react, you mostly kept some variables around somewhere, added some ifs and elses which update controls, handle some events, update the state and you extend and extend and extend... and finally you have a bowl of spaghetti with some state sprinkled all around.
React separates the state from the UI update phase. Simple and elegant.
Java executes faster than Node but is more verbose.
Choose the right tool for the job. I've put Node as a reverse proxy in front of Django, but now you can do JS in Nginx so I might not choose that pattern again.
We exist. I'm still forced into document mode 5 by the top level frame.
- `I’m no fortune teller, but I have a hunch a lot of teams are going to spend the next few years untangling a constellation of former “new hotnesses”`: I have seen this multiple times now, where a medium article (I was in fact able to find the exact article based on the stack used and the year in question) inspired someone to create a site with what was (at the time) the trendiest framework. Fast forward 2 years, and things are a complete mess. Patching of the node_modules folder, overloaded MongoDB instances on overpowered servers (just..create an index..), and dependencies so out of date the npm warnings/errors fill your entire screen when you npm install. I tried so hard to "update" the application, but it was hopeless. Spent hours migrating react versions, alpha version of material ui, spaghetti code etc, and eventually gave up. I had never before completely given up on a codebase like this, but updating/migrating things every single month is stressful and takes actual time away from improving the functionality and features of your own code, which brings me to the second quote
- `Every team I work with tells me how hard they’re trying to keep up with the Joneses.`: I love the new possibilities JS has unlocked for creating cool programs that run in the browser. WASM, service workers, etc. are cool innovations, as well the frameworks and packages made by people far more talented than I could ever be. But the way this new ecosystem works, I am constantly pressured by peers to uses the latest, trendiest, best ever tools. I'm fighting to maintain projects less than a year old without the "no one uses sass anymore, use postcss!" "no one uses webpack anymore, use rollup!". For personal projects, I have free reign, but I have lost the battle for stability in the workplace where the majority are more concerned with migrating to a new build tool, framework, or paradigm rather than maintaining existing code. Not to mention the utter disregard of semantic versioning both in workplaces and by package maintainers, causes me to wince in fear when I type `yarn upgrade` because things are almost guaranteed to break if it has been over a month since the last time I did so. By the time I have fixed up things to work again (looked at every github/website for discussion of migration or figuring it out manually) I am exhausted and have ran out of time for working on the codebase iteself.
- `Not super into the quasi-religious vibe of it all` I already said this in the previous bullet point, but people swear by their tools, and want to convert you to their tool of choice. Instead of "that's a nice project, but here's criticism of such and such" you get "that's a nice project, but why didn't you use Framework X for it??" (because framework x didn't even exist a year ago). I do enjoy certain benefits of modern JS, but I don't enjoy being forced to go along with the flow when I don't want to.
- `Trying to figure out what’s a real trend vs a flavor of the month` This one you have to spend a few months on when you start off in the world of modern JS. Once you've found your personal favorite, stick to it! A great thing about the massive size of the JS community is there is some framework/toolset somewhere that will fit you.
Javascript didn't "step up" to any plate. Browser vendors simply refused to support other languages.
> Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications.
Electron is there because software developers wanted to create apps with cheap labor and there were plenty of javascript web devs around.
> Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations.
Node is there because of SV hype and money, and no company should (or would) have the same employee handling "literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations," nor does knowing Javascript qualify a single person for all of these roles.
That's not a use case, it's a power fantasy.
I agree with most of your comment, although it seems as if you believe there was no open source development or public development of software before javascript came along, and the line you're drawing between "javascript" and "elitists manipulating society and capitalism" is specious, but none of what's good about javascript excuses what's bad about the ecosystem, culture and the increasing centralization and control over both by corporate interests.
No disrespect, it just feels like he's not spending the time necessary to understand how things work and instead of doing so, he just goes on and vents on his blog.
> I also got — and continue to get — a whole lot of (often private) correspondence from a slew of people who feel equally overwhelmed.
Adopting a new framework can be tricky. IMO it's okay to write about "the process of learning" to show that it isn't always a breeze. Posts like this can give perspective to both learners and experienced practitioners.
Speaking for myself, I've enjoyed learning React, though looking back on my first project I can see I've made some pretty bad mistakes with my use of state. I don't know if there is a guide I could have read to avoid these mistakes, or if I just needed to struggle through it.
It would be weird to go from a DSL and realize that to move forward you have to get good at general programming. I'm not sure that I would handle that transition very well.
Having done some significant work in vue and React and meteor, and played with a whole bunch of others, it is mostly about preference. React has a nice dev orietented mental model. As a true blooded programmer, none of them are that hard to work with once you get past their inital learning curves. I've generally swung towards to keeping things as close to HTML / CSS as much as possible to keep it realtively understandable for most any web "designer" ( so mostly I pick vue, though playing with svelte and that seems promising )
We can write re-usable components in pretty much any language with as bit of file organisation. So React takes a whole heap of convolution and tooling to end up in pretty much the same place as before, just written differently.
Don't get me wrong though, I have enjoyed learning it and it is very cool technology, and I'm still open to having that "aha" moment when I finally get why people think it's great. It just hasn't hit me yet.
React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration. Which increases reusability and helps further encapsulate the components.
One of the most obvious gains to me is helping manage huge CSS files in legacy projects [1]. Components are way better than a giant BEM'd [2] CSS file, it's much nicer writing .box in a <style scoped /> in Twitter.vue instead of .twitter__layoutBox among a ton of other nested layers. All just to avoid global clashes and maintain some sanity.
Or a ton of global jQuery plugins for select boxes and modals and everything else.
Everything is so much more portable across projects.
That's not even mentioning the whole plug-and-play reactivity that is baked in.
[1] Here's a good list of the problems of CSS-in-JS helps solve: https://i.imgur.com/LbE1kqc.png
But is this really true? If you have simple presentational components, this is probably true. But your app is tied together by "container components". The state is unique to the app you're writing. You have to somehow map the state to the components. Maybe you use "container components". In one project, you use Redux, in another, you drill props down to all children. In the next, there's React Context or whatever the next thing is. Do components load their own data (like some widgets) or is there a root component that loads all data and handles the state for the entire app?
I'd argue writing presentational components isn't that different from writing just HTML and CSS. The tough parts of React is where all the unique state logic is placed.
But this is like any abstraction in programming. When you have a function you want to be reusable you usually have to do some work to make it more portable across your codebase and create a proper flexible "interface" for it via arguments.
The UI components are particularily easy to reuse. If you look at something like Rebass it uses predefined constants to add consistency of values across the entire site + a theming system which simply tweaks those constants (ie, colors, the scales of font sizes across h1-h6, etc).
Utility-first CSS frameworks are awesome if you get past your first impression. I've been using TailwindCSS [0] both at work and for all my personal projects ever since I read Adam Wathan's justification on it [1]. In TailwindCSS those constants are configured in one place and generated at build time (through Rollup/Webpack/PostCSS etc.). Consistency and theming for free basically.
Even Bootstrap has now a decent collection of them in v4.
[0] https://tailwindcss.com/ [1] https://adamwathan.me/css-utility-classes-and-separation-of-...
Right now, for me, the main reason for choosing React on a project is staffing; the availability of enthusiastic devs is a major plus point. The flip side of this is it feels a bit like hiring JS devs 10 years or so ago at the height of jQuery's popularity -- you get people who can churn out decent code in that paradigm but will often miss easier ways to do things that rely on an understanding of the underlying technologies.
I worry that the underlying tooling and technologies for React too are far removed from most React devs daily experience, that because of this they won't make that transition to greater understanding. There's often ~one person on a React team who understands the build pipeline and that's a problem Have you ever come to a project and found an x-hundred line web pack config file? Yikes! Those things can be hard to un-pack and figure out what every piece is doing and why.
Sure you can, but only in that specific language, which sadly your browser won't understands.
I'm working with Struts 2 at my job sadly, when I started I quickly began to make components because it's much better than the usual copy-paste they were doing.
The components are great and works well, are not so hard to make (much harder than React but still accessible) but once it's rendered, that's it. You want to add an element using JS?
Well okay, you'll just add some kind of template that you will render in the JS, even more works, but that's fine. Thing is, you don't have access to parameters... well just add it in the JS initialization easy right? No they use OGNL, thus if anything is done programmatically (which it will, for concatenation or i18n, or whatever), most likely won't works.
Most time when the component change visually, the same change need to be done on JS too. Twice the time...
In the case of Struts, the components are also quite hard to imbricate into one another, which push toward even more code smell.
"There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.",
The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.
I now call them technical frontend developers and visual frontend developers during interviews. I am not sure what terms will stick in the end.
Our senior frontenders handle both the technical and the visual part.
We have some experienced senior full-stack developers who can work on anything from hosting, server-side code, client-side business logic in React, but they usually stop there and let visual frontenders implement the design.
Observing our junior frontend developers I noticed it is very difficult to be effective in both areas. You really need years of experience before you can grasp the whole thing.
Managing state and business logic is so different from implementing a design. It requires very different skills. I can really sympathize with traditional visual frontender feeling overwhelmed with the whole javascript madness that is going on. Companies who just dumped it on them because "it's frontend", are making a huge mistake.
I've never felt that way since with JS.
Backbone didn't have much appeal. Angular, I knew I didn't want to touch it with a ten foot pole. React was interesting, but usually more trouble than it was worth. Vue feels the nicest of the bunch, but not breathtaking.
I guess what I'm saying is that, after seeing jQuery, I knew I would not use anything else. It solved a problem so well (DOM manipulation) there was no need to.
With recent JS frameworks, it feels like we haven't even defined or come to agree on what the problem we are trying to solve is.
Again, jQuery was an easy sell. Saying manual DOM manipulation is messy… not so much.
Designers already suck so badly at HTML & CSS that getting them to do any wastes more time than it saves. They don't need to be let near any other implementation tech either, not Android layouts, not iOS storyboards, and not React.
Designers don't really want to do implementation either, why make them learn a bunch of things they don't care about?
That's first off an assumption, although I do see where you're coming from. The main thing is speeding up and removing the middle man - why separate design and implementation if you can do them at the same time? The tools are there.
So I don't think he's talking about making designers learn implementation. The point is that the scope of frontend development has expanded so much that it makes sense to split responsibility between "front of the frontend" UI responsibilities and "back of the frontend" responsibilities like managing state, cache invalidation, routing, etc.
In any case the line between design and dev turns gray when you consider that designers can't practically mock up designs for the web for every viewport size, define what every micro interaction looks like, etc. There are so many nuances to creating a great UX that it makes sense to have a class of front end devs with those kinds of proficiencies.
There's something to be said for constraints, and easy parse-ability
I experimented with a project once that could programmatically build a DSL for running e2e tests. The enabling factor was constrained html-like templates[0]. It would never have gotten even close to working with JSX.
[0] https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...
Like if it was Haskell or something I would be understanding, but this just sounds like lazy.
> I’ve done a CodeAcademy class, completed Wes Bos‘s React for Beginners course, bought books, listened to podcasts, and read tutorials. Hell, I even paid someone to build a side-project app I designed in React so I could learn how it works
> I’ve written elsewhere how I’ve never had a computer science course in my life, and I call myself a frontend designer,
> Tooling and build step stuff are tough to get my head around
Also it is hard to determine what the best way to solve a problem in React is when there are so many different versions and additional packages people are using (ex. Redux).
Then, start have your codebase grow and grow, and you will find yourself to rebuild it again and again. Good luck
I think the very near future will be web assembly code that paints a canvas. Mature desktop methods with GUI design tools will be ported to web assembler and retrofit for the web. QT5, imgui, are just the beginning.
I think a good exercise would be to open the Full Stack React book again and port the first few running examples to a Qt Quick Controls application and then target webassembler. I am willing to wager that anyone who gives it a real shot will be impressed at the productivity gains -- which generally stem from QML's expressiveness and not having to deal with React's over-complicated design. Not to mention, you'll not waste time because some component you made behaves differently across browsers. You'll also notice a complete lack of the dogma that tends accompany modern JS frameworks and libraries.
It also feels good to know that your UI may be a bit more performant that DOM based UI's.
Technologies for building UI's will forever be changing, so designers should be able to work while being agnostic to the UI's implementation details.
I secretly hope this becomes true. I always think back to how nearly everything done on the frontend are essentially hacks to really sex-up a document description language for scientists.
I think it would be really neat if we did end up building UI's in a responsive way like you describe. It would feel more like the right tool for the right job. But that seems so far away when I start to think about what it would take to get there.
Before React came around I wrote and used some mootools/prototype/jQuery, but very frankly didn't really know JavaScript and just used them for tricks like carousels or basic AJAXy things. For example, in the Django or Smarty/PHP days (yes, like I said, a long time at this) I just had regular old CSS/HTML with a whole set of "filters" in whatever the templating system was. It was very, very easy to read the docs and do |dateformats or something for example. I could also |sort things really easy. It was just a filter. I didn't need to learn the actual python and it already did the hard work to make sure whatever I had WAS sortable.
When I started getting into React I was somewhat taken aback. I needed to actually learn Javascript (for real this time) to just do basic things. I also needed to understand very Reacty type things like how things mount. States were fun and easy to understand, except dealing with previous states. With states I could replace all that jquery which was mostly me just adding and removing classes onto things anyway. That side was much better, but it took me months to actually learn enough JS to actually understand how the "template" format of a React component was structured. Also, EVERYTHING needed to be imported. Want to do some basic color stuff? There's a library to import. Want a way to truncate things? Sure, again, let's import something that works for more than just simple string limits. Eventually you end up just writing a lot of JS that does this without some huge dependency, but that took awhile to learn as well. The biggest thing I missed was something like Django's template docs. All that stuff was just built in, and I didn't need to piece it together myself. Ultimately I think that's what makes it harder. The world of Javascript is fractured at its core. Want to learn how to write a function? Which version? Have fun doing a google search and getting something that is the "right" way to do things. OK. Now it's fat arrows...etc. JS just has years of old examples available.
Once I got past all this, it was obviously fantastic and feels like the right way to do things. It let me realize some personal dreams by really building a design system of shared components, not just a CSS library. Now I could take those design skills and build out stateless components that you could piece together like lego bricks. Engineers would then take that stuff and build to their hearts content and I didn't have to worry so much about them abusing a selector. I could even document things and show real variations with very simple prop changes. All of this sounds pretty rote and is of course what React is there for, but man did it require much, much more knowledge that what I was doing for "frontend design" back in the sever side rendering days. To this day I know what redux, context and hooks do, but have real difficulty dealing with them day to day. It's beyond the rendered DOM and so far away from what I'm looking to do as a designer who just wants to make things look good.
I continue to think coding is invaluable for web designers and to be honest is the only true way to hit zenith in your understanding of the medium, but I really don't envy people starting from scratch that have React as the "easy" way to do things if they are moving from just handing you a mock. I think it used to be much easier to get into "coding" as a designer 10 years ago. It's likely why I run into more and more designers that simply aren't interested in it or think it is impossible. They work in these React houses and suddenly have to learn a whole lot more just to do the basics.
I guess what I'm trying to say is. Hey, I work at a big company with a great team doing what most people would consider high-level React work that is used by at least hundreds of engineers. But most days if I'm honest I struggle with it too, and I've been at it now for 20 years. That's totally normal if you still call yourself a "frontend designer" rather than "frontend engineer". I know and work with the later all the time. They are fantastic people with a different skillset even though we work within the same files.
Anyways, if you're a designer who hit the wall with this stuff: keep at it. You'll get there. The great part about React is that you can start small. Start with the React Create App and just build a widget. Don't jump into Gatsby and suddenly have to worry about GraphQL, routing, image resizing and all that stuff. Just build what you built in HTML, but in React. Add some props as "variables" in your document. Move on from there. You'll get there.
I still have trouble with JavaScript and have to look up how to deal with arrays and objects all the time. Maybe in 20 more years that part of my brain will match what I can do on the CSS / design side. Until then, thanks to all he engineer folks who put up with me and take on the hard stuff.
> The great part about React is that you can start small. Start with the React Create App and just build a widget
Great points! Your whole comment is worth reading.
PS. I had no idea Elastic open sources its internal React UI components. Interesting. (found this via your HN profile). Should I be using this if I want to provide an interface to an API that exposes an Elastic Search DB?
If you need that functionality these days Framer and it's bridge product is nearly magic. You can set up some basic shim wrappers on your React components and things work perfectly.
Hmm...
Instagram was the first time it was used to drive the whole page (rather than a small widget).
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.
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.
I'm not really worried about this causing spaghetti code because, well... I know how to program. I've always been mystified that salvation from bad architecture comes from frameworks.
I genuinely think picking React for a new project over Vue is a mistake.