> 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.
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:
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.
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.
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?
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.
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.
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.
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 )
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?
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.
[+] [-] ng12|6 years ago|reply
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.
[+] [-] zbentley|6 years ago|reply
[+] [-] cljs-js-eval|6 years ago|reply
[+] [-] kylecordes|6 years ago|reply
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
[+] [-] tuesdayrain|6 years ago|reply
[+] [-] Existenceblinks|6 years ago|reply
[+] [-] bwindels|6 years ago|reply
I've been trying trying this out [1] with a thin 300-line DOM wrapper, and works wonderfully well so far.
There are also libraries like lit-html but I prefer to construct html as an object tree, and not a string.
1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...
[+] [-] dsego|6 years ago|reply
[+] [-] dahfizz|6 years ago|reply
[+] [-] shareIdeas|6 years ago|reply
I don't want to program iOS and Android and web.
[+] [-] tenaciousDaniel|6 years ago|reply
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|6 years ago|reply
[+] [-] seanmcdirmid|6 years ago|reply
[+] [-] jameal|6 years ago|reply
[+] [-] lone_haxx0r|6 years ago|reply
> 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|6 years ago|reply
[+] [-] bobthepanda|6 years ago|reply
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.
[+] [-] dentemple|6 years ago|reply
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.
[+] [-] tenaciousDaniel|6 years ago|reply
[+] [-] throwaway8879|6 years ago|reply
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.
[+] [-] jypepin|6 years ago|reply
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.
[+] [-] ehnto|6 years ago|reply
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.
[+] [-] cljs-js-eval|6 years ago|reply
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|6 years ago|reply
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 )
[+] [-] Kaotique|6 years ago|reply
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.
[+] [-] tambourine_man|6 years ago|reply
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.
[+] [-] robertoandred|6 years ago|reply
[+] [-] mattacular|6 years ago|reply
[+] [-] sanitycheck|6 years ago|reply
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?
[+] [-] jameal|6 years ago|reply
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.
[+] [-] Cthulhu_|6 years ago|reply
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.
[+] [-] swsieber|6 years ago|reply
There's something to be said for constraints, and easy parse-ability
I experimented with a project once that could programmatically build a DSL for running e2e tests. The enabling factor was constrained html-like templates[0]. It would never have gotten even close to working with JSX.
[0] https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...
[+] [-] patientplatypus|6 years ago|reply
Like if it was Haskell or something I would be understanding, but this just sounds like lazy.
[+] [-] GhostVII|6 years ago|reply
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).
[+] [-] rhaksw|6 years ago|reply
> 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
[+] [-] externalreality|6 years ago|reply
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.
[+] [-] Yhippa|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] snide|6 years ago|reply
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.
[+] [-] rhaksw|6 years ago|reply
> 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?
[+] [-] Ibethewalrus|6 years ago|reply
[+] [-] fevangelou|6 years ago|reply
Hmm...
[+] [-] efdee|6 years ago|reply
[+] [-] beders|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] lacampbell|6 years ago|reply
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.
[+] [-] lloydatkinson|6 years ago|reply
I genuinely think picking React for a new project over Vue is a mistake.
[+] [-] chadlavi|6 years ago|reply
[+] [-] helb|6 years ago|reply
[+] [-] metsong|6 years ago|reply
[deleted]