Not specific to GraphQL, but plain old HTML doesn't work when other non-technical people are managing the content of the site. They need a GUI, and hence the need for CMS's in general.
> React (really JSX) solves the single problem of making HTML a part of JavaScript.
This is the crux of the matter. The people who find Vue appealing (myself included) come from the world of design and html+css markup and jQuery. We're not looking to get html into our JavaScript -- rather we're looking to get JavaScript into our html!
There is absolutely no reason to switch from React to Vue if it's working for you (and I don't think anyone in the Vue community would argue with that). But you came from using backbone -- the people who love Vue I think primarily come from using jQuery. We feel the same way about Vue as you do about React, and that's okay! (btw I also use react and also think it's great)
As for staying in React for the rest of your career -- give yourself more credit and hope you'll be around long enough that this isn't true :)
> The people who find Vue appealing (myself included) come from the world of design and html+css markup and jQuery.
This is something I've noticed-- spot on. Vue seems popular to people coming from the direction of "augmenting their HTML", whereas React is appealing to me precisely because it's all JavaScript.
Appreciate your comment, it sounds like Vue may be an easier option for you, if you don't want to write JavaScript. However, you should just learn JavaScript, even if you're doing nothing but designing components, will explain why.
I also came from jQuery (Backbone and jQuery was a popular duo, in fact using jQuery in everything was).
The way people wrote apps at one point basically was a stream of jQuery statements, $thing.add('something'), etc.. This created nothing but spaghetti code over time.
Now, we're using React to design extendable components that can be nested, or structured to add more functionality. Check out styled components below to see how much easier it is to combine CSS, HTML into JavaScript. Rebass is built on this as a minimal component library. I know this might be really advanced and you may not adopt any of this, I'm just showing you the latest in what we could be moving toward.
I don't think I would leave React unless JS/HTML/Browsers dramatically changed. The industry is too far into JavaScript code at this point to where I am concerned about job security.
Back to your original point, I don't think Vue would scale well for serious JavaScript heavy apps, so that's why I don't think it's fair to compare it with React, but that's not how it's being discussed, which is some sort of React killer.
It kinda bothers me when people say X won't scale (implying that React is somehow special in this regard).
For one thing, we're not talking about things like database throughput where you can actually have scalability bottlenecks.
If we want to talk about scaling maintainability, React is definitely not much of a poster child either, compared to other solutions I've used over the years. We got a new context API only recently to deal with concerns Angular had already accounted for years ago, and things like the Enzyme adapter state of the world is pretty terrible - and don't even get me started on React Router migrations :)
IMHO, one major thing Vue did right that React didn't which has an impact on scaling maintainability is that Vue owns its most important peripherals (data management via vuex, styling via single file components, animations, etc). In my experience, the React model (also adopted by webpack and babel) is a real pain in the ass to support at scale as a web platform engineer, because many times you're at the mercy of some random dude with no connection to the core project and you end up having to settle with bizarre makeshift configurations, fork things or do other nasty things to get around random design direction changes.
> However, you should just learn JavaScript, even if you're doing nothing but designing components, will explain why.
I think you are reading wrong between the lines. There are no vue users who dont know javascript or are not using with it. The concern is really how are you mixing the two. vue is more of js inside html, while react is html inside js.
And its just a matter of opinion. I work on both vue and react apps and personally dislike writing html inside js. But if the project started earlier using react, I am not going to suggest a rewrite just because of this single preference.
lol, I've been a javascript developer (among other things) for over 15 years :)
The point is that some people/teams/environments prefer to not treat everything as a javascript app. Especially in the agency world -- thinking about one's website from a markup/design-first perspective is a totally viable thing. And if you have designers on your team (or for solo practitioners) you sometimes don't want to javascript all the things. It's great that you found an approach that works for you, but it doesn't mean that it's the only best way for everyone and every situation.
Not all aspects of Shopify can be customized -- especially with the checkout workflow (eg you can only set a logo for the checkout page, but not style it). Also the non-ecommerce pages are woefully lacking in content management functionality (anything more complex than a blog is impossible without using a third-party app to store custom content in meta fields).
And writing apps yourself is not always ideal because they need to run on your own server (thus mitigating the benefit of using a hosted platform to avoid infrastructure maintenance), and any frontend modifications can only be done via JavaScript (you can't modify the outputted HTML itself, so it's a lot more difficult to make robust, performant and accessible customizations to functionality).
> they took advantage of the reporter’s good faith and benevolent motivations.
Someone with truly benevolent motivations does good things because they believe it's the right thing to do -- not because of a monetary reward. I'm not saying they shouldn't pay him more, but I think it's going a bit far to say they're "taking advantage of him".
If I find a wallet on the ground and there's $200 cash in it, I'll return it to the owner and leave all the money there. I don't expect a reward and certainly don't feel like I'm being taken advantage of if they don't give me some of that $$.
Yeah, but you might feel differently if instead of $200 it had $10m cash. And instead of accidentally coming across it on the ground, you spend months of your own time just walking the streets looking for such a wallet to return. And also the owner is one of the richest men in the world.
A few years back I made a hobby project like this -- it scraped the website of the local free weekly paper (since they have pretty much every concert listing, large and small) and then did a youtube search on band names so you'd see an embedded video or two for each show.
I think most larger cities (and smaller cities if they have a large university) have such a newspaper (e.g. Village Voice in NYC, Willamette Week in PDX, The Mercury in Seattle, etc)
Maybe it's better in the states, but where I live the papers don't come close to being a complete listing. They will have the major stuff, and some of the smaller shows too - but a large part is still missing. And it's not a small city - 2 mln people, capital, and quite an active music and culture scene.
Note to applicants: see the very last item in bullet-list about their definition of "remote". I was told that I am not eligible because I'm 4 hours away from Louisville instead of 3 hours away.
I would have assumed in the context of HN (and StackOverflow, where I first saw the listing) that "remote" means anywhere with an internet connection, not just "working from home but in our city".
I did receive a relatively prompt reply though, so that was appreciated (and it was fun answering their questions).
Yeah that seems odd. What's an extra hour if it's your own car with your own gas on your time? On the flipside, would have it been possible to work out an arrangement for you to move an hour or two closer? The whole thing seems like a wasted opportunity over an hour drive.
"Remote" means to most people that the work can be done from anywhere in the world. Consider rewording it to something like "work from home possible" or similar.
> Floods pose a serious threat to those living in the city, with 61 percent of residents having already experienced water damage to their properties. While rainfall poses a threat from above, rising sea levels threaten the city’s inner islands, which could easily be damaged by flooding if canals overflow.
And further on down the article specifically addresses this point:
> After 2050, cloudbursts will no longer be Copenhagen’s main concern – instead, the city’s greatest threat will come from flooding from the sea. Copenhagen is implementing dramatic landscape transformations to prepare for rising sea levels (the global total to be predicted as high as 2.7m by 2100),
I mentor and teach a lot of designers and beginning front-end developers. Services like this and FormSpree are a godsend for allowing them to create functioning contact forms on websites without having to go down the server-side rabbit hole.
Also, even though I'm fully capable of building my own form handling back-end, if I'm just building a static site it's nice not to have to deal with all that just for a simple contact form.
Perhaps one of these would serve your needs:
https://strapi.io
https://getcockpit.com