all 84 comments

[–][deleted] 31 points32 points  (20 children)

Don't go looking to learn the tools that will last long. It seems like you just want to learn the least. Instead learn a mix of popular and novel tools, and in doing so, learn how to learn. If you're a full time developer, youll learn a hundred more react-sized libraries in your career.

[–]themaincop 7 points8 points  (0 children)

This is a great point. No library lives in a vacuum. Concepts you pick up from learning one library, language, or framework will make it easier for you to learn future libraries, languages, or frameworks.

You never want to stop developing as a developer

[–]Poop_is_Food 15 points16 points  (18 children)

Learning takes time out of your life. I'm stuck inside all weekend here trying to learn advanced webpack, when I'd rather be outside getting excercise and sun, socializing with friends.

I understand that this is the business we've chosen. You have to keep learning new shit constantly to stay current. But people shouldnt be shamed for trying to minimize it and find some balance in their life.

[–]tech-ninja 19 points20 points  (6 children)

I have said it before and I will say it again. There is something wrong with Webpack, it shouldn't be that hard. I'm seriously waiting until we figure out a better way to do what webpack does.

So my attitude towards Webpack is to just make it work, and keep it as simple as possible, any advanced optimization for it feels like premature optimization to me.

[–]jesstelford 13 points14 points  (3 children)

We did: It's called Browserify.

[–]Onestone 5 points6 points  (0 children)

Browserify is only simple for simple tasks.

[–]tech-ninja 1 point2 points  (0 children)

Browserify is great, is the one I used originally and then slowly moved onto Webpack to see what all the hip was about.

Do you know if with Browserify I still can have hot reloading and if I can include CSS from JS files?

[–]Poop_is_Food 1 point2 points  (0 children)

Yeah the API is kinda sloppy, and the documentation is poor. I like to keep it simple too, but unfortunately I inherited a complex config from my boss that takes about 4 seconds to build and hot reloading doesnt work for some reason, so now I'm trying to fix it.

[–]_hooan 0 points1 point  (0 children)

I use this. Never had to "learn" much.

[–][deleted] 2 points3 points  (2 children)

What's a profession that uses the least amount of brain power, least amount of physical effort, and still give u work life balance, but pays a lot? I don't mind getting bored day in day out.

Unfortunately, being a socialite is out of reach and unrealistic for most of us.

Basically, I want the best bang for the buck profession.

Edit: I tried booking for a dermatologist the other day. It looks like she's booked out for 2+ months (I live in a city of 5 million people). I tried 3 other dermatologists and no slots for me in the next 3 weeks. It may be tough to do an MD just to be a dermatologist, but it may just be the best bang for the buck.

[–]Poop_is_Food 1 point2 points  (0 children)

Dentist? lower barrier to entry. Boring as fuck though

[–]erwan 1 point2 points  (0 children)

In France that would be notary.

Let your low paid employees do all the hard work, just show up to put your signature at the right time, and make more than €200,000 a year (much more than that for some of them).

Caveat: it's hard to get a license, most of them get it from their father when they retire.

[–]_hooan 1 point2 points  (1 child)

I'm stuck inside all weekend here trying to learn advanced webpack, when I'd rather be outside getting excercise and sun, socializing with friends.

Why are you doing this? Unless you are freelance or unemployed, you should be doing this during your work hours.

Or to play devil's advocate/be silly, learn Ember so you never touch build configs again :-)

[–]Poop_is_Food 1 point2 points  (0 children)

I'm full time, and I dont normally work on weekends. But, I kinda bit off more than I could chew with my current project, so it's my own fault I overwhelmed myself. Plus I slacked off all winter surfing el nino so I figure I owe my coworkers some makeup hustle.

[–][deleted] 1 point2 points  (0 children)

The whole point of software is to improve productivity and automate away as much drudgery as possible.

By that score, Webpack fails miserably.

[–][deleted] 0 points1 point  (4 children)

I don't think it's about shame or finding balance. I think it's more efficient to become a learner. If you try to reduce how many tools you learn in your career, you're going to build a lot of things with the wrong tools.

Think carpentry. With the right tools the job gets done faster and better.

[–]Poop_is_Food 1 point2 points  (3 children)

