11 ms·

Front-end design, React, and a bridge over the great divide

204 points by kimsk112 7y ago

throwaway8879 7y ago
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.
- nexuist 7y ago
  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.
  - corebit 7y ago
    But seriously why can’t I just do modern webdev with a <script src=“”>?
    - krapp 7y ago
      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.
    - dbetteridge 7y ago
      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.
    - grayed-down 7y ago
      Amen brother!
    - recursive 7y ago
      Wait, is there some other way to load scripts now? Asking for a friend...
      - arethuza 7y ago
        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.
    - WA 7y ago
      You can, but have you tried it? 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.
ng12 7y ago
> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. JSX is fine, the real power is building your HTML in pure JavaScript. I'll never go back to a template language, in my mind they're a fundamentally flawed design. They necessitate introducing extra concepts and implementing some magic rendering voodoo -- for what? So I can write my code twice, once in the JavaScript and once in whatever weird template directive language the framework uses. So for me the only real alternative to JSX is to do elm-html style nested function calls which tends to be much uglier. JSX isn't perfect but it's the best we have by a mile.
- cljs-js-eval 7y ago
  You should check out CLJS's reagent. It mixes the best of both worlds, everything is a plain CLJS object without special syntax, but it's also obviously HTML/CSS: [:div {:style {:display "flex", :flex-direction "row"}} [:label {:for "email"}] [:input {:type "text"}]]
  - rhaksw 7y ago
    is this much different than JSX? <div style="display: flex; flex-direction: row"> <label for="email"/> <input type="text"/> </div> I definitely want to try CLJS some time. edit Oh I see. You don't need the extra {} to jump into JS mode. And, CLJS requires : to denote keys. I think as long as my editor colors the syntax appropriately I'm okay with either.
    - cljs-js-eval 7y ago
      Not really - and that's why I like it. I like JSX too.
    - rafd 7y ago
      The difference is that in the cljs version you are writing clojure at all times using clojure data structures and types (vector, map, keyword, string) which lets you manipulate and generate things easily, and, you don't have to jump between "jsx" mode and "JS" mode.
snide 7y ago
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.
lone_haxx0r 7y ago
> 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.
- ericmcer 7y ago
  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.
  - erikpukinskis 7y ago
    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.
- bobthepanda 7y ago
  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.
jypepin 7y ago
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.
- rhaksw 7y ago
  he writes, > 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.
- cljs-js-eval 7y ago
  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.
- keithnz 7y ago
  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 )
patientplatypus 7y ago
This feels so foreign to me. Just...use React? JSX syntax isn't hard :< Like if it was Haskell or something I would be understanding, but this just sounds like lazy.
- rhaksw 7y ago
  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
- GhostVII 7y ago
  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).
  - bromuro 7y ago
    Please don’t stop creating your website n the way you need it. It worked 15 years ago and it still does. Then, start have your codebase grow and grow, and you will find yourself to rebuild it again and again. Good luck
  - davidjnelson 7y ago
    Building a complex user interface requires an incredible amount of experience in software architecture to do well.
chadlavi 7y ago
Anyone else using Firefox get a big ol security warning when you try to access brad frost's site?
- helb 7y ago
  No, but he's got a self-signed certificate there, so you'll get that warning when trying to access via https (the link posted to HN is just http).
externalreality 7y ago
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.
- tenaciousDaniel 7y ago
  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.
- Yhippa 7y ago
  > 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.
tenaciousDaniel 7y ago
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?
- baddox 7y ago
  I thought Netflix was pretty notable for using React Native or something similar in most or all of its native apps.
  - tenaciousDaniel 7y ago
    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.
    - wolco 7y ago
      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..
fevangelou 7y ago
So, if you read between the lines, React was basically built for a better "Like" button according to Dan's blog post here: https://overreacted.io/the-elements-of-ui-engineering/ https://overreacted.io/the-elements-of-ui-engineering/ Hmm...
- efdee 7y ago
  React was written for Instagram. Nothing to do with Facebook's Like button.
  - danabramov 7y ago
    That’s inaccurate. React originally was extracted from the Ads codebase. (Complex forms for creating ads.) Instagram was the first time it was used to drive the whole page (rather than a small widget).
swsieber 7y ago
> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. 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-dsls-in-kotlin/ https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...
lacampbell 7y ago
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.
Kaotique 7y ago
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.
sanitycheck 7y ago
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?
- Cthulhu_ 7y ago
  > 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.
- jameal 7y ago
  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.
tambourine_man 7y ago
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.
- mattacular 7y ago
  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.
- robertoandred 7y ago
  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.
  - tambourine_man 7y ago
    I’m not convinced. Again, jQuery was an easy sell. Saying manual DOM manipulation is messy… not so much.
beders 7y ago
"everything is a component" That is a major misconception. In reality, that is simply not the case. (see all those 'container' like components trying to tame underlying components and the awful state juggling dance we are now accustomed to.) And most JS frameworks confuse the logical structure of an app with the 'physical' structure of the DOM. Components are in the end rendered sub-trees in the DOM. But that forces you to lay out your app logic along these lines. It's limiting, it's wrong and there is a very good reason why there's a C in MVC. It stands to argue we dismissed the C part in the front-end world way too easily.
- ng12 7y ago
  > And most JS frameworks confuse the logical structure of an app with the 'physical' structure of the DOM. Because that's what JavaScript does. How is it any different than document.getElementById or the window event handling system? The point is if we're going to do it we might as well do it well.
