I see people here complaining about the author asking for email addresses, and I can't help but think: what a coup GDPR has been for large tech companies.
The author has spent hours creating a useful guide that he is giving away for free in exchange for an email address. He likely hopes to tap into this audience later for a paid product.
Reaching this audience via email is cheap and easy. He can email them as many times as he wants, even if he doesn't want to sell them anything.
But because of GDPR, he can't depend on email so much. He has to rely on other tactics to reach his audience again.
And what are those tactics?
Paid advertising, of course.
No one stands to benefit more from GDPR than Google and Facebook. Everyone here cheering for GDPR needs to think how it placed all the advertising power away from mediums you can control (email) and over to ad companies.
As a consumer, you can unsubscribe and block emails easily. As a creator, you can set up a mail server easily.
You can't do that with ads, at least without relying on outside tech
It's not about the subscription, it's about the lead.
Giving things away for "free" is a common marketing strategy to generate leads. A lead is a qualified contact of a potential customer. This things could be of a broad range of cheap assets, e.g. ebooks, apps or even games.
I have seen a marketer buying the copyright of a ten year old textbook for a cheap price, polishing it, giving it a new shiny cover and a new title containing up to date buzzwords, and then giving it away for a "free" subscription via e-mail, and on top asking the customer kindly to come up for the shipping. I wondered why i couldn't find this book on amazon or somewhere else, but then i understood that it was re-released on the purpose of being exclusive for subscription. The cost for printing a small number of copies (500 copies) is quite low ($1-3 per book). This is a decent price for a qualified lead.
This strategy has two benefits. First, you get a qualified lead with contact info and even with a correct address. Second, some countries have laws against e-mail spam, but this laws often have loopholes. In cases that your company has a business relationship with someone, you are allowed to get in contact and advertis your other products via e-mail, on an opt-out basis. Giving "free" assets to a costumer establishes this kind of business relationship. Almost always this "free" assets are of a minor quality, for me not sufficient enough to give away my datas.
...like ConvertKit? That's who powers the form that collects emails here.
Just wanted to point out that this question is decidedly not hypothetical. Many websites use third-party services to administer their mailing lists.
Now, this makes sense from a developer's perspective since we don't all want to be rewriting mailing list tools, but I'd wager many users aren't aware that their email address is being passed on to a third party. These are the sort of tradeoffs that we're now learning to address explicitly, as opposed to sweeping them under the rug in the name of "marketing". As much as it's a pain for me as a developer, I welcome it wholeheartedly as a user.
Well, my personal inbox was filled with even more emails from every company I ever signed up to, telling me about GDPR. Initially at least the effect has been quite the opposite.
Your email is probably already everywhere. There's very little chance that GDPR does ever help to alleviate spam. Email list aren't coming from Facebook, they are from scummy website that, you guess it, won't ever follow GDPR.
Don't give your email if you don't want spam... that include this website.
Thanks for the heads up. I now enabled the GDPR compliance form on ConvertKit. It seems my explanation under the form is clearly not enough to explain the intent and how I will use the data, and I need explicit consent to be able to contact EU users that enter their email. I probably need to discard their emails now.
Why do you believe the data collection is not GDPR compliant?
I think that the site is very clear on how my data will be handled and what my email will be used for (sending me 3 emails).
To quote from your pasted link:
'The new regulation requires that brands collect affirmative consent that is “freely given, specific, informed and unambiguous” to be compliant.'
I submit the data freely to receive the information stated on the page.
In js/front-end world, what would be the closest to those RAD/component based toolkits like Qt, wxWidgets, Delphi/VCL, WinForms? Is Vue a good candidate or maybe Angular is a better choice?
> In js/front-end world, what would be the closest to those RAD/component based toolkits like Qt, wxWidgets, Delphi/VCL, WinForms? Is Vue a good candidate or maybe Angular is a better choice?
Telerik, Sencha and a few other companies sell RAD solutions or components for frameworks like Angular and co. There are also plenty of free JS toolkits
Angular and co, they don't come with components like Delphi or Winforms, although they might have some official libraries(Material design,Bootstrap...) or widget collections that are separated from the frameworks.
But most of them will only deal with UI/data binding and it will be up to you to build components on top of that.
IMHO if your goal is to build desktop like apps and LOB on the web, don't bother with Angular,Vuejs,React and co, this is not the right abstraction. If you are looking for complex data grids widgets, have a look at the link I provided.
This is the exact same reasoning for charts. If you are looking for charts to use in your apps, don't use D3.js, use a library that actually comes with charts.
What about those frameworks are you trying to capture? It's almost impossible to pin down exactly what about those different ecosystems it is that you're looking for.
Is it the inter-component messaging? Integration? IDE support?
Vue and Angular are not directly comprable, Vue only deals with the V in MVC (View), where as Angular offers solutions for everything. vue + vue-router + vuex (or something else) would be a better comparison.
This is simply not true. Vue is not just rendering engine it does take care of lot of things. The fact that it is lightweight and modular (so for example it does not have router bundled but there is official one) does not make it worse. Vue is also its own ecostystem same as Angular or Ember. The ecosystem is in fact probably even bigger than any of them now.
I did not call Vue a rendering engine. I stated that Ember's closest equivalent is Glimmer. I do think that statement is incorrect on it's face now that you've brought it up -- but I think that's because the closest thing would be ember's `View`, and not just Glimmer because the "View" abstraction is what Vue provides, and Ember's had `View`s long before Glimmer (they just worked slightly differently under the covers).
> The fact that it is lightweight and modular (...) does not make it worse
I did not ascribe a value judgement to Vue. I am a huge fan of Vue and use it a lot in my own projects and at previous jobs. I do not believe it's worse, but the simple fact is that Vue by itself is not comprable to Ember at all. They're different leagues of tools, Vue is a knife, Ember is a swiss army knife. Different problem domains that only sometimes overlap.
> Vue is also its own ecosystem same as Angular or Ember
Yes, Vue does have it's own ecosystem, but they are not the same as Angular or Ember.
> The ecosystem is in fact probably even bigger than any of them now
I don't agree with this. Angular 1 became the defacto frontend framework for corporations -- this spawns a LOT of ecosystem from people working on Angular everyday. Next was React, and Vue is just coming up NOW. I find it hard to believe that Vue has already gained the same amount of mind share as either Angular or React in terms of ecosystem.
Ember on the other hand has somehow managed to not land the lucrative corporation mindshare.
Do Vue or emberjs come with a lots of pre-made set of components? I've heard good things about emberjs, but I've got an impression it's a pure js stuff, so doesn't play well with TypeScript, is this true?
Thanks, this looks helpful. If you have a friend who's a native English speaker you might ask them to read it over for you. There's some awkward phrasing and tenses used throughout (I'm guessing you're European). Not complaining about free education, just trying to be constructive.
Nice work! To counterbalance the comments here a little bit, I think an email address for a book is more than a fair exchange. My one suggestion would be to have a HTML version, so that mobile users can read it easier. I do most of my reading on my phone and PDFs are really hard to read, since the text size doesn’t scale. This doesn’t need to be extra effort, you could probably just compile whatever underlying markdown document you probably have that you used to create the PDF and save it as a HTML file, and send link to it (or send the HTML file itself) after email signup alongside the PDF.
This is a lot of work and value you are adding to the world for free, thanks for putting it out there.
An email address is a small thing to ask for when what you are providing is much more than 5-10 hours of work. I guess it's a fair trade for me right now because I'm exploring Vue.js and it looks to be much more mature than 1-2 years ago.
I gave a quick glance through this and it seems pretty good especially for beginners. I noticed at the beginning it goes straight into installing the vue cli with yarn or npm. Might be helpful for beginners to know what npm/yarn (and for that matter node) is and at the very least how to install it.
I understand that this is supposed to go with a complimentary course which might explain these things, but might be good for reference.
That being said this seems like a great resource that I would recommend to any new people that are starting with web front end, great work!
There's beginners and there's beginners though. Why not include a CLI basics tutorial too? An addendum covering just what the CLI is composing for you so you know how to use separate components would be a better use of time.
If you use some of the simple scaffolds it's fair obvious but the default and complex ones you're at the mersey of their github README, which as a newbie can be very thick.
Tutorials should set you up to get the most done in the least amount of effort with the fewest tripwires setup.
I considered beginners to the framework, rather than to frontend development altogether - I think an npm/yarn intro would have helped, it's difficult to know where to stop and avoid going into a rabbit hole to explain all the things you're "supposed" to know when entering the JS frontend dev realm.
I find RequestPolicy[0,1] to be both a powerful and easy way to manage cross-site requests. It too blocked ConvertKit (with options: temporarily allow, whitelist, whitelist only for vuehandbook.com, etc).
Mentioning it because it isn't as well-known as other security/privacy blockers.
While I appreciate your attempt to provide a community service, to be fair to the author, he is giving away intellectual property in order to gain an audience for his future course. Surely giving out an email is a small price to pay for the exchange if you are genuinely interested in Vue.js?
EDIT: I see the author himself chimed in on this thread with a direct download link. Kudos to him/her for doing so.
Thank you for jumping in. I was thinking about how to "react" to this :)
HN is probably not the target audience for my email list, which is more beginner-oriented, and a low percentage of HN users will leave their email there.
It's best to make the material available free of any kind of wall and let people jump in the mailing list if they enjoy it and want more.
I think it's fair to "trade" an email for a good learning resource. I mean, I'm not ok with the "3 pages ebook marketing BS leadmagnet " but it's not the case here.
A way a lot of people deal with this is to have a compulsory email box but do very minimal validation. For beginner focused content, people who know they can put a fake email and don't want to be on your mailing list are not much of a loss. And if the content is good, they might still recommend to others who will join the mailing list.
Most software I've used has easy ways to remove failed addresses. The issue is people using "fake" addresses that belong to someone else. Must be a nightmare to use [email protected] or similar.
The email "wall" is there because I want to keep in touch with my audience and possibly get back with more learning resources.
But if anyone is interested in a direct link and skip that, here it is :)
I honestly haven't dived into GDPR but I don't see a problem with a website owner offering something of value (an ebook) in exchange for something else of value (an email address). Disallowing that voluntary transactions oversteps the bounds of what I view a free state to be.
Would adding a second checkbox ("I'm not a resident of the EU") be a way for a site owner to still provide this to exchange to non-EU residents?
Well, for one, he's not gathering explicit consent anywhere. Just because there's a privacy policy and controller information at the bottom of the page doesn't mean I explicitly agree to have my data used for any purpose.
The question is what you do with the e-mail address. e.g., if the page would say:
1. "we provide this book for free, but collect your e-mail to follow up once in about 1 month time with a relevant offer." ==> this might even work from a "legitimate interest" view, but thats currently not well defined
OR
2. "click here to provide consent for us collecting your email and using it for ..., ..., ..."
The exchange email -> ebook in itself isn't problematic with regards to the GDPR, phrasing it not as an exchange but a free gift is.
edit: You may of course not like my comment, but it is factually correct: GDPR really doesn't forbid combining the newsletter entry with a bait like a free ebook, as long as you don't phrase the newsletter membership as "free" and use double opt-in.
You are entering in a relationship with the service or provider. If the email is used for the enumerated purposes only and you agree to it I can't see the problem.
This seems to indicate an "email to download a whitepaper" scenario is in violation. Now... "downloading" vs "delivered to your inbox" might be a distinction to draw. Whether or not it's actually a violation, info pages like the one above seem to make it appear to be a violation.
The author has spent hours creating a useful guide that he is giving away for free in exchange for an email address. He likely hopes to tap into this audience later for a paid product.
Reaching this audience via email is cheap and easy. He can email them as many times as he wants, even if he doesn't want to sell them anything.
But because of GDPR, he can't depend on email so much. He has to rely on other tactics to reach his audience again.
And what are those tactics?
Paid advertising, of course.
No one stands to benefit more from GDPR than Google and Facebook. Everyone here cheering for GDPR needs to think how it placed all the advertising power away from mediums you can control (email) and over to ad companies.
As a consumer, you can unsubscribe and block emails easily. As a creator, you can set up a mail server easily.
You can't do that with ads, at least without relying on outside tech