> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air.
JSX is fine, the real power is building your HTML in pure JavaScript. I'll never go back to a template language, in my mind they're a fundamentally flawed design. They necessitate introducing extra concepts and implementing some magic rendering voodoo -- for what? So I can write my code twice, once in the JavaScript and once in whatever weird template directive language the framework uses.
So for me the only real alternative to JSX is to do elm-html style nested function calls which tends to be much uglier. JSX isn't perfect but it's the best we have by a mile.
I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in-javascript metalanguages are being discovered now as a cure for spaghetti frontend-plus-backend-rendered code.
>I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code,
Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers, I can't see how the industry will migrate back to server-side rendering in 3 years.
The unavoidable technical issue is the round-trip latency of the network. The same delays from the speed-of-light will still be there in 3 years. Most of the world is accessing the web through mobile phones which has worse latency than desktops. Server-side rendering (which means painful page reloads) is user hostile on slow network connections.
I don't think so, at least not for the kinds of apps I build. My biggest problem is largely around interactivity -- shuffling lots of data back-and-forth between the client and the server. If I'm going to have a SSR app with lots of AJAX code running on the client, I might as well just go all-client.
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:
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.
I totally get the preference for the JSX approach. Also echoing other commenters, CLJS/reagent and similar tools did a pretty amazing job of this some years ago.
But I think it is wise to consider that there are advantages and trade-offs to a compiled template approach as used by Angular, Svelte, and probably some others I’m forgetting.
* potentially more concise syntax
* potentially more familiar syntax
* do more of the work at compile time, less of it at runtime in downloaded code
* avoid the GC pressure and other overhead of VDOM
I was initially a pretty big fan of JSX, but after using Vue it just feels like extra overhead. In my experience, parsing complex JSX in my head results in constant context switches depending on whether the specific parts I'm looking at are closer to HTML or closer to JS. And for the tasks I've generally been doing at work, there rarely seems to be a good reason to combine the two. If I'm trying to fix a bug for example, it's almost always clearly restricted to either HTML, JS, or CSS. And I really appreciate how Vue minimizes the amount of code I need to search through in those situations.
I keep hearing all of these "Vue just makes more sense than React" converts, and I'm baffled. I recently did some Vue after doing React for a few years, and it felt like a major step backward. It felt very JSP - here was a different syntax that was HTML except when it chose not to be - managing data was done in a custom expression language, and I was left to figure out what scope a given value had. Need to loop something ten times? It's one tag with a special "v-for" property. Want do to that loop with a condition? Special "v-if" property, and is that evaluated in the scope of a variable created by v-for or not? No idea! And that's not even getting into the various parts a Vue component object has.
JSX is just javascript. It's HTML looking, but is ALL (not some) a wrapper to write a JS function that outputs HTML. Need to have a loop? Loop in JS. Need to have a conditional? Condition in JS. What scope? This is all a JS function, so the scope rules are all JS scope rules.
I have no idea if I'm a weird minority, or if I'm just running into more people that felt better with Vue than React, but I really don't understand why.
After doing Elm or PhoenixLiveView, I'll never go back to React stuff. Every time people trying to re-invent html, it will end up pretty much HTML. It's simple and powerful. The sad part is developer resources spent on optimizing for JS instead of joining force improving HTML standard.
I think you can get pretty close to the comfort of JSX with plain JS, without needing a preprocessor. Local development is so much nicer without webpack, babel, source maps, ...
I've been trying trying this out [1] with a thin 300-line DOM wrapper, and works wonderfully well so far.
There are also libraries like lit-html but I prefer to construct html as an object tree, and not a string.
Extra concepts in templates aren't that difficult, it's usually just binding directive, conditionals and loops. You know, the bread and butter of every programmer. How hard is that? I'd say not harder than learning the many nuances of JSX. And the magic rendering voodoo enables you to do compile-time optimizations, because of the limited set of directives supported by this magical templating engine.
Server side rendering has one big advantage - it's fast. Client side rendering frameworks may be easier and sexier, but serving html is always going to be faster.
If you need custom data in the page on a per request basis then SSR is usually the fastest method to generate the final HTML but it isn't the fastest method of getting something on the user's screen. Its "time to render" that counts, and that means doing as little work as possible to send something to the user.
Serving the same static, "prerendered" HTML file with no customization to every user is always going to be the fastest method of getting something to display in the user's browser, so perceptually it's much faster to serve a static html file and then hydrate it with any custom data using frontend JS.
I love Brad Frost's work and writing, but I seriously disagree with this.
Imagine being a designer at a place like Netflix. Your product is among the most ubiquitous in the world - if there's a device with any kind of screen, Netflix has an app for it.
Now imagine developing a skillset, as a designer, that totally locks you into one platform (the web in this case). It makes absolutely no sense. I don't care how "easy" React makes things, or how "easy" layout now is with CSS Grid. It takes serious time and effort to develop these skills.
So I ask myself, why would a designer do this? It's one thing to have domain-specific knowledge (iOS design is _very_ different from web, for example). It's another to have implementation-specific knowledge, which IMO a designer really doesn't need.
This is great and all for Netflix's web designers, but what about iOS, Android, Apple TV, Playstation, Xbox, Roku, etc etc etc?
Perhaps. I don't know anything about how Netflix does their design. But the underlying point was that implementation details change, technologies change, and it's hard enough to keep up with the changes while you're focused solely on development.
I'm not opposed to individual designers learning how to code, but my fear is that the industry will come to an expectation that designers should be able to build UI's. I think that's a very very bad idea.
Bigger companies will have more specialized design teams and more developer resources (for prototyping and production) to avoid generalist design-dev needs. This post sounds like they are aiming at smaller shops where designers are much more involved in touching the implemented product.
People are getting stuck on the word "designer." The point isn't that all designers need to be involved in implementation but that the scope of front end _web_ development has grown so wide that it makes sense to split the responsibility between "front of the frontend" and "back of the frontend."
> Crafting semantic HTML markup with a strong focus on accessibility, in order to make experiences that are friendly to browsers, assistive technologies, search engines, and other environments that can consume HTML.
> Creating CSS code that control the look and feel of the web experience, tackling colors, typography, responsive layout, animation, and any other visual aspect of the UI. Frontend designers architect resilient CSS code with a focus on modularity, flexibility, compatibility, and extensibility.
> Optimizing the performance of frontend code in order to create lightweight, fast-loading, snappy, jank-free experiences.
I can't help but chuckle at this. I admit that good frontend designers do this, but they are extremely rare. Judging solely by the top Google results, 95% of frontend designers don't do any of this: they don't care about accesibility, friendly experience, compatibility or anything like that.
I applaud the author for caring about these things. His website is the biggest evidence that he does, but most designers don't do these things.
How many of us get to walk into green field projects or even decently architected projects? Accessibility isn’t too hard if you build conventions around doing it from the first commit, but adding aria tags and labels to 100s of old files is going to be a massive undertaking that few product managers will sign off on. I think it is less incompetence and more when it comes down to the wire, those are the first things to get cut or ignored.
It doesn’t really matter what’s there already. If your job this week is to add a new feature, spend some time this week thinking about accessibility. If you’re just fixing something old, then don’t worry about it.
I’m not even going to be prescriptive about how much time. If you have 5 minutes, fine, good.
The problem is that anyone can pick up design and web dev and get up and running fairly quickly, but very few intro tutorials even touch accessibility or get into it. Therefore beginners easily wind up doing things like using links or divs instead of buttons because buttons look bad by default, instead of overriding button css.
And then usually you pile up thousands of kludges before someone blows a whistle and says “Hey, none of this is accessible!”, and then you look back at a mountain of inaccessible garbage you wrote and claim it’s too hard.
So long as design and webdev are learned informally, this will always be an issue. Especially because unless you yourself need the assistance of accessibility software, it’s not obvious that things are broken, because they look good.
As an aside, I also feel like this is because webdev and design are taken less seriously by the world of programming. My college offered only one course on webdev and it mostly involved teaching PHP and jQuery. So no one takes it seriously and then they half-ass learning it.
It's not that 95% of frontend designers don't care about accessibility...
It's that 95% of project managers just won't place accessibility concerns on the top of their Jira backlogs.
It took me six years of full-time and freelancing work to finally end up a company that does this. It's a rare thing in the industry to find a company that cares about, what is essentially, this usually untapped source of potential revenue.
The last time I did a bit of frontend for a side project was in 2004. Then I took a long break from dev and computers in general. Earlier this year I'd decided to brush up on the whole frontend/JS ecosystem. It was weird initially and there was a lot of friction, as I was especially fixated with a "why can't I stick this in a <script> tag, what even is NPM..." mindset.
I have the say, after getting the hang of typescript, react, Vue and the tooling in general, I don't exactly hate it as much as I was led to believe I would. Also, typescript is very nice.
I continue to believe that the loudest perpetrators of JavaScript hate are those who overcomplicate simple things or follow other people's advice to overcomplicate simple things. Things like using SPAs for five page sites, throwing Redux into every CRA installation, npm installing useless packages like is-odd or leftpad (lol), etc.
You don't need to use <new framework on reddit>! You don't need JSX! You don't need <CSS alternative>! Surely you still don't need to support <version of IE released in 1997>!? Vanilla JS is fine! Most modern browsers have rich enough feature sets that you don't even need transpilers like babel or dozens of polyfills (or Webpack, which almost nobody needs unless you're averaging 10M+ views a month...)
Or maybe you do, or think you do. Maybe your bosses made these choices in the past. Maybe you had to compromise in a team. In which case, I get it. You call the shots or you're working for someone who does.
But don't blame the language, the frameworks, or the ecosystem. JavaScript stepped up to the plate because nobody else did. Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications. Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations. And there's so much stuff on NPM because everyone who works in this space for a few years always gets a brilliant idea for some abstraction that could fix everyone's lives. Many people who make packages on NPM have only a few months experience programming in general, which is why (1) we have so many dumb problems that "professional" software organizations avoid and (2) there are so many new frameworks all the damn time.
And that's a good thing! The whole point of our field has been to make computers more helpful to humans. A dumb little language like JavaScript (or Python if that's your cup of tea) is the perfect candidate to take any normal person and get them working on critical business problems, whether those require web dev skills or data science or anything in between.
For most of computer history, the role of today's pioneers has always been to offer up their shoulders for the pioneers of tomorrow to stand on. I'm sure bare metal logic electricians made fun of COBOL developers when it first came out, and COBOL developers made fun of C developers, and C developers made fun of Java developers, and Java developers made fun of Python developers...JavaScript is neatly filling the need for a "stepping stone" language that gives everyone the power to build their own applications, as opposed to using someone else's application which previously cemented the wall between "users" and "developers."
I'm excited to unleash a world where everyone has the power and know-how to develop their own applications, social networks, data processing services, etc. It sure beats a world where only an elite few have the power to manipulate society and capitalism to such a large degree.
-
Full disclosure: I'm currently writing a web service back end for my small business in Racket, so I'm not just a JS developer. However, I have 4+ years of Node experience professionally and recreationally, having built Express/React/Mongo web apps, Electron desktop apps, and React Native mobile apps, so I've experienced most of the ecosystem at this point I think. It's really not that bad.
>JavaScript stepped up to the plate because nobody else did.
Javascript didn't "step up" to any plate. Browser vendors simply refused to support other languages.
> Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications.
Electron is there because software developers wanted to create apps with cheap labor and there were plenty of javascript web devs around.
> Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations.
Node is there because of SV hype and money, and no company should (or would) have the same employee handling "literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations," nor does knowing Javascript qualify a single person for all of these roles.
That's not a use case, it's a power fantasy.
I agree with most of your comment, although it seems as if you believe there was no open source development or public development of software before javascript came along, and the line you're drawing between "javascript" and "elitists manipulating society and capitalism" is specious, but none of what's good about javascript excuses what's bad about the ecosystem, culture and the increasing centralization and control over both by corporate interests.
Even though I use quite a bit of modern JS, it's not the idea of react, vue or whatever frameworks and modern utilities that makes me dislike JS, it's what the author of the article mentioned under "stuff i’m still working through with react" that applies more generally to the community. Some examples:
- `I’m no fortune teller, but I have a hunch a lot of teams are going to spend the next few years untangling a constellation of former “new hotnesses”`: I have seen this multiple times now, where a medium article (I was in fact able to find the exact article based on the stack used and the year in question) inspired someone to create a site with what was (at the time) the trendiest framework. Fast forward 2 years, and things are a complete mess. Patching of the node_modules folder, overloaded MongoDB instances on overpowered servers (just..create an index..), and dependencies so out of date the npm warnings/errors fill your entire screen when you npm install. I tried so hard to "update" the application, but it was hopeless. Spent hours migrating react versions, alpha version of material ui, spaghetti code etc, and eventually gave up. I had never before completely given up on a codebase like this, but updating/migrating things every single month is stressful and takes actual time away from improving the functionality and features of your own code, which brings me to the second quote
- `Every team I work with tells me how hard they’re trying to keep up with the Joneses.`: I love the new possibilities JS has unlocked for creating cool programs that run in the browser. WASM, service workers, etc. are cool innovations, as well the frameworks and packages made by people far more talented than I could ever be. But the way this new ecosystem works, I am constantly pressured by peers to uses the latest, trendiest, best ever tools. I'm fighting to maintain projects less than a year old without the "no one uses sass anymore, use postcss!" "no one uses webpack anymore, use rollup!". For personal projects, I have free reign, but I have lost the battle for stability in the workplace where the majority are more concerned with migrating to a new build tool, framework, or paradigm rather than maintaining existing code. Not to mention the utter disregard of semantic versioning both in workplaces and by package maintainers, causes me to wince in fear when I type `yarn upgrade` because things are almost guaranteed to break if it has been over a month since the last time I did so. By the time I have fixed up things to work again (looked at every github/website for discussion of migration or figuring it out manually) I am exhausted and have ran out of time for working on the codebase iteself.
- `Not super into the quasi-religious vibe of it all` I already said this in the previous bullet point, but people swear by their tools, and want to convert you to their tool of choice. Instead of "that's a nice project, but here's criticism of such and such" you get "that's a nice project, but why didn't you use Framework X for it??" (because framework x didn't even exist a year ago). I do enjoy certain benefits of modern JS, but I don't enjoy being forced to go along with the flow when I don't want to.
- `Trying to figure out what’s a real trend vs a flavor of the month` This one you have to spend a few months on when you start off in the world of modern JS. Once you've found your personal favorite, stick to it! A great thing about the massive size of the JS community is there is some framework/toolset somewhere that will fit you.
every time Brad Frost writes something a bit controversial, it always feels like he can write and understand html and css, but anything else (including React) is way over his head.
No disrespect, it just feels like he's not spending the time necessary to understand how things work and instead of doing so, he just goes on and vents on his blog.
For me, it's not that I'm overwhelmed by the learning. I understand the "what" and "how" just fine. But React is a paradigm shift that I have yet to fully grok the "Why" for. It often feels like I'm having to re-solve problems we've had solutions to for a decade, on top of all the brand new problems React introduces. The core problem React solves, "re-usable reactive components", just doesn't come to fruition in most projects I have seen. It mostly ends up in a greenfields component stew.
We can write re-usable components in pretty much any language with as bit of file organisation. So React takes a whole heap of convolution and tooling to end up in pretty much the same place as before, just written differently.
Don't get me wrong though, I have enjoyed learning it and it is very cool technology, and I'm still open to having that "aha" moment when I finally get why people think it's great. It just hasn't hit me yet.
What about the whole component based approached? You could certainly take a component based approach with simple code organization in HTML, CSS, and JS frontends. I've done that before, in a sort of pseduo-web components way using directories and naming schemes.
React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration. Which increases reusability and helps further encapsulate the components.
One of the most obvious gains to me is helping manage huge CSS files in legacy projects [1]. Components are way better than a giant BEM'd [2] CSS file, it's much nicer writing .box in a <style scoped /> in Twitter.vue instead of .twitter__layoutBox among a ton of other nested layers. All just to avoid global clashes and maintain some sanity.
Or a ton of global jQuery plugins for select boxes and modals and everything else.
Everything is so much more portable across projects.
That's not even mentioning the whole plug-and-play reactivity that is baked in.
This chimes with my experience after 2 years of React dev I like it, it's fine, but on most projects I haven't really needed it and have found the tooling overhead can become quite onerous.
Right now, for me, the main reason for choosing React on a project is staffing; the availability of enthusiastic devs is a major plus point. The flip side of this is it feels a bit like hiring JS devs 10 years or so ago at the height of jQuery's popularity -- you get people who can churn out decent code in that paradigm but will often miss easier ways to do things that rely on an understanding of the underlying technologies.
I worry that the underlying tooling and technologies for React too are far removed from most React devs daily experience, that because of this they won't make that transition to greater understanding. There's often ~one person on a React team who understands the build pipeline and that's a problem Have you ever come to a project and found an x-hundred line web pack config file? Yikes! Those things can be hard to un-pack and figure out what every piece is doing and why.
> We can write re-usable components in pretty much any language with as bit of file organisation.
Sure you can, but only in that specific language, which sadly your browser won't understands.
I'm working with Struts 2 at my job sadly, when I started I quickly began to make components because it's much better than the usual copy-paste they were doing.
The components are great and works well, are not so hard to make (much harder than React but still accessible) but once it's rendered, that's it. You want to add an element using JS?
Well okay, you'll just add some kind of template that you will render in the JS, even more works, but that's fine. Thing is, you don't have access to parameters... well just add it in the JS initialization easy right? No they use OGNL, thus if anything is done programmatically (which it will, for concatenation or i18n, or whatever), most likely won't works.
Most time when the component change visually, the same change need to be done on JS too. Twice the time...
In the case of Struts, the components are also quite hard to imbricate into one another, which push toward even more code smell.
Yeah - I've seen and worked with (very talented!) people like Brad, and I feel for them. They're good at working with this presentational stuff, but it's never been necessary to learn that when they're creating an <input> they're secretly creating an HTMLInputElement. And then one day, they're expected to learn this framework that fits so nicely with the frontend because they try to emulate that hierarchy of objects on the frontend and deal with them in code.
It would be weird to go from a DSL and realize that to move forward you have to get good at general programming. I'm not sure that I would handle that transition very well.
I've always found it odd that many React devs just keep doubling down and insisting it is much better and that it would be a disaster doing it any other way with "magic" templating systems or anything closer to html/css.
Having done some significant work in vue and React and meteor, and played with a whole bunch of others, it is mostly about preference. React has a nice dev orietented mental model. As a true blooded programmer, none of them are that hard to work with once you get past their inital learning curves. I've generally swung towards to keeping things as close to HTML / CSS as much as possible to keep it realtively understandable for most any web "designer" ( so mostly I pick vue, though playing with svelte and that seems promising )
> I also got — and continue to get — a whole lot of (often private) correspondence from a slew of people who feel equally overwhelmed.
Adopting a new framework can be tricky. IMO it's okay to write about "the process of learning" to show that it isn't always a breeze. Posts like this can give perspective to both learners and experienced practitioners.
Speaking for myself, I've enjoyed learning React, though looking back on my first project I can see I've made some pretty bad mistakes with my use of state. I don't know if there is a guide I could have read to avoid these mistakes, or if I just needed to struggle through it.
"There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.",
The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.
In our agency a lot of our backend developers have moved their work on the business logic side of the frontend with React, managing state and routes, interacting with API's. While the traditional frontend developers work more on the visual part of the frontend with styling, JSX, images, animations.
I now call them technical frontend developers and visual frontend developers during interviews. I am not sure what terms will stick in the end.
Our senior frontenders handle both the technical and the visual part.
We have some experienced senior full-stack developers who can work on anything from hosting, server-side code, client-side business logic in React, but they usually stop there and let visual frontenders implement the design.
Observing our junior frontend developers I noticed it is very difficult to be effective in both areas. You really need years of experience before you can grasp the whole thing.
Managing state and business logic is so different from implementing a design. It requires very different skills.
I can really sympathize with traditional visual frontender feeling overwhelmed with the whole javascript madness that is going on. Companies who just dumped it on them because "it's frontend", are making a huge mistake.
I remember when I was messing with MooTools and Prototype and then I saw jQuery. OMG, yes, I want that! So powerful, freeing and easy.
I've never felt that way since with JS.
Backbone didn't have much appeal.
Angular, I knew I didn't want to touch it with a ten foot pole.
React was interesting, but usually more trouble than it was worth.
Vue feels the nicest of the bunch, but not breathtaking.
I guess what I'm saying is that, after seeing jQuery, I knew I would not use anything else.
It solved a problem so well (DOM manipulation) there was no need to.
With recent JS frameworks, it feels like we haven't even defined or come to agree on what the problem we are trying to solve is.
The problem being solved IS (manual) DOM manipulation. It's messy and error-prone. Using React et al to generate the DOM as a clear function of state is much better.
Agreed! It seems as though something will eventually come along and wholesale replace the need for React, Angular, Vue et al just as jQuery did to prototype, dojo, and moo.
Things I get from designers:
1. Wireframes
2. Layouts (bitmaps)
3. Assets (fonts, images)
(4. Occasionally, interactive prototypes made with designer-friendly tools.)
Designers already suck so badly at HTML & CSS that getting them to do any wastes more time than it saves. They don't need to be let near any other implementation tech either, not Android layouts, not iOS storyboards, and not React.
Designers don't really want to do implementation either, why make them learn a bunch of things they don't care about?
The author makes the point that "frontend designer" may not be the right title, so perhaps "UI developer" or one of the other titles he listed is more appropriate.
So I don't think he's talking about making designers learn implementation. The point is that the scope of frontend development has expanded so much that it makes sense to split responsibility between "front of the frontend" UI responsibilities and "back of the frontend" responsibilities like managing state, cache invalidation, routing, etc.
In any case the line between design and dev turns gray when you consider that designers can't practically mock up designs for the web for every viewport size, define what every micro interaction looks like, etc. There are so many nuances to creating a great UX that it makes sense to have a class of front end devs with those kinds of proficiencies.
> Designers don't really want to do implementation either, why make them learn a bunch of things they don't care about?
That's first off an assumption, although I do see where you're coming from. The main thing is speeding up and removing the middle man - why separate design and implementation if you can do them at the same time? The tools are there.
Readit News
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.
Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers, I can't see how the industry will migrate back to server-side rendering in 3 years.
The unavoidable technical issue is the round-trip latency of the network. The same delays from the speed-of-light will still be there in 3 years. Most of the world is accessing the web through mobile phones which has worse latency than desktops. Server-side rendering (which means painful page reloads) is user hostile on slow network connections.
Svelte also extremely promising. It brings a brilliant hybrid solution to the table.
Perhaps it might look better if there's a bigger example?
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.
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
JSX is just javascript. It's HTML looking, but is ALL (not some) a wrapper to write a JS function that outputs HTML. Need to have a loop? Loop in JS. Need to have a conditional? Condition in JS. What scope? This is all a JS function, so the scope rules are all JS scope rules.
I have no idea if I'm a weird minority, or if I'm just running into more people that felt better with Vue than React, but I really don't understand why.
I'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...
Serving the same static, "prerendered" HTML file with no customization to every user is always going to be the fastest method of getting something to display in the user's browser, so perceptually it's much faster to serve a static html file and then hydrate it with any custom data using frontend JS.
I don't want to program iOS and Android and web.
Plenty of gigs available.
Imagine being a designer at a place like Netflix. Your product is among the most ubiquitous in the world - if there's a device with any kind of screen, Netflix has an app for it.
Now imagine developing a skillset, as a designer, that totally locks you into one platform (the web in this case). It makes absolutely no sense. I don't care how "easy" React makes things, or how "easy" layout now is with CSS Grid. It takes serious time and effort to develop these skills.
So I ask myself, why would a designer do this? It's one thing to have domain-specific knowledge (iOS design is _very_ different from web, for example). It's another to have implementation-specific knowledge, which IMO a designer really doesn't need.
This is great and all for Netflix's web designers, but what about iOS, Android, Apple TV, Playstation, Xbox, Roku, etc etc etc?
I'm not opposed to individual designers learning how to code, but my fear is that the industry will come to an expectation that designers should be able to build UI's. I think that's a very very bad idea.
> Creating CSS code that control the look and feel of the web experience, tackling colors, typography, responsive layout, animation, and any other visual aspect of the UI. Frontend designers architect resilient CSS code with a focus on modularity, flexibility, compatibility, and extensibility.
> Optimizing the performance of frontend code in order to create lightweight, fast-loading, snappy, jank-free experiences.
I can't help but chuckle at this. I admit that good frontend designers do this, but they are extremely rare. Judging solely by the top Google results, 95% of frontend designers don't do any of this: they don't care about accesibility, friendly experience, compatibility or anything like that.
I applaud the author for caring about these things. His website is the biggest evidence that he does, but most designers don't do these things.
I’m not even going to be prescriptive about how much time. If you have 5 minutes, fine, good.
And then usually you pile up thousands of kludges before someone blows a whistle and says “Hey, none of this is accessible!”, and then you look back at a mountain of inaccessible garbage you wrote and claim it’s too hard.
So long as design and webdev are learned informally, this will always be an issue. Especially because unless you yourself need the assistance of accessibility software, it’s not obvious that things are broken, because they look good.
As an aside, I also feel like this is because webdev and design are taken less seriously by the world of programming. My college offered only one course on webdev and it mostly involved teaching PHP and jQuery. So no one takes it seriously and then they half-ass learning it.
It's that 95% of project managers just won't place accessibility concerns on the top of their Jira backlogs.
It took me six years of full-time and freelancing work to finally end up a company that does this. It's a rare thing in the industry to find a company that cares about, what is essentially, this usually untapped source of potential revenue.
I have the say, after getting the hang of typescript, react, Vue and the tooling in general, I don't exactly hate it as much as I was led to believe I would. Also, typescript is very nice.
You don't need to use <new framework on reddit>! You don't need JSX! You don't need <CSS alternative>! Surely you still don't need to support <version of IE released in 1997>!? Vanilla JS is fine! Most modern browsers have rich enough feature sets that you don't even need transpilers like babel or dozens of polyfills (or Webpack, which almost nobody needs unless you're averaging 10M+ views a month...)
Or maybe you do, or think you do. Maybe your bosses made these choices in the past. Maybe you had to compromise in a team. In which case, I get it. You call the shots or you're working for someone who does.
But don't blame the language, the frameworks, or the ecosystem. JavaScript stepped up to the plate because nobody else did. Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications. Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations. And there's so much stuff on NPM because everyone who works in this space for a few years always gets a brilliant idea for some abstraction that could fix everyone's lives. Many people who make packages on NPM have only a few months experience programming in general, which is why (1) we have so many dumb problems that "professional" software organizations avoid and (2) there are so many new frameworks all the damn time.
And that's a good thing! The whole point of our field has been to make computers more helpful to humans. A dumb little language like JavaScript (or Python if that's your cup of tea) is the perfect candidate to take any normal person and get them working on critical business problems, whether those require web dev skills or data science or anything in between.
For most of computer history, the role of today's pioneers has always been to offer up their shoulders for the pioneers of tomorrow to stand on. I'm sure bare metal logic electricians made fun of COBOL developers when it first came out, and COBOL developers made fun of C developers, and C developers made fun of Java developers, and Java developers made fun of Python developers...JavaScript is neatly filling the need for a "stepping stone" language that gives everyone the power to build their own applications, as opposed to using someone else's application which previously cemented the wall between "users" and "developers."
I'm excited to unleash a world where everyone has the power and know-how to develop their own applications, social networks, data processing services, etc. It sure beats a world where only an elite few have the power to manipulate society and capitalism to such a large degree.
-
Full disclosure: I'm currently writing a web service back end for my small business in Racket, so I'm not just a JS developer. However, I have 4+ years of Node experience professionally and recreationally, having built Express/React/Mongo web apps, Electron desktop apps, and React Native mobile apps, so I've experienced most of the ecosystem at this point I think. It's really not that bad.
Javascript didn't "step up" to any plate. Browser vendors simply refused to support other languages.
> Electron is there because nothing else could provide the same level of power for total novices to come in and make groundbreaking applications.
Electron is there because software developers wanted to create apps with cheap labor and there were plenty of javascript web devs around.
> Node is there because nothing else let you hire a guy who could handle literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations.
Node is there because of SV hype and money, and no company should (or would) have the same employee handling "literally every single aspect of your business's digital presence, from front end sites to internal employee portals to mobile apps to APIs to vendor integrations," nor does knowing Javascript qualify a single person for all of these roles.
That's not a use case, it's a power fantasy.
I agree with most of your comment, although it seems as if you believe there was no open source development or public development of software before javascript came along, and the line you're drawing between "javascript" and "elitists manipulating society and capitalism" is specious, but none of what's good about javascript excuses what's bad about the ecosystem, culture and the increasing centralization and control over both by corporate interests.
We exist. I'm still forced into document mode 5 by the top level frame.
- `I’m no fortune teller, but I have a hunch a lot of teams are going to spend the next few years untangling a constellation of former “new hotnesses”`: I have seen this multiple times now, where a medium article (I was in fact able to find the exact article based on the stack used and the year in question) inspired someone to create a site with what was (at the time) the trendiest framework. Fast forward 2 years, and things are a complete mess. Patching of the node_modules folder, overloaded MongoDB instances on overpowered servers (just..create an index..), and dependencies so out of date the npm warnings/errors fill your entire screen when you npm install. I tried so hard to "update" the application, but it was hopeless. Spent hours migrating react versions, alpha version of material ui, spaghetti code etc, and eventually gave up. I had never before completely given up on a codebase like this, but updating/migrating things every single month is stressful and takes actual time away from improving the functionality and features of your own code, which brings me to the second quote
- `Every team I work with tells me how hard they’re trying to keep up with the Joneses.`: I love the new possibilities JS has unlocked for creating cool programs that run in the browser. WASM, service workers, etc. are cool innovations, as well the frameworks and packages made by people far more talented than I could ever be. But the way this new ecosystem works, I am constantly pressured by peers to uses the latest, trendiest, best ever tools. I'm fighting to maintain projects less than a year old without the "no one uses sass anymore, use postcss!" "no one uses webpack anymore, use rollup!". For personal projects, I have free reign, but I have lost the battle for stability in the workplace where the majority are more concerned with migrating to a new build tool, framework, or paradigm rather than maintaining existing code. Not to mention the utter disregard of semantic versioning both in workplaces and by package maintainers, causes me to wince in fear when I type `yarn upgrade` because things are almost guaranteed to break if it has been over a month since the last time I did so. By the time I have fixed up things to work again (looked at every github/website for discussion of migration or figuring it out manually) I am exhausted and have ran out of time for working on the codebase iteself.
- `Not super into the quasi-religious vibe of it all` I already said this in the previous bullet point, but people swear by their tools, and want to convert you to their tool of choice. Instead of "that's a nice project, but here's criticism of such and such" you get "that's a nice project, but why didn't you use Framework X for it??" (because framework x didn't even exist a year ago). I do enjoy certain benefits of modern JS, but I don't enjoy being forced to go along with the flow when I don't want to.
- `Trying to figure out what’s a real trend vs a flavor of the month` This one you have to spend a few months on when you start off in the world of modern JS. Once you've found your personal favorite, stick to it! A great thing about the massive size of the JS community is there is some framework/toolset somewhere that will fit you.
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.
We can write re-usable components in pretty much any language with as bit of file organisation. So React takes a whole heap of convolution and tooling to end up in pretty much the same place as before, just written differently.
Don't get me wrong though, I have enjoyed learning it and it is very cool technology, and I'm still open to having that "aha" moment when I finally get why people think it's great. It just hasn't hit me yet.
React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration. Which increases reusability and helps further encapsulate the components.
One of the most obvious gains to me is helping manage huge CSS files in legacy projects [1]. Components are way better than a giant BEM'd [2] CSS file, it's much nicer writing .box in a <style scoped /> in Twitter.vue instead of .twitter__layoutBox among a ton of other nested layers. All just to avoid global clashes and maintain some sanity.
Or a ton of global jQuery plugins for select boxes and modals and everything else.
Everything is so much more portable across projects.
That's not even mentioning the whole plug-and-play reactivity that is baked in.
[1] Here's a good list of the problems of CSS-in-JS helps solve: https://i.imgur.com/LbE1kqc.png
[2] http://getbem.com/
Right now, for me, the main reason for choosing React on a project is staffing; the availability of enthusiastic devs is a major plus point. The flip side of this is it feels a bit like hiring JS devs 10 years or so ago at the height of jQuery's popularity -- you get people who can churn out decent code in that paradigm but will often miss easier ways to do things that rely on an understanding of the underlying technologies.
I worry that the underlying tooling and technologies for React too are far removed from most React devs daily experience, that because of this they won't make that transition to greater understanding. There's often ~one person on a React team who understands the build pipeline and that's a problem Have you ever come to a project and found an x-hundred line web pack config file? Yikes! Those things can be hard to un-pack and figure out what every piece is doing and why.
Sure you can, but only in that specific language, which sadly your browser won't understands.
I'm working with Struts 2 at my job sadly, when I started I quickly began to make components because it's much better than the usual copy-paste they were doing.
The components are great and works well, are not so hard to make (much harder than React but still accessible) but once it's rendered, that's it. You want to add an element using JS?
Well okay, you'll just add some kind of template that you will render in the JS, even more works, but that's fine. Thing is, you don't have access to parameters... well just add it in the JS initialization easy right? No they use OGNL, thus if anything is done programmatically (which it will, for concatenation or i18n, or whatever), most likely won't works.
Most time when the component change visually, the same change need to be done on JS too. Twice the time...
In the case of Struts, the components are also quite hard to imbricate into one another, which push toward even more code smell.
It would be weird to go from a DSL and realize that to move forward you have to get good at general programming. I'm not sure that I would handle that transition very well.
Having done some significant work in vue and React and meteor, and played with a whole bunch of others, it is mostly about preference. React has a nice dev orietented mental model. As a true blooded programmer, none of them are that hard to work with once you get past their inital learning curves. I've generally swung towards to keeping things as close to HTML / CSS as much as possible to keep it realtively understandable for most any web "designer" ( so mostly I pick vue, though playing with svelte and that seems promising )
> 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.
Deleted Comment
"There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.",
The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.
I now call them technical frontend developers and visual frontend developers during interviews. I am not sure what terms will stick in the end.
Our senior frontenders handle both the technical and the visual part.
We have some experienced senior full-stack developers who can work on anything from hosting, server-side code, client-side business logic in React, but they usually stop there and let visual frontenders implement the design.
Observing our junior frontend developers I noticed it is very difficult to be effective in both areas. You really need years of experience before you can grasp the whole thing.
Managing state and business logic is so different from implementing a design. It requires very different skills. I can really sympathize with traditional visual frontender feeling overwhelmed with the whole javascript madness that is going on. Companies who just dumped it on them because "it's frontend", are making a huge mistake.
I've never felt that way since with JS.
Backbone didn't have much appeal. Angular, I knew I didn't want to touch it with a ten foot pole. React was interesting, but usually more trouble than it was worth. Vue feels the nicest of the bunch, but not breathtaking.
I guess what I'm saying is that, after seeing jQuery, I knew I would not use anything else. It solved a problem so well (DOM manipulation) there was no need to.
With recent JS frameworks, it feels like we haven't even defined or come to agree on what the problem we are trying to solve is.
Again, jQuery was an easy sell. Saying manual DOM manipulation is messy… not so much.
Designers already suck so badly at HTML & CSS that getting them to do any wastes more time than it saves. They don't need to be let near any other implementation tech either, not Android layouts, not iOS storyboards, and not React.
Designers don't really want to do implementation either, why make them learn a bunch of things they don't care about?
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.
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.