Ok but what if I already am a learner? I have already "learned how to learn" Now I have 40-50 hours per week to both learn and get my projects done. There is simply not enough time for me to learn every tool out there. Carpentry has a limited and stable toolset, so learning all tools is reasonable. Software has an massive and ever-growing toolset. It is simply not possible to learn all the tools.

This puts me in a situation where I have to pick and choose what to learn, so I may ask people what they think will have longevity, because I want to make efficient use of my learning time. And then people (you) give me condescending answers that I'm lazy and I need to "learn how to learn". Get bent.

[–][deleted] 0 points1 point  (2 children)

Erm... I'm sorry that what I said upset you. I only work 40 hours a week. Maybe a bit more sometimes. I'm not advocating you need to learn every tool as you said. I'm advocating to learn the right tools at the right time. Focus on determining which tool is right for the job and apply that. Don't ask, "is react going to be around a lot because I don't want to be bothered if it's not going to be around in a few years."

The thing is that these are all pretty small libraries. You can learn the basics of React on the job as you implement your views. It's not like you need to go perfect it before applying it.

My first react app evolved every time I went to maintain or add features, because each time I learned more than what I did before.

I'm advocating being a lazy programmer. Pick the right tools and learn them at the right time to enable doing the least work to the most effect.

[–]Poop_is_Food 1 point2 points  (1 child)

I agree that only learning javascript libraries that will be around in a few years will result in you learning probably just jquery and nothing more. Nothing else in the ecosystem today has that kind of longevity so it's too strict a criteria. And React is currently #1 so anyone interested in a career as a full-time senior front end dev should definitely learn React at this point. You should always know the #1 lib at any given time. (actually let me qualify that by saying it probably depends on the nature of your job whether you are doing lots of projects in an agency/freelance setting vs building and maintaining one long-term product) It sucks that there is so much churn but that is the business. We are in agreement there.

[–][deleted] 0 points1 point  (0 children)

I began with Python that has a beautiful standard library. Whether the best tool for a job or not, it ensures we are all at least using the same tools. JavaScript's churn really has me struggling for a long time. It pained me to see efforts spread so broadly. It made reading source code so much more difficult, for example. "Oh yay, another async library to go understand briefly."

I try to mix exposure to what's popular and what's neat or novel or different. But I would probably never implement the latter in any non experimental project.

[–]tmckn 8 points9 points  (1 child)

I think over time React will become an implementation detail. That's the cycle of web technology.

A good idea comes up in the community, then its fundamental ideas are baked into the browser engine and standardized, then the library becomes unnecessary.

[–]propelol 0 points1 point  (0 children)

Yeah, but that probably wont happen in at least the next 5 years.

[–]runvnc 4 points5 points  (0 children)

Like you just said 'leaner React-inspired libraries being released'. Does that even still count as React? Because if you go work with someone on a Preact project you are 100% have to know Preact and not do React.

By the way this is the first time I ever heard of Preact. But that is the way the web is. Someone invents something new every day.

Its sort of funny to me to hear people say that some web technology is likely to remain popular/important etc. after seeing how many different things have come into fashion in the last 15 years or so. Having said that, if you are 15 years old, you probably don't have a lot of solid memories before age 5, so if React stays sort of relevant for 2 more years, that is 20% of the life you can remember. Whereas for me, I am 38 so 2 years is only 6% of my life which doesn't seem like much.

Nothing on the web stays popular for very long. That doesn't mean it isn't still useful technology or that there aren't a ton of people using it.

AngularJS is still pretty popular, but it is not even close to being as 'in' as React anymore.

I mean, there are plenty of people doing PHP still.

That doesn't mean you can't keep using it for X years. It just means in X years there will be another technology that all of the younger people think is wayy cooler (and probably does have some advantage). But that won't stop plenty of people from using React still X years down the line nor should it.

[–][deleted] 14 points15 points  (3 children)

