Live data from Hacker News

Roadmap to becoming a React developer in 2018

github.com

101–110 of 153 posts

Re: Roadmap to becoming a React developer in 2018

#102
post #47
post #26

Earlier quoted context omitted.

As one grows old we learn to avoid learning every new fad until dust settles. I saved a few brain cells by not bothering with GWT, CoffeeScript, mootools, YUI, prototype...

Now is a good time to learn front-end tech. Skipping YUI was good, but you should learn at least one of Mithril, React, Preact, Inferno. I recommend Mithril for learning and React for job opportunities. It's OK to have skipped CoffeeScript, but you don't want to skip TypeScript in 2018. The past couple of years have been good as it has increasingly harmonized with ES6.

I'm perfectly happy in ClojureScript to be skipping TypeScript and most of the JS ecosystem :)

Not everything on the web has to use the normal stacks. I used TypeScript in the past but didn't enjoy the complexity of most JS libs, even with typings. Clojure was a breath of fresh air, and still is.

Re: Roadmap to becoming a React developer in 2018

#103
post #71
post #68

Earlier quoted context omitted.

That's really stretching the definition of "professional work". If you're just gluing third party components and libraries together you're going to end up with a bloated mess. This is why javascript/front-end developers get so much flak - there is a prevailing opinion that you can just fake it and not bother to learn best practices, not bother to test, and not bother to care about performance. If you do not consisten…

If you've invested the time to derive a first-principles understanding of why every element in a React environment works the way it does, and what the alternatives are, and why you're going to use any given alternative, I can understand being irritated with the idea that there's a happy path that people can traverse to get to your level of productivity with 1/50th the amount of effort. What I don't really get is the…

Its not so much about re-inventing the wheel but more about understanding how the underlying system actually works.

So yes, go ahead and use a framework if that helps but when your UI Designer gives you something that doesnt neatly fit into a framework component you need to know enough to implement it yourself right?

Also - understanding how it actually works also helps when the JS community rallies around the next big thing 6 months down the road. I still find a lot of devs who cant do basic DOM manipulation without pulling in a jquery dependency.

I’m by no means a full time UI/front end dev - I do it when I have to. Over the years as css has improved and my understanding has improved I find myself less inclined to use a framework because doing it yourself isnt difficult and you’re not stuck fixing bugs and issues in the underlying framework and fighting against it to do whatever weird thing your design requires.

Re: Roadmap to becoming a React developer in 2018

#104
post #63