lloydatkinson 7y ago
I already loved the productivity of Vue and after using React for a while it makes me appreciate Vue even more. I genuinely think picking React for a new project over Vue is a mistake.
metsong 7y ago
Hi dude,are you a hacker? Can you do me a favor to break into a illegal web in china(it's a web of bitcoin trade,but it's forbidden by Chinese government). It's a very simple job to a professional man. Contact me: xuechs@gmail.com. I wish your reply , and get money together.

204 points by kimsk112 7y ago

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.

nexuist 7y ago
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.
- corebit 7y ago
  But seriously why can’t I just do modern webdev with a <script src=“”>?
  - krapp 7y ago
    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.
  - dbetteridge 7y ago
    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.
  - grayed-down 7y ago
    Amen brother!
  - recursive 7y ago
    Wait, is there some other way to load scripts now? Asking for a friend...
    - arethuza 7y ago
      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.
  - WA 7y ago
    You can, but have you tried it? 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.

ng12 7y ago

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

cljs-js-eval 7y ago
You should check out CLJS's reagent. It mixes the best of both worlds, everything is a plain CLJS object without special syntax, but it's also obviously HTML/CSS: [:div {:style {:display "flex", :flex-direction "row"}} [:label {:for "email"}] [:input {:type "text"}]]
- rhaksw 7y ago
  is this much different than JSX? <div style="display: flex; flex-direction: row"> <label for="email"/> <input type="text"/> </div> I definitely want to try CLJS some time. edit Oh I see. You don't need the extra {} to jump into JS mode. And, CLJS requires : to denote keys. I think as long as my editor colors the syntax appropriately I'm okay with either.
  - cljs-js-eval 7y ago
    Not really - and that's why I like it. I like JSX too.
  - rafd 7y ago
    The difference is that in the cljs version you are writing clojure at all times using clojure data structures and types (vector, map, keyword, string) which lets you manipulate and generate things easily, and, you don't have to jump between "jsx" mode and "JS" mode.

snide 7y ago

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.

lone_haxx0r 7y ago

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

ericmcer 7y ago
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.
- erikpukinskis 7y ago
  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.
bobthepanda 7y ago
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.

jypepin 7y ago

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.

rhaksw 7y ago
he writes, > 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.
cljs-js-eval 7y ago
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.
keithnz 7y ago
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 )

patientplatypus 7y ago

This feels so foreign to me. Just...use React? JSX syntax isn't hard :< Like if it was Haskell or something I would be understanding, but this just sounds like lazy.

rhaksw 7y ago
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
GhostVII 7y ago
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).
- bromuro 7y ago
  Please don’t stop creating your website n the way you need it. It worked 15 years ago and it still does. Then, start have your codebase grow and grow, and you will find yourself to rebuild it again and again. Good luck
- davidjnelson 7y ago
  Building a complex user interface requires an incredible amount of experience in software architecture to do well.

chadlavi 7y ago

Anyone else using Firefox get a big ol security warning when you try to access brad frost's site?

helb 7y ago
No, but he's got a self-signed certificate there, so you'll get that warning when trying to access via https (the link posted to HN is just http).

externalreality 7y ago

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.

tenaciousDaniel 7y ago
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.
Yhippa 7y ago
> 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.

tenaciousDaniel 7y ago

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?

baddox 7y ago
I thought Netflix was pretty notable for using React Native or something similar in most or all of its native apps.
- tenaciousDaniel 7y ago
  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.
  - wolco 7y ago
    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..

fevangelou 7y ago

So, if you read between the lines, React was basically built for a better "Like" button according to Dan's blog post here: https://overreacted.io/the-elements-of-ui-engineering/ https://overreacted.io/the-elements-of-ui-engineering/ Hmm...

efdee 7y ago
React was written for Instagram. Nothing to do with Facebook's Like button.
- danabramov 7y ago
  That’s inaccurate. React originally was extracted from the Ads codebase. (Complex forms for creating ads.) Instagram was the first time it was used to drive the whole page (rather than a small widget).

swsieber 7y ago

> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. 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-dsls-in-kotlin/ https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...

lacampbell 7y ago

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.

Kaotique 7y ago

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.

sanitycheck 7y ago

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?

Cthulhu_ 7y ago
> 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.
jameal 7y ago
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.

tambourine_man 7y ago

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.

mattacular 7y ago
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.
robertoandred 7y ago
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.
- tambourine_man 7y ago
  I’m not convinced. Again, jQuery was an easy sell. Saying manual DOM manipulation is messy… not so much.

beders 7y ago

"everything is a component" That is a major misconception. In reality, that is simply not the case. (see all those 'container' like components trying to tame underlying components and the awful state juggling dance we are now accustomed to.) And most JS frameworks confuse the logical structure of an app with the 'physical' structure of the DOM. Components are in the end rendered sub-trees in the DOM. But that forces you to lay out your app logic along these lines. It's limiting, it's wrong and there is a very good reason why there's a C in MVC. It stands to argue we dismissed the C part in the front-end world way too easily.

ng12 7y ago
> And most JS frameworks confuse the logical structure of an app with the 'physical' structure of the DOM. Because that's what JavaScript does. How is it any different than document.getElementById or the window event handling system? The point is if we're going to do it we might as well do it well.

lloydatkinson 7y ago

I already loved the productivity of Vue and after using React for a while it makes me appreciate Vue even more. I genuinely think picking React for a new project over Vue is a mistake.

metsong 7y ago

Hi dude,are you a hacker? Can you do me a favor to break into a illegal web in china(it's a web of bitcoin trade,but it's forbidden by Chinese government). It's a very simple job to a professional man. Contact me: xuechs@gmail.com. I wish your reply , and get money together.