> 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.
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.
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.
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 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.
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.
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:
> 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!
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.
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.
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.
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.
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.
I love Brad Frost's work and writing, but I seriously disagree with this.
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?
Perhaps. I don't know anything about how Netflix does their design. But the underlying point was that implementation details change, technologies change, and it's hard enough to keep up with the changes while you're focused solely on development.
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.
The expectation is already there. I feel sorry for designers who simply worked in html who's lives keep getting more difficult. At one point you drew in photoshop/sliced then you had bootstrap which would give you a base but you needed to override styles.
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..
Bigger companies will have more specialized design teams and more developer resources (for prototyping and production) to avoid generalist design-dev needs. This post sounds like they are aiming at smaller shops where designers are much more involved in touching the implemented product.
People are getting stuck on the word "designer." The point isn't that all designers need to be involved in implementation but that the scope of front end _web_ development has grown so wide that it makes sense to split the responsibility between "front of the frontend" and "back of the frontend."
> 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 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.
How many of us get to walk into green field projects or even decently architected projects? Accessibility isn’t too hard if you build conventions around doing it from the first commit, but adding aria tags and labels to 100s of old files is going to be a massive undertaking that few product managers will sign off on. I think it is less incompetence and more when it comes down to the wire, those are the first things to get cut or ignored.
It doesn’t really matter what’s there already. If your job this week is to add a new feature, spend some time this week thinking about accessibility. If you’re just fixing something old, then don’t worry about it.
I’m not even going to be prescriptive about how much time. If you have 5 minutes, fine, good.
The problem is that anyone can pick up design and web dev and get up and running fairly quickly, but very few intro tutorials even touch accessibility or get into it. Therefore beginners easily wind up doing things like using links or divs instead of buttons because buttons look bad by default, instead of overriding button css.
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 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.
The last time I did a bit of frontend for a side project was in 2004. Then I took a long break from dev and computers in general. Earlier this year I'd decided to brush up on the whole frontend/JS ecosystem. It was weird initially and there was a lot of friction, as I was especially fixated with a "why can't I stick this in a <script> tag, what even is NPM..." mindset.
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.
I continue to believe that the loudest perpetrators of JavaScript hate are those who overcomplicate simple things or follow other people's advice to overcomplicate simple things. Things like using SPAs for five page sites, throwing Redux into every CRA installation, npm installing useless packages like is-odd or leftpad (lol), etc.
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.
>JavaScript stepped up to the plate because nobody else did.
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.
You can, no-one is going to leap out of the bushes and mug you for doing so.
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.
You absolutely can, and should if you want to, just be prepared for people to look at you like you drive to work in an automobile made of logs and animal skins by pushing your feet against the road.
I suspect what corebit means is loading a script that has been manually created rather than a file that contains resources bundled by webpack or similar.
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.
Thank you. Of all things I've ever read about react, your post is the first one who clearly explains WHY we need something like react and what fundamental problem it solves.
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.
Even though I use quite a bit of modern JS, it's not the idea of react, vue or whatever frameworks and modern utilities that makes me dislike JS, it's what the author of the article mentioned under "stuff i’m still working through with react" that applies more generally to the community. Some examples:
- `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.
I've not found anything in JavaScript that replaces Django in terms of ecosystem and reliability. There's lots of attempts but Django and Rest Framework nail building out APIs.
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.
every time Brad Frost writes something a bit controversial, it always feels like he can write and understand html and css, but anything else (including React) is way over his head.
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.
For me, it's not that I'm overwhelmed by the learning. I understand the "what" and "how" just fine. But React is a paradigm shift that I have yet to fully grok the "Why" for. It often feels like I'm having to re-solve problems we've had solutions to for a decade, on top of all the brand new problems React introduces. The core problem React solves, "re-usable reactive components", just doesn't come to fruition in most projects I have seen. It mostly ends up in a greenfields component stew.
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.
What about the whole component based approached? You could certainly take a component based approach with simple code organization in HTML, CSS, and JS frontends. I've done that before, in a sort of pseduo-web components way using directories and naming schemes.
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.
> React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration
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.
It's true Redux/VueX creates a habit of coupling your components to the specific usecase. But I've been using them for over a year now and whenever I've had to reuse a component, often in very different environments, it takes about an hour of tweaking to make the component reusable. Sometimes you have to rewrite parts of the DOM to make it more flexible.
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).
On your last point, I feel like components this basic should really rather be addressed at the real theming level, i.e. in CSS.
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.
This chimes with my experience after 2 years of React dev I like it, it's fine, but on most projects I haven't really needed it and have found the tooling overhead can become quite onerous.
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.
> We can write re-usable components in pretty much any language with as bit of file organisation.
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.
Yeah - I've seen and worked with (very talented!) people like Brad, and I feel for them. They're good at working with this presentational stuff, but it's never been necessary to learn that when they're creating an <input> they're secretly creating an HTMLInputElement. And then one day, they're expected to learn this framework that fits so nicely with the frontend because they try to emulate that hierarchy of objects on the frontend and deal with them in code.
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.
I've always found it odd that many React devs just keep doubling down and insisting it is much better and that it would be a disaster doing it any other way with "magic" templating systems or anything closer to html/css.
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 )
> 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.
"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.
In our agency a lot of our backend developers have moved their work on the business logic side of the frontend with React, managing state and routes, interacting with API's. While the traditional frontend developers work more on the visual part of the frontend with styling, JSX, images, animations.
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 remember when I was messing with MooTools and Prototype and then I saw jQuery. OMG, yes, I want that! So powerful, freeing and easy.
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.
The problem being solved IS (manual) DOM manipulation. It's messy and error-prone. Using React et al to generate the DOM as a clear function of state is much better.
Agreed! It seems as though something will eventually come along and wholesale replace the need for React, Angular, Vue et al just as jQuery did to prototype, dojo, and moo.
Things I get from designers:
1. Wireframes
2. Layouts (bitmaps)
3. Assets (fonts, images)
(4. Occasionally, interactive prototypes made with designer-friendly tools.)
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?
The author makes the point that "frontend designer" may not be the right title, so perhaps "UI developer" or one of the other titles he listed is more appropriate.
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.
> 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.
> 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.
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.
I don't think it is the syntax that is difficult, it is the overall layout and design of a React app, and the tools that come along with it. When you start a website with regular HTML/CSS/JavaScript, you just open up index.html and start putting in HTML tags, and maybe add a .css or .js file. When you start a React app, you (usually) run create-react-app, which pulls in a million dependencies and tools you use to develop your app. Now in the long run, for a large app, those tools are useful since they make it easier to actually host your website somewhere, but the learning curve is far steeper than just opening up index.html in your web browser.
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).
React is more than JSX. I don't think the author is lazy. Some relevant points from the blog,
> 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
I think HTML is bad. I think DOM based development is bad. I really feel that Desktop UI development is much more mature and has much less legacy to compete with when developing a web UI.
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.
> I think HTML is bad. I think DOM based development is bad. I really feel that Desktop UI development is much more mature and has much less legacy to compete with when developing a web UI.
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.
Yep! Which is why I'm dismayed at seeing this trend among designers where they feel the need to learn to code. There exists, however implicitly, an interface between design and development. That interface needs to be preserved, and it gets weaker each time a designer decides they should learn to code UI's themselves.
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'm a "font-end designer". I've been one for since 2000 or so. To me, that basically meant I was a designer that could write HTML and CSS. At some point Sass was thrown into the stack and things became really awesome. I did this for very big companies and even my own startups that I sold.
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.
> 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
> 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?
It's Apache 2. You can use it for anything though we do road-map against our own uses of course (mostly Kibana). There's nothing specifically tied to ES in it. The only difference with our library vs. someone else is we tend to have to deal with things like data density, form layouts and visualizations more often than other folks.
No. I've seen the output and it's just not very usable.
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.
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.
The deeper I get into front end javascript the more I think Vanilla JS is the way to go. As it stands I am just using preact for rendering jsx, I am not using anything for state management or routing. I might as well hardcode most of my html, write some functions that target a few small areas of the dom, and some code triggered by 'onhashchange' that hides all but a single div so I can still be SPA.
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.
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.