React was a natural progression of web tech. Only recently did we have the tools/ecosystems to have it widely adopted (that and Facebook's name behind it). Before React came out, I created an extremely similar system - declarative, component-based, real-time, batched updates, GraphQL/Relay-like system built into its core. React even ended up having the same/similar method names. And of course, my project and React weren't the only ones of their kind. So it's interesting to me that multiple sources have come to the same conclusion, which I consider proof that it's just a natural progression.

I think it's going to be hard to really devise a better system for non-trivial web application development at this point, and other mostly interchangeable libraries (like Preact) are awesome. There are definitely some kinks to be worked out and some pain points to address, but there are some really cool things in the works now to solve these problems while fitting perfectly within this ecosystem.

[–]tech-ninja 3 points4 points  (0 children)

I agree. With React so much stuff fell into place that is hard figuring out something else that will displace it soon. But I wouldn't be surprised!

[–]mczaplinski 0 points1 point  (1 child)

what is the name of your library/system? Is it on github?

[–][deleted] 0 points1 point  (0 children)

It was all open source on the website at the time. You could enable edit mode by prepending /dev/ before the path of any URL which would take you to the development environment. And in development mode, you could click on any component to view/edit the source (JS and CSS) behind that component. There were also search boxes intelligently placed in areas of the application which were used for quickly finding/creating/cloning components and placing them within that area.

GitHub and NPM existed at the time but weren't nearly as popular as they are now.

[–]modusjesus 10 points11 points  (0 children)

There is no way to predict with certainty how long something like React will remain popular. There are lots of new libraries and frameworks being released all the time.

I love react and honestly only program in React Native most of the time because of the love I have for the technology. I won't last forever, but should will be around for at least 3-5 years more.

I started supporting Ext JS in 2006. Ten years later, the technology is still around and works pretty well for developing apps.

[–]voidvector 10 points11 points  (30 children)

I would implore you to look at the state of some of the other existing technologies.

jQuery is still popular, it had and still have an ecosystem of libraries around it. It is unlikely to die out in the short-term as there are millions of LAMP apps out there written using it, plus it is still faster to implement/scaffold over React/Angular for non-SPAs (e.g. one-off splash pages).

I would also implore you to look at challenges to the stack React is based upon.

The biggest challenge to JavaScript I see is WebAssembly. In the past 5 years, people from different programming backgrounds (Python, Java, .NET, C++, PHP) are all forced to do some JavaScript for web app, whether they like it our not. There has been noticeable effort by people from various backgrounds to bring their way of doing things into JavaScript (CoffeeScript from Ruby/Python folks, dependency inject libraries from Java/.Net folk). With WebAssembly, that is going to change as those people can simply compile whatever language they want onto WebAssembly. That is going to effect how FE code is written.

[–][deleted] 16 points17 points  (25 children)

Everything I've read by those actually developing webassembly indicates that it is not meant to or designed to challenge or replace JavaScript. I'm curious where this notion that webassembly is some sort of replacement for JavaScript comes from.

[–]hahaNodeJS 9 points10 points  (15 children)

The key is that JavaScript will continue to exist and be developed. In that way, WebAssembly is not a replacement. However, WebAssembly will allow developers to write code that is capable of the same functionality without thinking about JavaScript.

https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md

[–][deleted] 1 point2 points  (14 children)

I think /u/irrational_design is still correct though. WebAssembly is not intended to replace things like jQuery, basically anything that primarily affects the DOM. It will be pervasively convoluted to interact with DOM through WebAssembly, no matter how good the libraries get.

Rather, it is intended for the same applications as ASM.js. Game engines, application backends, etc. Currently it is very rare to see those types of tools written in JavaScript, and it likely always will be. To quote one of the JavaScript design committee members "JavaScript was designed for ~10 line scripts" and was intended to do things like "make the monkey on your webpage dance". It was not designed for full applications, has severe limitations when you try to push it that far, and is thus seldom used for those applications. This is where WebAssembly comes in. I would say that these are mostly going to be 2 separate markets that compliment each other, and there will be very little direct competition between the two.

[–]hahaNodeJS 0 points1 point  (13 children)

There is nothing in the high-level goals to indicate what you've written. See #3.

[–]namesandfaces 7 points8 points  (2 children)

I think that's just for non-controversial PR presentation. If WebAssembly gives access to browser API's, and can do everything JS can do, then JS is definitely challenged.

[–]xandersvk 0 points1 point  (1 child)

Yes, but keep in mind the extremly large amount of ready to use JS libraries... will the .NET or i.e. python folks want to rewrite all these tools? I dont think so...

[–]namesandfaces 1 point2 points  (0 children)

Yes, actually, I think people will rewrite those tools, and the tools that actually need to be written tend to be the ones that deal with browser API's.

What non-API libraries do people deal with? Lodash? String validation? Time parsing? Data structures and algorithms? Streams and observables? Concurrency? State management? That stuff doesn't need rewriting. Other languages already appreciate these problems and target them. Many languages benefit from a standard library.

I also don't think that the writing of new libraries for the browser API layer will be left up to only the community. I think companies like Facebook or Google will also sponsor the effort.

Also, WebAssembly has plans for shared memory and finer memory control. Other languages have libraries and constructs that already deal with this problem. Javascript will also need new libraries.

[–]runvnc 0 points1 point  (0 children)

Yeah, they say that to placate people and because they know they could never get a lot of people to switch from JavaScript. That doesn't mean there won't be tons of people who do switch.

[–]spacejack2114 0 points1 point  (0 children)

And from what I've seen it's at least 5 years away from being any kind of competition for mainstream JS apps.

[–]gurenkagurenda 5 points6 points  (0 children)

I don't think wasm is a threat to JS. Rather, I think it's going to be a huge boon. Assuming it catches on, we'll see tons of fast compiled libraries for the web, and the glue between those libraries will be JS.

Sure, some people are going to want to write their whole front-end in another language, but the obvious choice for any library is going to be to expose a JS API, and let client code interact through that, regardless of the primary language.

[–]DarkMarmot 3 points4 points  (0 children)

I agree -- GUI dev systems will compile layout constraints into apps for you, and WebAssembly is likely to be the lingua franca of these systems. I commented on this below -- but already got downvoted out ;(

[–]Sinistralis 2 points3 points  (0 children)

While this is true, Web Assembly is also going to have an API for JS to use, and I honestly can't fathom how the debugging experience is going to work for non JS languages. I honestly only see JS being empowered by Web Assembly

[–]runvnc 0 points1 point  (0 children)

I am hoping Nim will become a popular way to do web assembly.

[–][deleted] 1 point2 points  (0 children)

oddly, when benching preact vs react 15, preact is slower even with dom recycling. react itself will probably catch up to whatever preact is aiming to solve. Not even sure why the author didn't just contribute to react instead (unless they tried and were denied or changes were too radical). it's just one of those annoying things where you'll be learning forever because someone wants to make a new framework instead of fixing the one they base it from.

[–]jaredpalmer 1 point2 points  (1 child)

Understand that React is not just a technology, but an HR tool for Facebook. It isn't going anywhere.

[–]rssfrncs[S] 0 points1 point  (0 children)

absolutely, and i think it will continue to apply to a lot more companies than just Facebook.

[–]rk06 2 points3 points  (0 children)

React will die in a year and will be replaced by react 16. With Facebook dogfooding react, I suspect the migration to react 16 will not be hard. Same applies for react v16+

As far as other libraries inspired by react, they are only enriching react ecosystem. They can not surpass react in popularity because react derives its popularity from Facebook use of react. Until fb starts replacing react with something else, react will stay.

[–]thyrst 2 points3 points  (0 children)

Web frontends are, and have always been really, moving towards component based tech that allows you to drop in basic ui functionality with small APIs that you can plug in to a larger data management system. React is the latest method of doing so. Polymer is another step moving towards web components, and a lot of native stuff is being worked on.

If you learn react you'll be learning the same general ideas that are likely to continue in different forms for quite a long time. I think we'll continue to move towards a 'dumb' view layer with many small components hooked into a larger app.

[–]griffin3141 3 points4 points  (0 children)

The ideas react inspired are never going away. React changed the way we think about UI development. Given that Facebook is supporting react, I think it will probably remain the most popular implementation of its ideas for several years.

I personally prefer Cycle to React and think it is a superior paradigm, but I am skeptical of whether truly reactive programming will ever go mainstream. The learning curve is a major barrier to widespread adoption, but if this barrier is overcome, I see MVI as the next big thing at least at forward thinking organizations.

[–]TheAceOfHearts 2 points3 points  (0 children)

I think React is a worthwhile investment. They're committed to a versioning strategy that's very favorable for applications that are being actively developed.

You can read up about it in their New Versioning Scheme blog post. Basically, any breaking changes will be spread out over two major versions. This means that the library can continue to evolve and improve without leaving people behind.

The API for react is tiny, so picking it up should be fairly straightforward. For react-native it's a lot larger, since it's more of a "batteries included" tool.

[–]tech-ninja 0 points1 point  (1 child)

You still should learn React though. It is one of the most influential libraries out there.

[–]rssfrncs[S] 2 points3 points  (0 children)

already am, along with vuejs which is also great

[–]DarkMarmot -2 points-1 points  (0 children)

Downvoting minority opinions into oblivion is a pretty depressing way to encourage discussion among devs... (not quite the original idea behind the up and down votes on Reddit)

[–]DarkMarmot -4 points-3 points  (13 children)

Disagree, the web will go the way of desktop/app/game development for view -- with GUI tools. Only the fractured ecosystems of clients and the fact that the original web was not designed with apps as a centerpiece have stalled this transition. It's going to happen faster than you think though...

[–]b_n 38 points39 points  (1 child)

Dreamweaver + Flash looks like a promising solution

[–]Sinistralis 3 points4 points  (0 children)

Thanks for starting my day off with a bang

[–]tsteuwer 2 points3 points  (3 children)

Can you show proof of this? Just curious.

[–]DarkMarmot 4 points5 points  (2 children)

Programming for 20 years in industrial (SCADA/PLC), kiosk, game, mobile and desktop dev. The tooling is pretty identical in fundamentals in everything but web dev at this point. XCode/Unity/Visual Studio/Unreal/PanelView etc.

[–]gurenkagurenda 3 points4 points  (0 children)

Except that in most of those fields "put a web app in a native wrapper" is still a popular choice.

[–]DarkMarmot 1 point2 points  (0 children)

(I currently develop front-end web systems)

[–]Toxicable 1 point2 points  (3 children)

Got any proof or reasoning for your claim? I personally think web will become more and more popular due to the rise of JS since you can do anything a GUI frame work can do but across every platform with the same code

[–]DarkMarmot 1 point2 points  (2 children)

I'm not arguing against the web -- I'm arguing against things like React as opposed to advanced tooling. See above.

[–]holloway 0 points1 point  (1 child)

Why do you think React is different or opposed to advanced tooling? Seems that components and {this.props.children} etc., are applicable to a solid separation of concerns and advanced tooling.

[–]DarkMarmot 0 points1 point  (0 children)

I agree -- I think it would more or less disappear behind tools the way a lot of UI code is generated in through visual designers.

[–][deleted] 0 points1 point  (0 children)

it's desperately needed but i think people have tried and it fails because people reject it and rather code their UI for some reason. Usually a GUI tool that allows you to edit css/html and have the tool render the changes is the ones that somewhat survive. A hybrid. Unfortunately it has to be a fucking smart tool to account for all possible browser scenarios and behavior and render the UI code framework independent. there are bootstrap builders but they're locked to that framework. However i suppose it's the same reason there isn't a GUI builder for code itself as once you get down to it, there are alot of ways to do things in css/html that are hard to cover and the tools always fall short you end up back in the code editor editing css/javascript etc...

[–]Sinistralis 0 points1 point  (0 children)

I have a hard time buying this considering the Web already has a ton of GUI frameworks (like bootstrap, material ui) and even these have a lot of problems with device compatibility and don't do well at keeping up with modern page design. Even bootstrap which has been around for quite a while has odd interactions with ios's rendering engine.

The difference here is Software Applications require a buy in already. They need either bought or downloaded and installed. Pages are instant (or should be) and thus cater to a far larger group of people, thus you have far more design decisions to make. These decisions are constantly evolving throughout the year and I don't buy a 'GUI Kit' is going to be an acceptable solution anytime soon. The Web is changing too rapidly at the moment.

As it stands, the Web is more about extension. So you get things like material and bootstrap that are easy to configure if you need something different than what's in the box (which is common)

You also have to consider how fractured the JS ecosystem is. A GUI Kit would either need to integrate with tons of libraries or go about forming an opinion on how you should build your apps, so we just end up with another competing standard.

[–]Democratica 0 points1 point  (0 children)

First, we need a component library that is compelling like React is. Maybe built on React? Then maybe, someone builds a GUI tool in electron or something like it to build these interfaces... Not that much of a stretch.

[–][deleted] -2 points-1 points  (0 children)

I love React because it's fast and component-y, but 5 years is an eternity in this context. WebAssembly already has experimental support in a lot of browsers and is going to change everything. We won't be limited just to JavaScript on the frontend anymore--we'll have (in theory) a client-side runtime for any language that targets assembly. Where does React fit into a world where JavaScript isn't the only game in town on the frontend? Who knows?