I understand this is opinionated and "personal", but on the off chance that this might make React less intimidating, let me chime in and say that you can do professional work (and build pretty much any reasonable application) without: - really understanding "semantic HTML" (if you know what div's and span's are, you're ready to get to work), - understanding flexbox (you can, and many pro developers do, just use a CSS…

I've still not found the time to really look at reason+react - but I strongly suspect that the "return" on learning reasonml is much better than lodash+js+react+redux.

As for loads in a post es5 (never mind es6) world - I agree. I briefly contemplated adding lodash to a legacy project (jquery, not spa) - but found that es5 without any transpiling/shim gave me enough to do some functional refactoring without adding an additional dependency.

Anyone have experience with reasonml in a real, greenfield project?

Re: Roadmap to becoming a React developer in 2018

#105
post #41
post #34

Earlier quoted context omitted.

5 generations to make something that is less efficient (slow build times, caching not always possible) that straight up css processors. Its kinda sad really (but hey my css is in my js file now, so useful).

Yes, notice the trend: web develeoper > Javascript developer > React developer. Soon we'll have CSS developer as a career in itself.

Given that I, as a n00b, find JS – hell, even React – way simpler to master than CSS, that wouldn’t surprise me at all.

I don’t mean the syntax, of course. The syntax is trivially simple. Translating that to something that looks good and is laid out just as you want, oh boy.

CSS is by far the element of front-end development that I’m enjoying the least.

Re: Roadmap to becoming a React developer in 2018

#106
post #71

Earlier quoted context omitted.

If you've invested the time to derive a first-principles understanding of why every element in a React environment works the way it does, and what the alternatives are, and why you're going to use any given alternative, I can understand being irritated with the idea that there's a happy path that people can traverse to get to your level of productivity with 1/50th the amount of effort. What I don't really get is the…

Its not so much about re-inventing the wheel but more about understanding how the underlying system actually works. So yes, go ahead and use a framework if that helps but when your UI Designer gives you something that doesnt neatly fit into a framework component you need to know enough to implement it yourself right? Also - understanding how it actually works also helps when the JS community rallies around the next b…

I don't know if "difficult" is the word I would use. Is a mail merge in Microsoft Word "difficult"? I think probably not. But it would still take me longer to get a mail merge working in Office than it would for me to implement and test a topological sort or a breadth-first graph traversal. That's approximately how I feel about the level of difficulty involved in DIY-ing CSS and layout. I could get really good at it, I'm sure --- but why would I? Other people got these details right already, and did a better job of it than I would (it was, at the time, the most important thing they worked on, and a perfectly laid-out button or sidebar is always going to be very far down the list of most important thing I work on).

Honestly --- and this isn't fair but I am just being candid about my impressions --- the pushback I see to relying on frameworks reads to me as a combination of specialist front-end people feeling threatened and of dilettante developers being irritated that something might be invented somewhere other than here. But if you're using React at all, hasn't that ship sailed? Oh, wait, there are like 10 bespoke vdom JS frameworks now, so I guess it hasn't.

Buttons, sidebar, grid systems, and vdom libraries are commodities to me. I think they are and should be commodities to 80-90+% of all applications that get built anywhere. Build an online pharmacy or trading position and inventory tracker or continuous integration system or CDN console and I guarantee you that nobody who pays money for it will give a shit whether your buttons came from Foundation or you lovingly handcrafted them yourself.

Re: Roadmap to becoming a React developer in 2018

#107
post #65

Crazy to me how far we’ve come from HTML and some script tags. Part of me is really sad that the web is big and complicated and ugly now. I just don’t have the patience to read some new framework author’s long winded and grandiose tutorial and ode to themselves. Why is it so hard to do seemingly simple things? I can remember 10 years ago training up someone with no programming experience at all to competency in a few…

Modern programming languages are a lot more featureful and sophisticated than assembly language, and they change a lot more than instruction set architectures do. How is your lament different than that of an assembly language programmer, who might complain "crazy how far we've come from conditional jumps and some stack manipulation"? I'm 41 and got started in the 1990s, and those assembly advocates really did exist.…

The assembly people were cranks even in the 90s whereas this complaint, even when put inartfully or outright inaccurately is not completely nuts. In 20 years, people will hopefully wonder how it was that every runtime (or even framework) came with its own set (or multiple sets) of dependency management, build, test and god-knows-what-else toolchains that that do almost but not entirely the same thing as every other one.

Re: Roadmap to becoming a React developer in 2018

#108
post #65

Crazy to me how far we’ve come from HTML and some script tags. Part of me is really sad that the web is big and complicated and ugly now. I just don’t have the patience to read some new framework author’s long winded and grandiose tutorial and ode to themselves. Why is it so hard to do seemingly simple things? I can remember 10 years ago training up someone with no programming experience at all to competency in a few…

Modern programming languages are a lot more featureful and sophisticated than assembly language, and they change a lot more than instruction set architectures do. How is your lament different than that of an assembly language programmer, who might complain "crazy how far we've come from conditional jumps and some stack manipulation"? I'm 41 and got started in the 1990s, and those assembly advocates really did exist.…

There was a time when compiled languages compiled into a somewhat predictable finite sequence of machine instruction, and thus one might use them but still understand everything happening. I think that is less true of modern web frameworks.

Re: Roadmap to becoming a React developer in 2018

#109

I've never learned any programming language / framework with a step-by-step component learning. I usually grab a simple task ( make a todo app, make a hello world, etc. ) and do it. Funny enough I've worked with and know almost all of the yellow circles on this diagram only because I needed them at some point.

Therein lies the best [/s/career/life] advice I could possibly dispense: just DO things. Chase after the things that interest you and make you happy. Stop acting like you have a set path, because you don't. No one does. You shouldn't be trying to check off the boxes of life; they aren't real and they were created by other people, not you. There is no explicit path I'm following, and I'm not walking in anyone else's footsteps. I'm making it up as I go. - Charlie Hoehn

Re: Roadmap to becoming a React developer in 2018

#110
post #21

Earlier quoted context omitted.

> I've noticed this spirit of "learn everything" all over the React and JavaScript community, and I don't think it's a good thing. I strongly disagree there. The only way for an engineer to make good decisions as to what tools / framework to pick from is to know and understand as much tech as possible. It is fundamental for an engineer to do this job of tech-watching in order to not become religious and blinded by th…

I'd much rather work with a developer proficient with C, Java, JS, React, DDD and a deep knowledge of Unix than someone who has spent the majority of their time on JS, Backbone/Knockout/Angular/Ember/React/Vue/Mithril, Redux/MobX/Vuex and Grunt/Gulp/Brunch/Webpack. Knowing how a technology works is important. Knowing technologies needed to accomplish tasks to be done is important. Knowing seven different technologies…

Your entire JS ecosystem should be narrowed down to React, Webpack, and maybe Redux. Easy
Post reply on HN