Thought about it, and then tried it. I followed my dream and started a creative project that had been dogging me for a long time. EVERYBODY wanted me to do it. Family, friends, people on the street with whom I discussed it. I expected it to be a big moneymaker. And it didn't work out. Not only that, but it became very clear that it was a really poor fit for me on a fundamental level.

I'm glad for the experience, though.

Going back to programming, here's what I figured out:

- I was working on stuff I didn't enjoy, with people I didn't particularly care about.

- I was taking on new work projects without any particular selection criteria.

- I wasn't thinking about the kinds of work that got me excited about programming and chasing it down.

So I recently nailed the first two back into place. I'm working closer to my values system rather than paychecks. In exchange, I'm just saving more money so I have more freedom.

Anyway, burnout is real. I thought I was done for sure and that my interest in programming and computers was a thing of the past. But that was just the burnout talking.

It helped to keep a journal during this time. Not a chronicle, but a thought-dump process in which I asked if my life was actually improving daily. That made it pretty quick to pinpoint my frustrations, as you can only write about the same pains a few times before you start to really zoom in on the causes and potential solutions.

I have been a professional dev for 12 years but have often considered other paths. Just a few: Placer gold miner (yep, like the TV shows), Brazilian Jiu Jitsu instructor, metal sculptor, mechanical engineer

I got kind of burned out after I got laid off at the tail end of the first dotcom implosionI'd stayed in a really toxic environment for a couple of years too long because things were rough for a junior/early-mid-level developer back then, at least in my market. So I spent several months depressed and unemployed before deciding to go back to school which ultimately led me to preparations to go to med school.

Ironically, I took a semester off and took a contract gig for a few months to pay off some bills and save up some cash, and that turned into a full time job writing software in the public health sector. I never did return to finish the undergrad, and have doubts I ever will, as my career in software has been about as good as medicine would have been when you balance the ten extra years of earnings against a slightly higher salary. The only reason I'd do it now would be to pursue a masters in something interesting.

I think if I had it to do over again I'd have probably just stayed in the market a little longer and skipped out on the student loans. I loved biology and medicine but i'd love to not be paying off the student loans too.

I did not stop programming but I got a dramatically different job of what I had before. You didn't say why you're curious for that question, that might be like me simply for the need to change.

Even with a gratifying job full of technical challenges, I feared I was becoming a 9to5 zombie. So, I got a new job a few weeks ago. I joined a non profit offering free WiFi in the city as the one man army tech guy. Instead of just software/web/mobile development, I also have kind of managerial type of responsibility and more public relation to do. It's something like a safe steady job with nearly startup mindset.

There's still a bit of programming involved, but it's so different from what I know that it's a real professional challenge. And for that I had to accept a big salary downgrade.

It really depends on what's your motivation. Is it salary, challenges that go in pair with your personal growth or simply working in a different context / mindset?

That may be the tasks you do that aren't fulfilling? For some people, manual work is really gratifying. Last week I was setting new cables in a patch panel; there's nothing challenging about it but it's simple and you can be proud of a cleanly done job.

There are so many people performing repetitive tasks who could benefit greatly from relatively small optimizations. I would be able to directly witness the impact of my work and make a difference on a personal level. It's hard to do this in software because the landscape changes so quickly.

It would also be super fun to practice apprentice-style learning in multiple fields and document/share everything.

I went into college for computer engineering but immediately double-majored in journalism (my first love in school) and didn't even bother looking for an engineering job after graduation (though I did fail a Microsoft interview).

Today I do both but I'm extremely thankful I stuck with programming. Not just as a useful job skill but as a different, powerful way to see the world.

Mechanical Engineering -- I work through a different mechanics textbook once a year, or so, for fun. I think I enjoy the theory of how the physical world works more than the practice, which keeps me where I am. :)

A few years ago, I briefly considered going back to school, getting a degree in Exercise & Sports Science, and getting into athletic training. But in the end, I could never quite convince myself to do it, and the moment passed. I also flirted with the idea of becoming a private detective a couple of times in my life. I actually still find that idea somewhat interesting, but I doubt I'd ever make the money doing that, that I make in software. And here in NC the training requirements to become licensed are somewhat onerous, so I doubt I'll ever pursue it.

If I could make a much money as I do now, I still don't think I'd choose something else. If I did it would probably be, in order:

- Robotics (more on the hardware side)

- Woodworking

- Custom motorcycle/classic car building and restoration

The common theme for me is the creative problem solving, building things in general, and attention to detail/craftsmanship specifically that maintain my attention. As it is those are all hobbies of mine, so I still get to dabble while making a good living doing another thing I really love.

First time I quit programming, burned out, went working on a friend's farm. After some times, I felt much more valuable helping them with computers/website/payment processing problems. Didn't took long, I was back in programming.

Second time, I took some time to execute on a non profit to help our local community. Being good with data really help organizing event people really liked so I tried to spin that into a startup and failed. Like other commenters said, I was doing stuff I didn't really like.

I'm back to programming but I'm really glad I tried different things. Not everything was a failure, I eat fresh organic food from my friend's farm and I have an impact on my local community.

For 10 years programming has been my thing, but for a while now I have been getting the feeling that programming won't be big in 30 years. If all my eggs are in the programming basket and I can't keep a programming job in the future, I would be out of luck. (presumably because it's a blue collar profession by that point).

With that fear in mind, becoming a M.D. actually seems like it would be a good decision. Even this late in the process, doctors have been well paid and relatively rare for thousands of years; a tried and true profession. Plus it will sate my curiosity about the function of the human body.

Yes and did to some degree when I left a captive software dev position and started my own business. Still involves lots of programming but mixed with a ton of other things.

I sometimes day dream though about doing something outside of software such as landscaping or remodeling houses. Something I can do away from the screen & keyboard. Something that still involves creating and being able to see the end results of your creation.

I did this just recently. Before I went to a middle east country for an SEO job, I am a PHP dev for 7 yrs and my last work made me realize that I'm not growing or something and this new environment would make me do this change. Unfortunately, after working for only a few months, I was sent home due to health reasons and dev jobs are hunting me again which I think because of my qualifications in the past.

In general, when those thoughts crossed my mind it was when I was working a job I should have left already. There are good companies that value developers and/or give them a reasonably good balanced work environment. Generally the two go hand in hand. For places that don't, frustrations and poor practices tend to push us into less fulfilling lifestyles.

But if pressed... Corporate pilot comes to mind. I've spend I don't know how much money on training and aircraft rental. Most piloting jobs for corporate clients have you working only 2 weeks out of the month. That is, you only fly about ~250hr a year. The rest of the time can be spent hacking or doing whatever else you'd like to do.

I'm slowly working my way toward park ranger, though I've considered paramedic. Wood working also sounds interesting, and I'm great with my hands. Certainly, programming is my passion; having to do it under someone else's terms can spoil the deal though.

I took a year off in my 20's for spiritual pursuits and volunteer work. Best thing I ever did, it wasn't well planned and on a shoestring. If I could do over I would have done the finances differently. I cam back to software, but with a much different outlook and world view.

I've been working for almost 2 decades and have recently rearranged life to study part-time. A combination of luck and good timing let it happen. It's done wonderful things for me in all aspects of my life, professionally and personally, and is opening new doors.

I've considered it a couple of times. Being a chef or someone researching climate change are the two things that I've considered. I have no background in either (I can cook up a decent meal but nothing impressive) and the thought of having to start from scratch bothers me a lot.

I used to charge $50 USD per hour, but I kept upping my rates. Soon I charged $100 per hour, and then $125 hour. The highest I ever got for programming/consulting was $150 USD per hour, but I don't charge that anymore. I've moved on to day rates.

Now I bill around $800 per day, but I only work about 6 super-focused hours, and I use the Pomodoro method every day. My clients are happy because I get a lot of work done, and I'm happy because I have to work less.

This is just doing general PHP dev work (Codeigniter and Laravel frameworks), and if I specialized, and if I focused on the ecommerce or finance industry I could probably make more. Most my clients are in the Rocky Mountain West, and so far I have more work than I can finish.

So if you want to increase your earning potential you should:

1. Specialize and master a niche. 2. Network like your business depends on it. 3. Give free seminars and teach everywhere you go. 4. Label yourself as a consultant. 5. Don't be just a programmer. Work with businesses and fix their problems. 6. Know your worth, and don't be afraid to charge what you're worth. 7. Anchor your costs against how much value you'll make your clients. 8. Keep raising your rates until you can't get any work. 9. Work half as much as you used to. 10. And finally, spend time on things that matter like family, learning, and having fun.

Or you can keep competing against bottom-barrel programmers on upwork, and spend the rest of your life working for peanuts. Totally up to you.

I am willing to work for 10$ an hour for full stack development (React/redux and go or firebase, SQL, sometimes node), or Cordova app development, or programming embedded devices (C or proprietary languages).

But no clients so far except for some friends who have promised to pay in the future if their startup gets successful or gets funded :)

I have tried the usual freelance sites but no one really bids on me. The reason is that I am from India and don't have much to show in terms of projects/experience - my previous company had a very strict non disclosure policy, and haven't worked on anything open source yet, don't have a blog, etc.

I am not very serious though and more focussed on a project/"startup" of my own but still looking for pocket money of 20-40$ a day to sustain myself without having to do a job. I am trying at fiverr now. Somehow I just haven't cracked the money nut yet.

Back when I was freelancing, I charged around $150-200/hr for fullstack development.

I know this is on the higher end, but it is definitely possible to find clients that can afford this higher price point. I routinely took work from clients that had hired a cheaper team and weren't satisfied with the final product, needed someone to fix numerous bugs, or to optimize the performance of their technology.

Also, if you are interested in this higher price point, you need to be ready to truly partner with your client and help them solve problems, vs just writing code. This means embedding yourself in their team as much as possible (which can be done remotely; I always worked remote) and understanding the actual problems they had, rather than just building what they asked for.

On top of that, you'll need to own your solution all the way through. If your client doesn't see you as a lot of overhead, and you can act autonomously, then they'll be even more satisfied with your work and rates.

It depends. I work with clients and their budgets. Leaving money on the table doesn't bother me because I want long term relationships. For example, I'm wrapping up a 2 year project this month. Built the MVP all the way to two profitable product lines for the client. Super happy about it. I like to see my clients succeed.

My focus is building solutions to business problems. I don't look at it as software but solutions. When you approach it that way people are more receptive to what you have to say.

I don't reveal amount earned but can't complain. I bill monthly, weekly or per project and it works. Forget hourly. Either way, Im raising my rates for 2017. Best of luck.

I have a Cordova app before I go to clients, currently landing on too much work because of it ( it's a great conversation starter and builds trust). Will up hourly rates soon, but have a lot of work the next months ( mostly creating webshops for clients). I also work full-time.

Currently notified all me clients that i will probably have some delay, but nothing was planned for this month. I do put longer hours currently then i want for now, just to make sure everything will land on time... ( 16 hours per day at the moment, hope soon everything will be back to normal)

Also use a lot of jenkins and automation tools, i hate manual labor. My collegues use 4 tools i wrote for myselve every day. It just takes off a hell of time of lookup up usernames, passwords, phone numbers, logging hours, ... I guess you only need to use it in a "ux friendly" enough way, but just don't sink too much time creating it ;)

I charge $120/hour for development work. I specialize in low-level, performance critical stuff, lock-free algorithms, C/C++, assembly, SIMD code. But most of the work I get is typical full-stack web application development, with a little mobile stuff sometimes.

I charge half rate to startups in top accelerators, like YC, that haven't closed an A round yet. The idea is to build relationships with future customers that have lots of growth potential - but who can't afford $120/hour.

I'm a 21 year-old who has recently gotten into contracting to supplement my primary income (a Software Engineering Apprentice for a Defence contractor).

I earn 12 an hour for my contract work, which I'm quite happy with at the moment because 10 hours a week means I get an extra 500 per month (which is considerable at my age, it pays my rent and bills and some).

I know it doesn't seem much, but I think I'm actually quite lucky to be able to get a gig at my age with my experience.

I'm a full-stack developer and I was working full-time till last month and freelanced occasionally. After leaving my job I decided to take up freelancing and currently, I'm making $35 an hour working on CakePHP/Laravel/Angular project which is low considering my experience (11 years). I usually charge upwards of $50 but this time I made an exception because the company is looking to raise Series A (which means more work at a better rate in future).

I worked on top of my full time job doing web dev for Ad agencies, usually php, asp.net or CMS work. Billed at $80/hr, probably netting 40-60k per year on the side. I had always hoped it would lead me to a career as an independent, but that rate is not enough to make a living with a family. I eventually made it to being an independent, but I had to switch to doing enterprise consulting in a niche market at a much higher rate.

My actual rate is 100 /hr for developing work. I charge way less for skype calls, tests, discussions.

I am deeply embedded inside the small company I consult for, it is extremely nice because people trust me, are not in my way and are just looking for results.

Really happy, however since I don't only bring coding experience but also business acume I would definitely increase my rate to 150 /hr .

People come to me with problems, I make sure they actually have that problem, I listen to the solution they propose, I actually make my own proposal about what should be done considering both business and technologies, we talk a bit, more problem or constraints arise, we tweak a bit whichever proposal is better and then I go ahead and I implement it.

Time spend talking between 10 and 30 minutes, client have its solution about ready the day after. We are both happy.

I haven't freelanced in ~5 years, but while I was based overseas in a _very_ inexpensive living situation, I scraped by on $35/hour doing WP development (urk...) and infrastructure work (now "devops", though we hadn't come up with that moniker yet). I'm currently fulltime employed; if I were freelancing I'd charge >5x that amount.

What's the best way to start freelancing? A few years ago I used a few freelance sites such as upwork but the pay was fairly low and the work was just around building wordpress sites. Any recommendations? Specifically for backend or fullstack projects?

I'm working a full time gig now and haven't taken on any additional work in ages, but depending on contract length I would start at $170 and up.

As I've seen posted here and elsewhere if you're experienced and charge less than yearly salary/2080 * 3 you are giving money back.

(My wife worked as a buyer at one of the national labs and had to purchase contractors, should used to have to tell them what to ask for because more often than not it would be too low for her to quote them out.)

I do web development for $25/hour, HTML/CSS, JavaScript, and some basic things on server, Apache, MySQL, Python. I'm in China, so it's good for me. If you have any project needs help, feel free to contact me, tarvos21 at gmail.com

Don't really freelance anymore, but when I did, $75/hour (mostly in Rails and ColdFusion) was typical. I do some mentoring (codementor.io) at $80-120/hour (they take 20%). (My rates would be higher if it was my fulltime gig)

I freelance part-time in addition to my 9-5. Mostly doing WordPress sites, with the occasional ASP.NET app for projects that need something totally custom. Some other web/mobile work as well. I've been averaging $40k/year the past 3 years in a row.

I charge $30AUD an hour for freelance WordPress development. Billing monthly an average of 8 hours ($240) for maintenance and support for an agency which isn't much but nice extra income on the side and the occasional from scratch projects (charges depending on requirement). Main job is a front end developer (angularjs).

As someone who has tried HTC Vive, Oculus Rift, Playstation VR (I own PSVR) and even Samsung's foray into VR via its flagship Galaxy phones (S7 Edge) I would have to say that at present, it's still overhyped. The technology is so new that most companies are experimenting and finding their feet.

As cool as VR is, the cool factor wears off very quickly when you realise that screen technology hasn't quite reached the point where VR can compete with a 4K monitor on a gaming PC or even the level of immersion of a gaming console on a TV.

"Deep learning" and virtually any other kind of "data science". I teach classes in analytics and I think ninety percent of what people really need is better understanding and visualization of the simplest statistics: sums, averages, counts, time series. Fancy statistical algorithms have some applications for example in fraud detection, but for most business people I think a great dashboard that lets them visualize patterns with their own two eyes is much more robust and useful.

Perl is a hacker's language (not unlike e.g. Common Lisp). It brings maximum power to the fingertips of an individual. When you are alone, developing with Perl is a blissful joy of pure godlike power over your domain. Perl6 amplifies this feeling to eleven and beyond: there's almost nothing you couldn't do with a few lines of code.

The popularity of Perl coincides with the golden age of personal computing (and hackers culture). PCs got powerful enough that individuals could do the same things that were only available to big corporations and sometimes universities. Perl helped to harness this power, becoming the proverbial "Internet duct tape" to connect things (in the world of UNIX with emphasis on text protocols, the most powerful language for text processing won).

When lone hackers were no longer enough to satisfy the demand, the world had moved on to create _software industry_, and Perl's advantages (all power to the individual) started to be harmful. Different individuals have different preferences, and when you have to work in the team, reconciling your differences with your colleagues creates way too much friction. To facilitate teamwork, more uniform languages were deemed necessary, where understanding other people's code became a priority. Even open source software moves faster when anybody can read and participate in your code without fighting over style. This attitude was firstly exemplified with Java; now, we have Golang, which is a king of all languages optimized for team development. To facilitate this, the expression power available for individual developers had to be cut short.

As a consultant supporting my own code, I still use Perl, and if you are working alone, it's your fine bet. But as 99.9% of people work in teams, Perl6 is not the best choice for them.

I love perl 5 and have been using perl since 1997. I haven't touched perl 6 yet simply because the whole mess is still too confusing. It's not obvious what I should download and the frequent release announcements just confuse the issue further. If I want perl6 why am I downloading rakudo star? What the heck is a moar vm and why do I care? Why is the download page telling me it supports "Christmas Perl 6 (6.c language version)?" What is 6.c? Are there multiple versions of perl 6 that I have to worry about? Why does every release announcement say something like this:

"Please note: This announcement is not for the Rakudo Stardistribution[^2] --- its announcing a new release of the compileronly. For the latest Rakudo Star release, see<http://rakudo.org/downloads/star/>."

Perl 5 is much more straightforward. Their download link sends me to a page where I click my platform and then there's a link to "download latest stable version." Why can't I just download the latest stable version of perl6?

I know I can spend a couple of hours learning more about it but perl 5 more than meets my needs and I'm comfortable with it.

The thing to remember with these questions is that popularity is largely a matter of social dynamicsnot the language's intrinsic qualities. I mean, sure, qualities matter to a point, but that point is pretty low: it just has to work well enough. Past that, it's mostly a matter of spreading through social networks, perhaps helped on by marketing.

So when you look at a language and ask why it isn't popular, the answer is probably not that it's bad or that it has terrible features or that it's missing things every other language has.

Instead, the relevant answer is some combination of timing, marketing and luckand Perl 6 definitely flubbed the first two!

It's been, what, two decades since Perl 5 first came out? In that time, trends have changed, people's preferences have shifted (and ossified) and even the role of a scripting language is different. And Perl 6 is not making any of that up on marketing, niftly logo notwithstanding: the Perl brand has been pretty well tarnished over the past years which makes these the absolutely wrong coattails to try sliding in what is supposed to be a brand new language.

None of this, by the way, shows that Perl 6 is a bad language. That's a different discussion entirelya discussion in which popularity plays a small role at best.

But it is to say that I'm not all that surprised Perl 6 hasn't gotten anywhere.

Perl was the poster child of scripting languages. When I started hacking on Perl 4 in the mid-1990s (before there was a Perl 5), it was a miracle language. I was throwing out multi-thousand line C programs wholesale and replacing them with 50 line Perl scripts that worked far better (daemons and Sybase reports, mostly).

Around 2000-2001, I worked on Perl 5 in a close-knit team at a dotcom startup. Even with daily interaction, it was really hard to keep coding standards straight and readability under control. The problem with Perl is that it tends to be a different language for every programmer. Its flexibility leads to arcane code that can only be easily understood by the person who wrote it.

Years later, in different roles, I've worked extensively with both Ruby and Python (I prefer Ruby). I will never, ever, ever go back to Perl for anything more than one line long. I still use Perl for 'perl -e' one-liners in the shell, mostly complex greps. That's it. If I write anything small enough that structure doesn't matter, I use /bin/sh. If I write something large enough that structure matters, I use Ruby.

Why? Because I like to be able to read my code.

Ruby is wonderfully expressive. It can do everything Perl can, and it does it in a much more readable, much more human way.

The two main reasons: (a) It's still not finished, but mostly (b) all I ever see is people in love with how clever they can be with the language.

I don't need to see hyper-clever ways of using built-in lazy memoised lists to generate a Fibonacci sequence in a dozen keystrokes. If I get tempted over to Perl6 (or any other language) it'll be be by examples of how easy it makes the boring, mundane tasks that I actually need a langauge for - things like reading from/writing to files; handling dates/times nicely; etc. etc.

What I like about Perl5 is its "Make the easy things easy and the hard things possible" mantra. The only mantra I hear from Perl6 is "Look how cleverly you can solve this contrived example". That's not something I care about in the slightest when I think about what language to write my next program in.

I just started playing with Perl6 a couple weeks ago, and I am completely loving it now. It's the strangest process to get used to. I haven't had this much fun programming in a long time. Some frustration every one in a while until I can wrap my head around some new concept, but that's to me what this language is all about. SO much conceptual stuff in it. Very, very rich.

I've been converting some old stuff to it to learn it, and it crazy how much more compact things can become. Working with grammars has been amazing. And I'm just now getting hit over the head with how flexible class roles with parameters can be to consolidate methods that do similar, but slightly different things.

I haven't even started into the concurrency bits yet... something about "promises" and "supplies". But I'm actually looking forward to it at this point. And that's really a surprising thing to me ;)

Anyway, my 2 cents on it at least. I'm not sure it matters if Perl is ever a poster child for anything. I think it kinda just doesn't matter.

Because we aim for organic growth: not too fast and not too slow. Based on stats, our userbase doubled since last year; and that's with an yet-to-be-optimized compiler that's an order of magnitude slower than competitors and by some people's standard not yet production ready.

It'll also take a bit for people who loudly push 25-year-old languages like Python and Ruby like holy grail to... die off (no, I don't want them to convert). Perl 6 is a next generation language over them and it'll take next generation of programmers to make use of the new programming paradigms.

What you're probably asking is why hasn't Perl 6 went viral like Swift, Rust, or Go? Well, we don't have a multi-million (or -billion) company backing us, so fanboys and people who are after the latest shiny things aren't flocking to us like to manure. But look around this site: those langs get as much nonsensical comments from the Python-Ruby zealots who are too scared of new languages :)

Perl 6's first production release was less than a year ago. It's a bit unrealistic to expect it to be a "poster child" of anything so fast. If you're old enough to remember, no one gave a shit about Python until at least second version.

Don't worry about popularity. Learn many languages and use what you like using.

Because it waited too long and now everyone who needs scripts just uses Python/Ruby/Lua instead. I highly doubt Perl 6 will take off in any meaningful sense. Not to disparage the language, it's just the social dynamics of the software world and tastes have shifted. Perl is, rightfully or wrongfully, considered a legacy language of the 90s and it would take a serious re-branding and evangelization effort to change that perception. That being said, I know some folks who pull in pretty good bank maintaining Perl apps but they are definitely not writing Perl 6 on the day to day

The short answer boils down to, "It might be dangerous, you go first." Moving to a brand new language (which is what Perl 6 is, despite its long incubation and its vestigal name) has real costs - the libraries you have come to depend on aren't there, new libraries to replace them aren't all written yet, some might never be, the ones that exist aren't as feature-complete and battle-tested. For a new language to get adoption, someone needs to go in there and start doing those things, and deliver a value proposition. If a language wants to get followers, at least in the beginning it's better to have one "does it better than anyone else" area than to be a jack of all trades, too.

3) Baggage. Some of the conventional wisdom about Perl 5 is pretty iffy, but it's well established conventional wisdom, dammit! In fact, you'll almost certainly see it recapitulated in this thread. Most arguments to the contrary seem to be slow to make a real dent in what Everybody Knows about Perl. The fact that Perl 6 is a different language will probably be equally slow. People will repeat the comforting mantra that Ruby is the new Perl. Order will be reinforced.

4) Blub-ish paradoxes. Perl 6 is doing some weird and different stuff. Is it hyper-useful weird and different stuff? Will I know until I learn to use it?

I learnt Perl 5 a long time ago (in school) and used it for CGI based web-sites and sys-admin stuff. I always found it easier to rewrite Perl code from scratch than maintain it. Of course at the time, I was a newbie programmer, so I don't blame the language.

I don't know why I should learn Perl 6 when there are so many new languages to learn. (Just keeping up with web-tech and Javascript itself takes an enormous chunk of time away)

Can a perl 6 geek give a use case of why perl 6 would be better choice than Ruby/Python/ES6/Java/Scala/C#/F#/Rust/Swift for an application in some domain ?

A comparison on where Perl 6 is superior on different parameters such as productivity, libraries, module system, documentation tools, packaging & assembly, macro and micro performance, runtime-scaling, concurrency models, hot-deployment, software-update, etc would be great.

I think the biggest problem Perl6 faces now is the perception that it is unfinished. This is mostly a problem of their own making. The language was in development for 15 years! In that time people got it drilled into their head that it wasn't done yet and likely would never be.

While this perception did hurt Perl5 it seems to have also hurt itself since reading this thread and seeing the number of people saying that it is "still in progress" or "still changing". This brings me to my second point, and the one that frustrates me more.

In fact Perl6 was released as stable 1.0 on Christmas of 2015. You could be excused for not noticing it. There were a few articles in a few technical journals in the months leading up tot he release but mostly the release day went by completely unnoticed and barely remarked upon.

Perl6 is a spectacular achievement! A language designed over the course of 15 years with the extreme flexibility and malleability to last 100 years more. This could have been a news story, a big release party, lots of hype, press releases. A language in the works for 15 years, it must be great right!?

Instead, to keep with an in-joke about "released by Christmas" it was released on Christmas day by developers who had family plans to a community that was busy with their own. I doubt many people know it happened. Indeed this thread seems proof of that.

Its not everyday that a 15 year project is completed. What an opportunity for exultation, and good press, wasted.

Perl 6 was too little, too late. It was hyped for a long time and delayed for a long time. During that time, everybody who was impatient and not forced to use Perl ended up moving to the new hotness languages like Python and Ruby.

Ruby is probably the main reason Perl lost so much market share, since it took a lot of the underlying philosophies from Perl and turned it into a beautiful, easy-to-read language.

Python, by contrast, says "There should be one-- and preferably only one --obvious way to do it."

The practical outcome of the Perl philosophy is that Perl code can be extremely varied to get the same thing done and therefore much harder for different programmers to understand and maintain. Python programmers are more likely to quickly understand the intent of a chunk of code regardless who the author is.

Perl at its worst can also be pretty arcane and I've heard it described as "executable line noise". That doesn't make for maintainability.

The python community have just about managed to achieve a backwards-incompatible change, which was fairly minor and developed in a reasonable timeframe to address certain specific issues.

The Perl community were made extravagant promises 15 years ago. People started holding their breath for 6. By now, everyone has given up and the delay has asphyxiated the community. Not to mention that the Perl niche is much more crowded and still has a working, complete Perl5 in it.

This is my own personal opinion, but I despise Perl. The language requires a ton of memorization of small, tedious rules that are arbitrary, and there are many disparate ways of writing the same thing. I remember giving up on Perl when I discovered that || and or were both "or" operators but had different precedences.

Again, this is my own personal opinion. I know many people have made some great software based on Perl, but it's the only language I won't touch with a 10 foot pole, and I've spent a couple of years programming in PHP and a year in COBOL.

About a decade ago many educators where looking for a language to teach programming to utter noobs because governments where scared by the year 2000 bug and asked them to produce more programmers (the latter part is a lie but it sounds nice :) many of them picked Python. Educators play a big role these days when it comes to a first language. Most folk who commented here likely went to school when teachers didn't have computers and didn't even think about teaching programming -- that was considered a hobby. So far I know only two educators who want to teach programming with Perl 6.

It takes years for a language to become used by a reasonably large group to make a difference. Given you come from Python you probably know that the first release happened in 1991. Do you know anyone who used that language before 2000? So Perl 6 didn't take off yet because less then a year since the initial release has happened.

Around the new year, I looked at Perl 6 as a candidate for focus in 2016. This was around the time Perl 6 was officially released. I encountered two impediments.

1. At the time, there was not a great 'hello world' installation story for Rakudo Star.

2. There was not a good Perl 6 book published in the last ten years (that does not appear to have changed per a quick Google).

The most readable information I found was the Advent Calendars, but it's fragmented, poorly indexed, and doesn't form a coherent whole. At the time, there wasn't a good StackOverflow story (and the most recent question right now is from October 16, and the average is less than one question per day).

That said, Perl 6 is obviously a long term project and looks like an innovative language that could build mindshare with a bit of luck and the right resources (Ruby and Python didn't become popular overnight). All I'm saying is that it was not a good fit for me at the time.

The reason why developers don't migrate from other languages is plainly because Perl 6 doesn't offer enough unique things that people actually care about to migrate.

The reason why existing Perl 5 developers don't migrate is because they don't need and/or want to. The benefit would mostly be derived from writing new code, but most Perl 5 code in the wild are legacy systems and complex admin shell scripts. Those are exactly the kind of thing that you don't want to rewrite in the latest-and-greatest; the potential to introduce subtle bugs by upgrading is more important than the benefit of being able to use new constructs in those parts that you need to improve. And the vast majority of new code is also admin shell scripts written by experienced greybeards, who really don't like their cheese moved, and so will stick to what they're used to for as long as they can.

The story of Perl vs PHP vs Ruby vs Python is interesting. Apparently both PHP and Ruby were created because its authors found Perl too complicated 20+ years ago(!?). There is definitely a problem with that language (and I find Ruby already complex) that looks extremely cryptic for a non Perl developer. Perl is still used in place of bash scripts and in legacy apps, I just don't see people writing new software with Perl at first place. And System administrators have moved to Python which is now bundled with most distributions. Python just killed Perl.

i think the story it similar to Visual Basic 6 and VB .NET: the change between perl 5 and perl 6 is really big, perl 6 is a new language - not just a change of version, people who are comfortable with perl 5 have little incentive to learn it all again (or they have switched to python)

Maturity: Perl 6 was released a little under a year ago. That's not long, and the leading implementation has not yet caught up with the standard (though work is ongoing). The ecosystem isn't quite there yet either.

Examples: People can be really bad at imagining value in the right things - they need to see it. There hasn't been a very compelling killer app yet.

Perception: People conflate Perl 6 with Perl 5. (Reasonably!) Most people remember TIMTOWTDI and remember that it was a bad thing, or at least that they prefer the Zen of Python. Most of all, they remember trying to read bad code. I don't think that Perl encourages bad code, but it sat in spaces that had lots of bad code already. (Lots of code made by people who are not programmers.) There are also codebases in Perl that are very well made, and easy to read. But we are better at remembering bad things.

Again, IMO, Perl 5's biggest problem was the surprising language. I could write something that was legal code, but had different semantic value than I thought, and the language was littered with cases like that. It was common to think that Perl was to complex for any one programmer to know.

Perl 6 isn't like this - the entire language is composed of simple components (at least, simple for their problem domains). It's also littered with good ideas that don't exist in other languages, like their regexen and grammar support. Everything else in the language is still top notch, like unicode handling and concurrency.

Basically, it is the things around the language, not the language itself. I think it is telling that people saying they don't want to use the language are saying "Perl sucks" rather than "I don't like feature X" or "This construct is confusing".

(I remember Eevee saying that "Perl 6 is truly the realization of Perl 5s mission: to be startlingly consistent, and also just plain startling." I think that when people look at Perl 6, they'll be startled. But when they are no longer surprised, they'll just find powerful consistency.)

I think that logo is really childish and weird looking. It puts me off. And Larry Wall talking about perl gets old really fast.

In my opinion perl will slowly die because it has no social capital. A good sign of this is when you are around other programmers working on a real problem if you say "Hey let's solve this problem in perl!" it will almost always be the case that everyone can do it that way and knows exactly what perl to script (if they are of a certain age) but almost no one would even bother. Who cares about the why. It's just the fact. You get no extra points for knowing perl and for the most part if you are the guy on the team that is assigned to work on some old perl script it's probably a bad sign for you career-wise. Other languages, on the other hand, do have social capital.

Ultimately for me it's a lot like asking why everyone still uses the QWERTY keyboard when there are other keyboard layouts out there that are so much better. Perl might be better at some things, but like alternatives to the QWERTY keyboard, it's just weird to use it and the payoff isn't big enough to justify the change.

It took 15 years for a "production ready" Perl 6 interpreter to be finished, at which point Python, Ruby, Lua, and even Node.js had more than enough traction to not leave much room for Perl 6 in the market.

Six years ago I got into a flamewar on Hacker News about Perl 6 not being done yet and had to clarify to an angry Perl hacker that by "not being done", I meant, "as of 2010 we only have an incomplete implementation of a draft specification of the language".

I'm a Linux sysadmin/devops with a heavy automation background and quite an interest in automation. I've been writing Perl (until recently that is) for over 15 years. Today I focus on Python, both in my personal and work projects.

I do it for the same reason I learned Perl originally, because I have a mortgage/rent/expenses to pay. You have folks who walk around with LISP books under their arms and learn obscura perfecta like OCaml, but I'm a lot more simple-minded: I learn what I need to learn to get my job done and also new jobs/gigs lined up. I'm not an academic, nor an advocate.

Don't get me wrong, I enjoy reading purist debates, early adopters, experts, people with interest in dynamic language theory, duking it out. At the end of the day, though, if not a single person around me writes in Perl 6, and not a single job listing shows Perl 6, then I'm probably going to wait it out until that does start to happen. And then we'll see.

So, to answer the question by the original poster: I haven't adopted Perl6 because I'm not an early adopter. Maybe if the 24 hour day suddenly became a 28 hour one ...

I know this isn't going to happen, but I think the only way to make Perl 6 the new poster child would be to rename it.

It has a lot to do with human psychology. People don't like that argument, but many things happening in IT have a lot more to do with psychology, sociology and marketing rather than any technical ("factual") reasons.

The most technical reason probably is the cost to switch, but that reason doesn't explain many things and people do switch to new things all the time.

For me the Perl 6 and Python 3 changes have similar problems: no realistic solution for massive code bases.

I worked at least 3 different places that had massive code bases in Perl 5, that saw no signs of changing the entire time. Furthermore, ecosystems develop around these things, e.g. people (unwisely or not) saving data as Perl 5 hashes. There are similar dependencies on the Python 2.x way of doing things.

Also, every project has its own long-term maintenance items to do. LONG before I consider screwing with the very syntax of my entire code base, I will be thinking about things like: avoiding deprecated APIs in other libraries, refactoring problematic designs, etc.

Also, project repositories frequently branch out and every merge is a pain point. There could be many people developing unrelated items in parallel. There is NO convenient place to merge in somebodys completely new language syntax, just like there is no place for gratuitous reformatting of code or other high-impact, low-benefit scenarios.

And finally, even if a code base isnt massive, developers have limited time. It is always more attractive to fix some bugs or add dozens of features. It is never attractive to do a complete rewrite of code for unproven gain and definite pain.

I used to love Perl 5 in my free time for personal projects around 2009-2010, frameworks like Dancer or Mojolicious were getting traction and it was a lot of fun; but when I wanted to change my career and move away from what I was doing at the time (PHP mostly), I finally decided to go with Python and that meant no time for Perl (and no Perl 6).

Basically at that point there were less Perl jobs and the language had (has?) bad reputation on being too easy to write hard to maintain code that I thought the language wasn't worth the peer pressure when Python or Ruby were nice languages too with open and welcoming communities behind them.

But i hate Perl6. It feels like an obnoxious showoff who people prefer not to talk to.

It offers little that I crave for in Perl. And those bits I can do with Go already.

Perl6 is a distraction from what we should have had .. I'm still dreaming of the day Perl7 comes out with these features: (i) full Perl5 functionality (without having that klunky Inline::Perl5), and (ii) built-in concurrency.

Perl6 is late to the party. Sorry kid, nobody likes you and besides, it's time to go home.

I suppose Perl 6 "taking off" and becoming such a "poster child of "scripting languages" nowadays is not so much about "scripting languages" but rather "application platforms" instead. Gone are the days where one would just write a bunch of scripts for a cgi-bin--you're now supposed to write a complete environment for deployment onto highly redundant, low-latency clouds--bonus if going "Serverless" and transpiles to JS.

That said, Perl 6 is becoming such an attractive platform for those who have bothered themselves to go and actually try it; being a Perl 5 hacker myself, I'm taking my time learning it in parallel to a few other languages, and its interesting to see how 2 decades of wandering has brought forth. I suppose that maybe Perl 6 will become like a Lisp (in such that learning provides for a deeper appreciation,) or maybe not (e.g. we actually make https://xkcd.com/224/ happen,) but at the end I know Perl 6 will be there as a tool I can reach for.

"why isn't it (Perl6) the poster child of the scripting languages yet?"

In the Perl6 community there is no equivalent of "The Python Tutorial" [0] or the "Python X.Y.Z documentation". From Python 1.X onwards, if you wanted to learn Python from scratch, this is where you started. Where is this in Perl6 version that assumes you start from scratch without having to learn the baggage of PerlN? [3]

The syntax is even more complex and harder to learn, than the syntax of Perl 5, so it has to offer something worthy of an effort. Even worse, it has to compete with non-scripting languages, limiting its usage to pretty much just I/O bound tasks.

If you think about it the only one among new scripting languages that offers something over competition is Elixir, because of the actor model. And it's getting traction.

I'm a (very happy) Perl (5) dev and although I've attended lots of Perl 6 cool presentations, I haven't took the time to learn it yet. My reasons are related to the fact that there are not that many commercial opportunities with it just yet.That is a thing which I expect to change in a relatively short time. I've already seen a few job posts looking for Perl 6 developers, which, given the language is declared 'production ready' for less than a year is a pretty amazing stuff.

Also, there aren't hat many libraries in its ecosystem yet, a thing which can be a plus for devs who want to create a name for themselves in the open source world by implementing/translating libraries with a large user base potential.

That's very similar to saying why haven't Perl 5 folks switched to Ruby or Python or whatever. For all intents and purposes, Perl 6 is a different language with a very similar sounding name. Those folks who have used Perl 5 and built up systems around it, they are only going to switch if there is a compelling reason to.

I was tired of dealing with TIMTOADI (there is more than one way to do it), one of Perl's catch phrases. More like there's more than 50 ways to do it. It sounds wonderful and liberating, and it is, but it also means that when you just want to read some docs, the docs go through all the different ways, when you just want to get something done right now. And reading others' code, no two solutions are the same. Are there benefits, sure, yes, but sometimes you just want to know the best practice.

With Perl 6 having a learning curve, I thought I might as well use that time to instead learn Python, a language designed with the stated principle that there should be one preferred way to do things.

Unfortunately I started learning Python just as the Python 2 vs Python 3 rift was at a peak. Sigh.

I have been using Perl since 1996. I use it as my main language in a professional setting day to day.

I have started doing some things in Go, but the bulk of my code is Perl 5. Having lots of code written in Perl 5 that has worked for over a decade, makes a tough case to suddenly switch to Perl 6. In some sense its like switching from Python 2 to 3. You have to get all the CPAN authors to port all of their modules that your code depends on. I think there too much risk and not enough resources on the corporate side to make the switch.

Perl 6 took so long to come out that it long ago became a punchline. The actual launch was the softest I've ever witnessed, and the retention of the name is misleading given the huge changes in the language.

I expect usage and awareness will grow with time, as the geniuses that do the proofs of concept that get the masses' blood flowing burn out on Clojure, Rust, and Haskell and start looking for the next big thing, and write a framework that makes people's heads spin.

I have been using Perl for more than twenty years. I remember installing Perl 5 because somebody had written the network monitoring tool "SATAN" in it. I have written some nasty code with it, and some pretty clean code. Relying on CPAN, I have saved myself and others just huge amounts of time and trouble.

These days I tend to use Python for new projects, because the young coders where I work are more accustomed to that. Now, if someone where to show up fresh out of school and sure that Perl 6 was the thing, I'd be open to trying that.

Mainly because it isn't ready yet as it is slow and certain features are still missing like macros and concurrency. It's a cool language for sure that I'm excited about, but needs to be at least as fast as P5 (on average) before adoption.

The comments here are great and answer the question in various sensible ways, but I slightly wonder... could Perl make a comeback if it got its own Rails equivalent? You could argue that Laravel has done a lot for PHP (though of course PHP never went into the wilderness in the way that Perl did). Perl 6 seems to have a lot of magic in it, and I wonder if any of that could be usefully leveraged to make something very modern, very clever, and very Rails-esque that actually might get people interested in using Perl 6.

I think it's because the language appears to be very complex. So much syntax, context, and novel terminology.

It appears that Perl 6 lets you be very clever and can save you some keystrokes. But I don't want to be clever, and am willing to type a few extra keystrokes if it makes things easier for me to understand the next time I look at my code.

Actually other languages user got some awesome web frameworks: PHP got Laravel and Symfony, Ruby got Rails and Python got Django and Flask. On other hand Perl community kept waiting for v6 for long time and in due course users shifted to other languages due to reasons mentioned above.

This is one of those things where everyone who even understands the question is going to have an opinion, and the rest will too. I've worked with Perl professionally since 1995 and still do, which doesn't necessarily mean I know what I'm talking about but FWIW here's my best guess.

I think Perl 6 has not taken off because of three things:

1. Other options.

When Perl 5 really took off in the mid-late 90's, building much of the early Web as well as all sorts of business software (we used it heavily in biotech), there weren't so many other options.

For server-side things it was (or at least seemed) faster, easier, and much much newbie-friendlier to use Perl than the other "obvious" languages, C and Java.

Now there are a lot more languages to choose from, inluding ones that share Perl's original virtues of accessibility and "hackability." While some of these newer languages were gaining ground, Perl 5 was enjoying subtle improvements while seeming more and more dated.

We have large populations of potential Perl hackers who have, for good reasons, chosen to develop their expertise in other languages. They have little interest in learning the "new Perl" because they don't have deep knowledge of nor love for the "old Perl."

That at least some of the hot new languages (Go, Swift) have corporate backing with infinitely deep pockets may also be a factor.

2. Hiring death-spiral.

It's very hard to hire for Perl programming jobs these days. We older Perl hackers often move on (or up) and the young folks look around at where the excitement and the jobs are, and they see them elsewhere.

(Perhaps counterintuitively, there are also a lot of young programmers who prefer Java: maybe not much excitement there, but never any lack of employment.)

The fact that it's hard to assemble, grow or even maintain a Perl team means that it's harder to justify developing systems in Perl from a business perspective. On the one hand you have all the advantages your senior Perl hackers can list for you, and on the other hand you have the cold hard fact that the systems they build will one day be maintained by junior devs who wish they were using something else.

It should be obvious that this is self-reinforcing, and I think there are probably thousands of little Perl shops embedded in big companies where the managers have long been dreaming of a path away from Perl, while the senior Perl hackers reluctantly start to agree with them.

This ends up as Perl 6's problem, not just Perl 5's, because the same people who would usually champion the newest version of the language are busy keeping their Perl 5.x legacy systems alive with shrinking staffs and growing pressure to get off that train.

Also, it will be hard to get your management team to back a big push into Perl 6, because they will only hear "Perl" and remember how painful it was to find Perl people the last time, and the time before that.

3. Approachability.

Perl 6 is really cool and really hackalicious but also not super easy to get started with. Where even back in Perl 4 it felt like it was newbie-friendly, the only thing newbie-friendly on perl6.org is the butterfly logo, of which I am not a fan.

Something like the Go Playground[0] would be nice and might help spread the word. As would a story about what Perl 6 is better at than anything else.

As far as I can tell, cutesy "spokesbugs" aside, Perl 6 is presented as something for the Perl crowd. And as noted above, much of the Perl crowd is too busy for it.

A lot of languages get popular because they show you how easy and fun it is to do thing X in them, and you've always hated doing X in whatever other language. I'm not sure what that X would be for Perl 6, but I have a feeling it's something about the writing itself, which might be a hard sell, but I don't really see it being sold outside the Perl community.

...

Anyway, all that said I would love to see Perl 6 get some traction. I just have no idea where it's going to do that. Maybe if a super high-profile project appears that's all done in Perl 6? Maybe if a small but influential cult of AI hackers falls in love with it? Maybe if it out-Pythons Python as the default entry-level "big data" language?

Because of the reasons listed here, for this old Perl hacker "write stuff in Perl 6" is stuck at the way-way back of the backlog, and well behind at least two other "write stuff in..." stories.

From my perspective and I went through a years-long period of writing exclusively in Perl Perl just doesn't seem to have anything to offer me anymore. I resisted Python for a long time because Perl was so much faster, but eventually I switched because Python was much less a write-only language.

I've since switched to Go, because the way it handles static types is actually pretty awesome (for the most part there are edge & corner cases), and I find that my software is much more reliable in Go.

For my quick-and-dirty tasks I have Lisp; for my job I have Go: does Perl 6 offer me anything I don't already have?

Where did you even get a mention of moarvm for you to get confused about?

Sounds like you're making shit up just to be difficult. The giant button on perl6.org says "Rakudo is a compiler for Perl 6 code", it leads you to a page of choices, among which is a link to a binaries where you choose your platform.

It's like complaining that you have to use `gcc` when learning the C Programming Language and being flabbergasted to find there are multiple versions of it.

A new form of text editor designed from the ground up for lower precision input devices (e.g. motion sensors, touch screens). Demo video at the url above.

I had issues using mouse and keyboard and gave up programming for six years until the concept behind this hit me. The actual software is an engine/framework for producing particular text editors (I figured I'd need to extend it to in a similar manner to Emacs, so that I could efficiently do, e.g., command line things too). It could also be configured to edit natural language documents for text editing on e.g. mobile devices and VR.

Editing and navigating documents is done, and there's a system built, but not yet attached to the UI, that is effectively a universal autocomplete: you give it an EBNF grammar for some language and it can list all grammatically valid options (that you could insert) from any point in a document. (I'm thinking of extracting and open sourcing that part. Not sure yet, though.)

I worked on it for a year and half, had an increase in medical bills and had to work morehaven't touched it much for a couple years. The copy on the website is oold.

I made this last year, but failed to build on the initial audience... There's no revenue, so any offer will be considered.

The site was launched in August 2015 and got 79,000 pageviews in its first month. It also got some media attention which has given the site quite good search engine ranking: it is a top-3 Google result for most of the relevant keywords and search phrases.

I can also throw in the domain BabyNameCheck.com. There's no site there currently, but you could easily reuse the word check back-end from WordSafety... Just make a new baby-themed design and it could be a site that any parent would want to check out when trying to decide a name.

(Edit: Please don't post word suggestions in comments - there's a form for that on the site :))

I launched this a few years ago with great success (>$100k in a single day), but despite the content being highly valued by the folks that have gone through it, I've had a hard time getting it in front of people. It's very profitable, but I just don't have the time nor the marketing acumen to really take it to the next level.

I made it March 2015 and updated it December 2015. It's been sitting since, with a few thousand people using it every month.

It hit the #1 spot on Product Hunt, and after that it was posted about on Lifehacker, Inc., Newsweek, and others.

I've recently tried to spend time updating it to monetize it, but I just don't have the time to work on it.

Right now I make $100-200 per month from AdSense, but I really have no idea what I'm doing with it so nothing is optimized with the ads - they were just kind of slapped on there. I know it has potential to make money, I just don't have time.

I have a project where I "reverse engineered" this world class poker bot: http://www.slumbot.com. I have something akin to a "what would slumbot do?" API where you can enter the parameters for a heads up poker situation (hole cards, aggression, etc.) and get back a decision. It's far from perfect (and the code is a mess) but it worked surprisingly well in practice. I don't have time to work on it since I've started a new job and online heads up poker is kind of dead at low stakes but it might be useful to someone? Drop me an email via my profile if you're interested.

A cms for schools and colleges, lets students, parents, teachers, staff, etc log in and view/add student attendance, homework, assignments, datesheet, exam result, generate report card, view/manage student and teacher data, lecture timetable, send SMS/email newsletters, get different printouts with different set of data columns and a bunch of other stuff that I am probably forgetting about. I made/maintain it myself. I have 4 paying customers (schools). Revenue isn't much but whatever it is, it's all for myself, not have to pay anything forward other than hosting which is like 2500 rupees / year (37 dusd/year).

I wrote a (free) simple super-basic photo editing app natively for iOS, Android and Windows Phone and have over half a million downloads. It has been a good resume piece, but I don't have time to work on it anymore.

I also wrote mrgr (also on mskr.co) a similarly simple video editing app for iOS. Less downloads, but I'd throw it in if anyone wanted to buy either.

I might consider parting ways with http://www.LiberWriter.com if the right person were interested. It currently has revenue and doesn't require much of my time, so it's not urgent for me. Someone who is willing to take good care of existing customers is important too.

http://www.sysadminsoftware.comI made this tool like 5 years ago, to scratch my own itch as a I was a sysadmin in charge of securing thousands of machines. Those days are gone now and I currently have no time for this. The tool still works.To be honest I have not advertised it at all. I made sales only from people landing on the website through google search.

It's not that I don't have time for it, I'm actually looking for a partner. I'm making a DIY Chromecast-clone Software solution, which you install on Debian and you can use our apps to cast stuff to your TV. Great way to repurpose an old PC, or test out a rPI, etc... It's meant to be semi-proprietary, and it's great for countries where Chromecast hasn't launched and 2nd hand ones go for as much as $100 which is a price of a refurbished Intel Atom PC :S. Mail me at (my username) (at) gmail (dot) com if you're interested and want a demo over Skype or something. It could earn money by showing ads on the screensaver or simply being pay to use...

Written in Django, got some HN love a while ago - no signups for a while now but we have over 500 accounts that signed up at some point. About 20 sprang for the "Pro" version at $10/month. We even had a customer pay $50/month for an API version integrated directly into their site.

It's used to have your customers send their browser details directly to your inbox. Just point them at your site such as http://example.browser-details.com (CNAMEs with custom domain possible).

Created to scratch our own itch: previously, most of our customer would be hard-pressed to name their browser version so it was very helpful in development. Uses an external API to map the user agent string to browser make/version.

It's not making any revenue so any offer will be considered. It's a tool for helping inexperienced founders avoid common mistakes when starting a business with someone, both legally and in terms of making sure you're on the same page. Did it after getting very burned on a business venture because of this.

Got retweeted by some TechCrunch writer and also got to the frontpage (I think) of ProductHunt a while back. But I never got the time to get the product to where I wanted it to be (pay a $49 fee to get a good legally binding agreement based on the data you provided that you can just download, print and sign, and avoid problems and lawyer fees) nor market it properly (I also think it would be great to partner up with people who organize hackatons etc).

I'm interested in selling http://www.seasonalysis.com. The site has been around for over 4 years and has a wealth of seasonal market data. We have subscriptions ranging from $50/month to $5000/year with several at the top membership tier. I think with the right marketing campaign and site content it could be quite lucrative but I just don't have the time.

This is something I had to put together from scratch to cope with working across any type of backend programming language when I was doing ecommerce web apps to enable customers to edit their websites very easily and flexibly.

KitGUI is a content management SAAS that runs off of Amazon S3 for content storage and plugs into any backend. Editing is accomplished on the customer's website directly through a JS plugin. It makes a little money but more as an adjunct to existing products. I would also be open to working on this seriously if there was investor interest but there is a hell of a lot of CMS systems out there. It is very sturdy because it runs off of Amazon S3 for all the content serving.

Web-based form and application creation software offered both as a stand-alone purchase or fully operational cloud subscription. Currently outputs as PHP or C#, can be extended to just about any other language/platform.

I wrote a very popular iOS animation program, FlipBook, and a friend wrote a companion Django-based website, flipbook.tv. Then I hired a group to write an iPad version, FlipBook HD. I also own all the legal rights worldwide to the trademark FlipBook for mobile animation software. I've just been too busy to update it, so I'd be up for selling it. You can reach me on twitter (@joshanon) or via joshanon.com (there's a contact form).

Workday-lite (really lite) for small businesses. Individual components such as time-off tracking and expense reports all have sites on there dedicated to them individually that seem to do well. This covers all of them and could use somebody who has time to dedicate to (content) marketing.

A bunch of .it domains with exhausted, failed or never started projects: bestapps (formerly a web magazine, now a never happening apps recommender system); databot (now a landing page for a local business); jobsud + jobcentro + jobnord (an empty job board, not starting because of a break up with the sectoral partner). Getting rid in order to focus on my primary nuclearresearch.net. Anyone going for the full batch of five .it?

A Slack bot leaderboard for ping-pong, chess, etc. Open-source, written in Ruby, https://github.com/dblock/slack-gamebot, with premium features. A handful of paying customers at $29.99/yr. No time to work on it.

Developed a solution (File System Filter Driver) to prevent ransomware from encrypting users' files. It's 70% done but I have recently accepted a position at a company and will not have time to build a full fledged product. I have tested it against major ransomware variants and it has proved very effective. I am looking to license either object or source code.

www.c0dereview3rs.com (I mangled this to avoid having this comment associated with the domain).

Boutique consultancy providing professional code reviews. Could be run by a coder who likes to do reviews and writes well or by a project manager who contracts the work out to experts with the appropriate skills. I have done projects both ways. I have some good reports to give to prospective clients and have found that customers who reach out are usually serious.

It has been completely ignored for many years. It used to get a good lead every month, but I havent checked the inbound email address in years. I joined a trading group in 2007, loved the work and quit doing side projects.

I won Yahoo!'s international student programming competition in 2009 with this site. About a year ago it stopped working because of deprecated PHP functions. It had/has quite a few users but I've been too busy to fix it up. It could use a more nurturing home.

If the content will be deleted after 24 hours, what about the comments and all the discussion? I think this is not the case like Snapchat, which has been a chat/messenger app. Comments and discussion for certain contents needs to be preserve. If you are deleting the content after 24 hours for a clean interface, why not just remove the comment?

Android uses Dalvik/ART, which is an alternative to the JVM that has an entirely different set of optimizations for mobile. The most important one is that object creation is significantly more expensive -- if your code is allocating lots of objects it will significantly impact performance. This is why Android has the whole Recycler paradigm. My gut reaction is that Effective Java recommends a lot of heavy-OO practices which may impact Android performance.

I would say most of it IS appropriate. A lot of the advice is good for Java development in general, regardless of platform. Enums are one area that is hotly debated in the Android community, but there is no consensus on it.

Generally, I would say follow the advice in Effective Java, but be aware of some potential performance issues and how you can avoid/fix them if need be.

Edit: I noticed there is a chapter on serialization. This can be ignored by Android developers in favor of Parcelable.

OK, I know a lot of folks are tired of me talking about it, but if you are interested only in UX functionality and not necessarily in learning the latest trendy tools, I have built a library that gives you a lot of what the other front-end libraries do at a fraction of the complexity:

Basically you use HTML attributes to drive AJAX requests, and render your HTML on the server side. (There are actually very good theoretical reasons for doing this[1][2].) It is built on top of jQuery and dovetails very nicely with it.

And, again, if you are looking for simplicity in front end development, while still building a modern web application, I think it's a good option. There is no tool chain beyond what you currently use for web development.

Frontend at this point is a problem just as much as backend is a problem... And I don't mean backend as in "I built an MVC app with Rails". I mean JVM + Data store + infrastructure with virtualization + APIs + caching + queues + blah blah blah.

You don't wake up one morning going "I know some java...lemme learn Dynamo and S3 and SQS while learning dependency injection and Spring while figuring out what this SQL thing is about on Postgres...or should I use MySQL? Oh and there's Maven and Puppet and all the deployment tools...

That would be totally insane.

Look at frontend the same way. If you're trying to learn react and babel and ES6 and webpack and eslint and flow/typescript and NPM/Yarn and Node while looking into Service workers and websockets at the same time as reading a book on Functional programming, yeah, that's overwhelming.

Pick one thing and a time and go for it. If you're a backend developer and getting overwhelmed by frontend, it's because you're attacking it from a "Frontend is an atomic small thing" perspective, as opposed to being an ecosystem just like on the backend. And that won't work.

If not, I'd recommend taking a step back, look at the few most popular options, and start with the most "blessed" config/boilerplate with no custom changes.

Like for react, use the create-react-app thing. Don't add anything on top aside from what is needed for the bare minimum of your project you are learning with.

Feel the pain points, feel what you struggle with, make notes about what works well. Then when you have a minimum viable product, start adding "stuff". Maybe try out redux, or mess with webpack yourself, try out that library that you see people on HN bitching about all the time to see if it's really that bad. Just start fixing the worst issues you had with the language/stack, and understand how the additional tooling solves (or doesn't solve) your problem.

Don't worry about size, number of files, performance, how messy it is, how over engineered it feels. Just make something first. You'll have plenty of time to learn that other stuff once you have a good foundation. And at that point you'll know to leave out x, or that y isn't over engineered, it's just engineered.

Rome wasn't built in a day. Expect your first few things to be complete trash, and don't worry about it.

First, it's important to understand that most of these technologies have emerged and became popular because they solved real problems. In this regard, it may be difficult to "learn" them, if you never had those problems in the first place. If you feel comfortable learning jQuery, learn/use it enough to run into its weaknesses -- it won't take long. Then moving on will feel more natural and will feel less like effort and more like pain relief.

Second, I would be more focused on obtaining fundamental programming skills, like the ones you get taught in academic CS classes, and less concerned about [insert-your-shiny-"new"-js-paradigm-here]. The reality is, pillars of programming haven't changed drastically since 70ies, and if you're very comfortable with the fundamentals, everything else becomes less a matter of understanding, and more a matter of memorizing ("oh so this is how you do fundamental thing X in this particular framework").

Finally, as others have rightfully noted, focusing on one thing at a time makes learning way more efficient. It may seem counter-intuitive, but learning ten things consecutively will take way less time and energy than learning them in parallel.

The single most important advice I could give you is : take whatever path/framework you want, but take it seriously.

Javascript has a long history of not being taken seriously. In early 2000, it was considered a malware language, that you should disable. Then rails started doing cool things with animations and ajax, and developers started getting into it, but only by swearing they did not want to waste their time on it. I think that's the reason why jQuery got so much success: its promise was that you could use cool js features without having to learn much about it. Personally, my big "oh wait, this language is cool" moment has been when I discovered mootools. It was not unlike what es5/6 is nowadays.

And then, there has been this whole "javascript fatigue" thing. My analysis on this is that the same phenomenon applies: backend developers know they need to learn js but still do not consider it a "real" language and are overwhelmed by the amount of things they have to learn.

By simply considering javascript is just as important as your backend language, and deserves as much efforts from you, it should not feel any more difficult. Oh, btw, css matters too :)

2. As a first pass, don't overfocus on the details, focus on the conceptual model: what are the key abstractions, how do they work and how do they interact?

3. Read a book, not just tutorials. Harder for newer frameworks, but got to be something. A decent book will give you a much deeper view than a tutorial, helping you with item 2 on the list.

4. Start looking for common themes that connect to existing knowledge. None of this is really new stuff; front end frameworks inherit ideas from GUI frameworks, and from backend web frameworks. I've written a bit about doing this for programming languages (https://codewithoutrules.com/2016/03/10/compare-contrast/), but same concept applies elsewhere: everything is variations on a theme, basic functional requirements forcing particular forms.

Ok, I read through this whole thread and with the variety of recommendations for frameworks and tools mentioned it will make your head spin for sure.You mentioned Vue, so I will talk about Vue. Vue will get you there in terms of any complexity you may need. React, Angular, Ember, etc. will also get you there, but you mentioned Vue so let's stick to that.Wrt boilerplate templates: just use vue-cli to generate the project, there are not even that many options, and you get hot-reloading, test harness with it automatically.

To keep it real, I imagine your SPA will need different sections of the screen to show: a header, some kind of menu (sidebar?) and a main window that shows what the user is working with for the moment. How do you get the main window to show the relevant content if the user clicks on a menu item? If you solve that (hint: vue-router), you now understand one of the main benefits of using a front end framework for managing components and avoiding round trips to the server.

Next challenge: create a nice page that has, let's say, two different panels. One panel shows a list of items, and the other panel shows some details about the currently selected item from the list. How do you: 1. show the details about the selected item in the second panel? 2. If you change the item name in the detail panel, will it update immediately in the list above? Solving for this will satisfy your curiosity of why a state management solution would be useful, and you'll be led to ...... yes, Vuex!

These 'challenges' would be enough for a good 90% of common web apps/SPAs, with navigation and master-detail UI.

Just one piece of advice, pick one current framework, learn it by solving these common problems, and you'll be on your way. Source: I have built and rebuilt a complex system in Angular, Meteor, React and Vue (I do NOT recommend that kind of churn, but keep in mind each framework have had significant shortcomings over that past 2 years which made client-side state management difficult).If you take the intellectual route and try to do all this with vanilla JS or solely jQuery, be prepared to spend a while before becoming productive (depends on your app's complexity of course).

Learn by doing. It is hard to learn by just reading. You should have something in mind that you want to build. If you don't or can't come up with something, maybe you can build an internal tool your company may find helpful, or talk to friends to see if they need something you can build. Once you have an idea, then you have a goal.

Since you know jQuery already, that makes it easier to start. Start building it with jQuery first. Then look for a component or two for which states get a bit complicated. Replace the jQuery code in that/those component with Vue. You're already ahead since you've decided to use Vue. Many people are not even sure what JS framework library to use. Vue is an excellent choice, by the way.

This way, you have a reference to compare to. If you like Vue code better, you can think about if you want to replace all or most of the jQuery code. If not, then you can ask why. This may lead you to a deeper understanding of Vue.

Ask yourself if you're building a website or a web application. The main difference in my mind is websites are static documents at the end of the day, allowing users to read text, while web applications are dynamic and often allow the user to modify the data in the system.

If it's really a web application you're after, then get ready for some complexity. The state of the art has progressed significantly in the last couple of years, to the point where modern web applications are as complex as iOS and Android applications in terms of the number of moving parts. To add to the confusion, there seems to be a large number of framework and library choices on the web, where with iOS and Android the vendor largely controls the environment, and the tooling choices are more obvious.

Try to see the big picture as you're looking at all these tools, and recognize that they're largely interchangeable. We can see a common architecture emerging, where the latest versions of all the largest libraries have coalesced around the same basic patterns and ideas:

You really can't go wrong learning any one of these libraries. Even if you aren't using the same library a year from now, you'll understand the application design patterns and JavaScript, two skills which aren't going away any time soon.

Backend developer here.Everytime I need to create some sort of rich UI I discovered that the last framework I learnt was "no longer valid". Happened with JQuery, Knockout and now Angular 1.

My feeling is that frontend development is overcomplicated/overbloated. Specially with the big players (Angular, React). Lucky me, I found my way with riot.js. Simple, elegant, lightweight and fast enough. You don't need a lot of complicated boilerplate, nor learning a new template language or syntax.

First, I would say you need to understand your own learning style and what methods work for you. For me, practical beats theoretical any day. Everything I've become good at, I almost always had tried learning it from reading books or tutorials online, would get bored and give up. It wasn't until I needed to use the tool to get some greater purpose, then I could use the draw of having that tool solve one of my needs, and had a reason to not get lost in the details until I needed them. So read up on the general types of problems they're commonly used for, and get an understanding of what they might be able to do, and if something sounds like it could help towards solving a problem, go after it.

Also, people like to shame you when you're learning, as if using "training wheels" will keep you an intellectual cripple. I love training wheels. They get me productive enough to keep me interested, and I can always dig in deeper when I want to/have time, etc.But don't be afraid of just getting the job done. Then go back, learn from your mistakes, and iterate.

Meanwhile, you're building real experience, familiarity with solving real problems, and learning the internals of the tools you're using, while the people arguing over the right editor to use, the right framework, the right generator, toolkit, bridge, etc, are all still posting on medium about how some new programming language/paradigm will solve all of our woes.

At the end of the day, whatever helps you understand it better, go for it, no matter all of the "should"s and "shouldn't"s people will try to burden you with.

> Everything I try feels messy and strange, leading me to a lot of frustration.

It appears you've learned to program but have not yet learned to learn. Like learning to do anything new, you start with minimum viable product. Let it be messy, buggy with edge cases, etc, just be completely persistent until it works and then build from there. Then do it again and you'll do it better and faster.

You MUST persist.

Don't worry about using anti patterns. I know this is somewhat controversial, but in the beginning shipping with antipatterns is better than someone who gave up. Besides, a diligent engineer spends their lifetime perfecting their craft.

I say this because when I was learning I was completely debilitated by fear of doing it "wrong" and setting myself up for failure in the future. If you're actually interested in becoming a better engineer this simply will not be true.

Lastly I leave you with a quote:

Nothing in this world can take the place of persistence. Talent will not: nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not: the world is full of educated derelicts. Persistence and determination alone are omnipotent. [Calvin Coolidge]

In this day and age I think you should use vanilla JS and not jQuery. But I don't think you need to use a MVC or "view manager" framework for simple projects. My personal standard is when I start writing a bunch of code to track state means I need something to do it for me. But if we're just talking about some basic AJAX forms that send to a server, these frameworks are overkill.

Try the Elm programming language - it should save you the trouble of dealing with the explosion of JavaScript frameworks. It is designed with learning in mind, and should provide a really direct path to high quality front-end code.

Take a step back and focus on JavaScript the language. Really learn how things work. Then take a step even further back. Learn more about data structures, about abstractions and how to think declaratively vs. imperatively. Rinse and repeat for the rest of the stack.

That way you'll have a solid foundation to build on top of. At some point you'll start to see patterns, and that all the "new" things are just incrementally improved materializations of patterns and concepts that have existed since way before the web was even thought of.

Spend most of your learning/experimenting time on fundamentals (timeless). Learn actual implementations and specifics when you need to, just in time. Avoid learning specifics (lib/fw) just in case.

Source: My own personal experience + the very insightful experience of teaching classes in JavaScript and React the last two years.

I'd suggest getting a solid understanding of the core front end technologies: HTML, CSS and vanilla JavaScript. If you can't build reasonably complex websites without the crutch of a framework or a more complex tool chain, then you've probably missed out on getting the basics right.

You should also learn about UX and design. I met a self appointed frontend developer recently, who didn't have any understanding of what a good designer does. This led to some really horrible conflicts where core design decisions got ignored (the developer thought they knew better) and the end result was a mess. Designers are your friend when working as a frontend developer and will help to make sure that the end product is both well built and actually useful for the users.

If you're building frontend your job is to make sure that your audience can use it. There's no reason not to learn and use fun tech, we all like play and make our own development lives easier, but your users must always come first.

If you can do all of that then you'll be able to do a pretty good job as a frontend developer. Picking up the latest and greatest frameworks is really quite easy once you understand how JS and the DOM works. You'll have the added advantage of being able to critique new tools as well.

I'm currently using Vue.js to do some projects and can explain you everything you need to get started - it's a great framework and doesn't hide too much Javascript and emphasizes POJO (Plain old Javascript objects). I'm convinced that no one here can help you without investing more time than searching for their favourite links. If you don't mind, leave an email address in the comments.

Read about MVVM (Model-View-ViewModel), because this is the design pattern used by Vue.js, I assume you already know about MVC if you did backend programming. If you're unsure about MVC in the frontend try to build something simple with jQuery using Models, Views and Controllers. I did this in the past and it's helpful to understand the problems of SPAs that we're trying to solve. I don't want to repeat everyone's comment, but you should be aware that the abstract concepts and fundamentals are more important than the frameworks you are using, I guess you already know that.

I can't guarantee you that I have enough time to explain everything thoroughly, but I can assure you that I can give some helpful directions.

Got some pointers for you. First, I keep a big list of links to high-quality tutorials and articles on React and related topics, at [0]. As part of that list, I have a page called "Basic Overviews" [1], which has articles that try to help clarify what these various tools are, how they fit together, and what you would use them for. There's also a couple articles in that section that give advice for how to tackle learning front-end stuff, and not be overwhelmed.

As for React specifically, there's an official tool from the React team called Create-React-App [2]. It hides the details and complexity of project config from you until you're ready to tackle them yourself, and lets you focus on just writing the app. Meanwhile, the React docs were just revamped and improved [3]. There's also a great community called Reactiflux on Discord, which is a set of chat channels dedicated to talking about React, Javascript, and React-related tools [4]. It's a great place to hang out, ask questions, and learn.

Finally, part of what's going on here is that people are trying to write highly complex and powerful applications in the browser, not just "pages" with some interactivity. Complex applications mean some meaningful amount of complexity in the project setup. These tools are basically the web equivalent of a C++ compiler toolchain and standard library. So, there's several aspects here: the tools are somewhat big, the libraries are sophisticated to enable you to manage your application's complexity, and your own app code is going to be more than just a couple click handlers.

The other thing to remember is that you don't have to use everything all at once right away. Focus on learning one or two tools and concepts at a time.

Hey, I've been managing 3 single page applications in the last 3 years. I could breakdown what you need to get started, and answer questions along the way. We can hop on Skype or Google Hangouts. If you're interested, contact me at dmak [attttttt] moneytree.jp

I would recommend you start by building out a non-trivial project using the tools and technologies you know (jQuery), but try to do a single page application that calls services via RESTful APIs. Bonus points if you can avoid hash urls using the HTML5 History API.

If you're not familiar with the standard Promise API and ES6, add babel and the core-js shim. This gives you things like block scoped variables (let/const), arrow functions, and the new class syntax. Start here. Most new frameworks and tools expect you to know modern JavaScript.

Eventually you'll want to start breaking apart your code and organizing it by responsibility/concern. You'll want to use ES6 modules and a tool like WebPack to resolve and bundle your modules all up for production. This also means learning how to configure WebPack to transpile your ES6 code using babel.

Now just focus on building out your project and cleaning it up. Maybe deploy it so real people are using it and you can get some feedback.

Once it's been out there and people are using it, plan a major new feature change or addition. This is where you might start feeling the pain points that are addressed by modern libraries and frameworks. When you do, start researching things like Vue.js, React, Redux, Angular 2, etc. Pick one and migrate/refactor your existing code into it before attempting anything new.

If you follow this approach, then your learning will be needs driven and practical, which keeps it from becoming too academic and uninteresting.

Frontend development has come along leaps and bounds since the days of document.layers and MSIE6 alert() debugging, it seems to be slowly coming out of a renaissance period lately as many devs have reached a consensus that they are spoiled for choice and now all that's left to do is, well, build.

There is this trend of developers feeling just as you described: overwhelmed. But rather than feel that, I try to embrace it. Like anything on the web, if you're not building on strength, then you must be in it for other reasons, like trying to impress employers, or trying to learn code because apparently it pays the bills better than other gigs.

I would start small, and treat everything like an experiment. If an experiment works well, you can build on top of it, and import what you learned from experiments into full blown (hopefully paid for) development.

I sometimes have to remember to use <em> instead of <b> but only because I didn't think such things were above me. Indeed it's a miracle a visitor to your site can even read the content with the temptation that exists to include another slider widget, or inaccessible web component.

And then, let's say you picked Vue.js. Googling MVVM and learn about the basic concept from your best backend language. (Reading as much as you can. Some good articles are written in other programming languages also.)

And then, starting to read source code as much as you can. I won't pick big projects. Just pick any sources you think you're interested and understand it.

After all, you will get the whole picture how the app should look like and why framework trying to do X & Y.

One option is to eschew front-end and do to work for a large company where roles are so defined that there are jobs that truly are back-end. Pretty much anywhere else you go, even if the role is "back-end", there is a chance you'll have to touch front-end at some point.

I wouldn't suggest that, especially since you started off with JQuery.

If you don't mind probably rewriting everything and don't have models that are that complicated, you could take a look at Electrode. I've not used it, but the goal of their project was to hide the complexity of JS front-end: http://www.electrode.io/

Angular or Ember are opinionated frameworks that might be good to use if you can give up JQuery and just embrace something new. The following has an answer which suggests Meteor also- it's cool, but is a more specialized use case that might not be appropriate for everyone. Also note that the opinion on Ember being better than Angular is pretty biased- it really comes down to what makes sense and is comfortable: https://www.quora.com/React-Angular-Meteor-Ember-Vue-etc-In-...

However, if it just doesn't matter and you are just doing it to try to stay current, I'd argue to not jump to a new framework unless it makes things easier for you and your team.

There are benefits to using what is popular in the development community, more specifically in the pools of development talent you have available to your company.

But, in the end, what matters is your productivity. Are you getting more done now than you used to? If not- you shouldn't be doing it.

Frameworks like jQuery allow you to do DOM manipulation in a less painful way, but frameworks like Angular, React or Vue do their best to abstract DOM manipulation away. This is the reason you may feel overwhelmed by the learning curve, since a paradigm shift is involved.

I would suggest you to check the basics of Angular 1.5 first, just the fundamentals to understand the big picture and build a basic application.

The reason is because Angular is an opinionated framework which gives your project a specific architecture, so you can focus your learning efforts in appreciating the decisions that were taken for you and how the different pieces fit together.

Whenever you feel comfortable with the basics of Angular, you can start checking alternatives like React or Vue, which will feel less strange and over-engineered at this point.

If you are just trying to learn UI development: try to develop a somewhat complex single page app without any framework (a GUI for a database for example). Don't do it as if you were just changing a document here and there with jQuery though. Try to approach it like a more typical UI development in another language (i.e. write your own mini component library that renders to the DOM, etc..)

By doing this you will see what problems you have to face, and the next time you see a framework you will catch up much more quickly on the good, the bad and how it fits.

Its like when ppl try sports, they buy all these tools, clothes, suplements and cool aid, and the same gear the pro uses. But you dont need any of that to grow some muscles and stay healthy. All you need is a text editor and you are good to go.

Go to pure back-end. That's what I did, although I did it during the time when most sites still required IE6 compatibility, which was arguably more of a hair-pulling experience than you are dealing with.

I suggest to avoid any templates. Start from empty configurations and add things that you need. Avoid blind copypasting, read documentation about anything that you want to add. It might take some time, but you'll have control over your application. Also you might want to start simple, using latest ES6 or TypeScript is not necessary, you can start with ES5, and then, when everything OK, migrate to ES6. Same with CSS/LESS, magnification, source maps, hot reload, etc.

I was in a similar boat and I recommend angular2 using the CLI. The build process is totally abstracted and the nice thing about angular is that you're never really going to be wondering what router do I use etc, because the framework is full featured. Plus it's fairly intuitive. It will be more complex than a jQuery powered Web page, but I think these SPA frameworks assume you're trying to make a more complex application, ie if you can build the same thing using jQuery, then just use jQuery -- unless it's an educational exercise.

Are you in the SF Bay Area by chance? We're putting on a 2-day React & Redux workshop where you build a full stack e-commerce app. We developed this workshop after hearing similar feedback from students frustrated with the lack of tutorials and workshops that teach you how to build a real app with React. It could help you to wrap your head around how to use React in a production application. More details at https://universe.com/realworldreact

in addition to all the great comments on how to start in this area I wanted to add that you shouldn't feel bad about yourself for being frustrated and overwhelmed. The frontend world is a mess at this point in time. There are many options with as many camps arguing about them. There is a large amount of framework over vanilla and most frameworks yet have to mature. You probably will make a wrong choice once or twice (who am I kidding, more than twice) and curse on the trouble it brought you. Two months in another tool or framework becomes the flavor of the day and the major headlines tell you to switch. You have to consider it, but always carefully decide if you need it (because chances are another one comes along).

My point is, the whole frontend scene is relatively immature. So are it's tools and frameworks. Angular2 solves major flaws in angular1. Yarn came to solve issues with npm. Gulp fixed grunt. Webpack fixed both. React... You get the point. Embrace chance. Hit your head once or twice and take the time to learn the most valuable lessons from it.

My solution to the problem of not knowing which framework to learn was to pick an open source product that I liked and learn the stack it uses.In my case I experimented with Discourse for various projects for about a year and as I result I learnt ember js and use it on almost all my projects now.

Does the question implies front-end development now has a higher barrier to entry? It has always been told that front end has a low barrier to entry therefore attracting many people. It appears this is no longer true.

build mini-projects. I made https://enlight.ml - and although it's still a work in progress, it teaches small projects related to web development and ways to actually implement for knowledge of html, css, js, etc.

Let me know what you think! I plan to evolve it by building a codeacademy style interface for learning these projects...

I'm answering this in depth only because I love vue and want you to eventually succeed at it.

if you are not a total beginner and know javascript very well, start with riot instead of vue. riot has fewer conceptual abstractions so it's easier to wrap your head around and doesn't require a complex build system. as a vue user, it will already make sense to you -- using single file components.

if you are truly a beginner:

don't start with javascript at all. start with HTML and CSS. this is how you'll learn about progressive enhancement as you begin to introduce javascript. (in production, you may need to satisfy tor browser i.e. noscript users, non-Google bots for SEO, richard stallman, etc -- so your site must function without javascript, or you're ruining the web. this is just my opinion).

good CSS, if you work on a team, is critical, and almost no one gets it right. use sass, a grid mixin library like susy, and autoprefixer to start. because your username is "pythonicpro," I am assuing you're a python user, and would recommend you apply to your sass the same sort of sanity that python applies to indentation levels. sass allows you to endlessly nest things. this is bad, and a common mistake. also, because python is a whitespace-y language, you might look at pug (formerly jade) for making your HTML simpler.

don't use something like bootstrap, or if you do, only use it for a day to understand the grid and then move to susy. grids are important. learn about grids in a book called "grid systems" by josef muller-brockmann. you will be disappointed by that book. learn to be disappointed by that book because it is a very good book and one day you will not be disappointed by that book. do not use flexbox for layouts or things will look weird as they render on slow connections.

once you get to javascript, you should probably stop using all javascript frameworks including jquery if you're just getting started. yes this means you'll have to type "getElementByID" and "requestAnimationFrame." there are worse things in life (like trying to use frameworks or complicated build tools when you don't know how and why they work). consider using ES6 (my recommendation) or typescript (many others' recommendation) for the javascript, because this is what the frameworks you'll eventually want to learn use. both es6 and typescript work with vue and react, but angular is typescript-only. consider strongly using gulp for babel, typescript, es6, autoprexfixer, sass, etc.

once you are comfortable enough with this stuff, start working on your design abilities. if you have any autonomy at all in your job, you have no idea how much easier it will be for your designers if you speak design. (this is why grid systems are so important). learn about typography, because that's most of what web design is. be smart about CSS em and rem units. be smart about the size of your font files: ask your designers, "have you removed all of the glyphs from the font file that aren't in languages we support?" look up why an em is called an em. learn about colors that are compliant with disability standards. learn about whitespace. read kenya hara's "white." be disappointed by kenya hara's "white." learn to be disappointed by kenya hara's "white." you're well on your way to pleasing your designers.

Yeah, who has time to learn? Just slap in some jquery, some ajax calls here and there. Why use templating when you can concat html strings. And pub/sub, who needs that? You can easily do an ajax call that sets a hidden field somewhere, and a setTimeout for some other "decoupled" module that is waiting for that value. Because front-end is easy if you are writing a big ball of mud. Good practices are for backend developers, because backend is serious programming with algorithms and shit. /s

One tip, Redux is great and is worth learning but if you want to curb the amount of boilerplate and anxiety-inducing added conceptual overhead look no further than mobx. And good news, after a quick search I found that someone has made it one git-command away to implement a simple redux counter on top of a fresh create-react-app template(https://github.com/mobxjs/create-react-app-mobx). Mobx is able to drastically reduce boilerplate and cognitive overhead while still allowing the flexibility to dive deeper and gain just as much granular control as you'd have with Redux. Also it scales well (although that shouldn't really be a big concern if you're just trying to learn how to build production react apps right now).

I'd say, start doing some basic HTML, then CSS and then JS courses, if you don't know the basics yet.

Then, every framework does it's own thing...

I think it's the best if you start with something full fledged.

For example Ember, it has everything you need for front end stuff in one (okay with ember-data in two) place(s). Throw in a Bootstrap and I think you're set for 80-90% of the feature wishes you will encounter.

You get routing, data retrieval and rendering of DOM stuff with okay styling out of the box.

Back in the days (2 years ago) it was enoug to simply include the ember.js, ember-data.js and bootstrap.css and you could start writing a complete app.

2. Use create-react-app or a webpack/babel/react boilerplate to built a little something. Ignore all the things you don't need in the boilerplate and don't try to optimise for production right now.

3. If you're comfortable with this, gradually remove the parts you don't need.

=== Node, npm and webpack ===

All of the tools are installed and configured using "npm install" which installs everything listed in a "package.json" in every project. You don't need to install anything globally except nodeJS to get "npm".

* You install all your runtime-library-dependencies also via npm. Ignore "bower", you don't need it anymore.

* There are a couple of different module-systems to split up javascript code ("requireJS", "commonJS" etc.) Just use the ES2015 "import" syntax. Webpack handles the rest for you.

* There are many tools ("gulp", "brunch", "requireJS") that bundle your javascript-files together into something for the browser. Most people use Webpack now, which is confusing to configure, but does everything you want.

* With Webpack you can just import/require text-files or CSS or images as modules in your code (see "import" above). Webpack will figure out how to serve them (as files, or inline with the HTML or else). It also does everything on-the-fly while you are coding, called "Hot reloading".

## ES 2015, ES6, ES7

* The JS world kinda settled on ES6 syntax / ES2015 now. But JS-syntax is rapidly improving and many people use additional plugins for "babel" (see next point) to enable them to have, for example, class-properties.

* Most people use "babel" for transpilation from ES6 to code that browsers understand, webpack does all of this for you with "babel-loader".

## ESLINT

* "eslint" is generally used to format code and correct warnings. It is also installed by npm and run by a script in "package.json".

## React / Vue

* React brought back the virtues of functional programming to the web. If you use React, I'd recommend using it with the JSX syntax, which is enabled in the boilerplate by default. There is also vue.js, which seems to be better in various points. I don't like it because I prefer JSX, but it doesn't really matter for the beginning.

* Many people don't like react because it's too big. I wouldn't really care about that if you don't build for production now. There are a couple of improvements like tree-shaking (removal of unused code) that are around in the corner as well.

### State / reflux/ redux

* There is a war going on about how to best organise your code and your logic. There is "redux", but also stuff like "mobx". Just try anything you want for the beginning and see how your thoughts involve.

### CSS / SCSS / POSTCSS / SASS

* There is another war going on about how to do styling. There are various helpers like SCSS and SASS that provide improvements over CSS. These processors are usually run by "postcss" which, in turn, is also run by Webpack.There are also various CSS-frameworks and the possibility to just write your CSS inline with the React/Vue code you are producing.

I personally would recommend "tachyons.css", because you won't need any other framework, nor postCSS, nor SCSS anymore, but it's all your choice.

One of the problems that must be solved one a larger project is that you want to put your code in many small files,like put each class in it's own file (similar to how you would do it in other languages) , because you do not want to import each small file you need a tool that will merge them in one big file and for production maybe also minify it, also you will want source maps to be generated so you can debug your code. So to solve this problem in larger projects you need a tool, I am not familiar with all tools that exists to solve this, the project I am working one uses gulp (I did not made the choice so I did not done the research why gulp was the best solution then, and now something else may be better)

Other problem in big projects with jQuery is caused by the fact that data and UI are combined(what I mean is I often see data set as attributes on UI elements ,hidden fields with data in it), this can be solved if you use jQuerry better though, if your UI is not very dynamic I would continue generating it in server side but if you want something like an infinite scrolling list, or a very huge list then it is more smouth to implement it on client side and implement some tricks to have it work efficient(react would work better in this case then jquery and maybe you can find a good component that you can use),React is used for UI.

Some people compare angular1 with react, angular is a full framework it contains a lot more, like translations support, ajax support,routing , If you want my opinion here it is, angular templates vs react : reactis pure JS , you can use JSX and you should use it but have a look at the generated .js files, when I started I did not use jsx so I can learn better what actually happens. Angular templates feel to me as magic, there are no generated js files, the templates are compiled at runtime, I am sure eval is used too, in case of errors if you are lucky you get a printed stacktrace (not a real one)) if there are other errors you get a generic error message with a link to a generic solution and if you are not lucky nothing happens, no errors, no application loading. If you need to do something more complex you will have to get your hands dirty and have a look under the hood and maybe use the $compile. Also react can be used in existing jQuery projects, I have worked on such a project where we migrated some components to react and keep the rest using jQuery. If you like languages like C#, AS3,Java then I suggest trying TypeScript , TS works great with React.P.S. I am not a person that tries tools, frameworks and the latest shiny thing, I am working on web projects that were already started, so I seen what problems and what solutions we faced, until some of the solutions get standardized then there will be more alternatives, you will have to identify the problem in yourproject, then try to find the simplest solution for it and also try to not bet on the technology that is at the end of life(it is not easy)

I think the issue for me is their overwhelming lack of respect for their users during the Windows 10 "free upgrade" push. The heavy-handed GWX nagware push, the use of dark patterns like switching 'Install' and 'Cancel' buttons, repeated re-issues of the update which installs GWX. Then there was the telemetry built into Windows 10, which "could be turned off" but mysteriously kept re-enabling itself. Then pushing that telemetry into earlier versions of Windows via updates. Now rolling updates into monthly undocumented blobs.

To regain any kind of trust from me, they'd need to begin with a public apology for their approach, and a commitment to a far more open, accountable, and respectful approach in future towards their users' privacy and autonomy over their own systems.

The product itself doesn't matter here. The way it was marketed, distributed, developed matters. MS did some bad stuff on all fronts, regardless of which software was involved. IE, Windows, Office, consoles all had their bad days because someone decided to force or bundle software in questionable ways. On the other hand there were some amazing projects done by MS teams: Singularity, security research (https://www.microsoft.com/en-us/research/research-area/secur...), and many others.

I mean, it's still the same company. Just because they stop developing one of their products where most of their malice manifested, doesn't mean that they let go of the idea that doing these things was acceptable in the first place. So, I'd still be very much wary of their intentions.

[Shameless plug] We're one more option for preparation: http://interviewkickstart.com. We're a bootcamp, which continually tries to answer this very same question - where to start and how far to go, when it comes to preparing for technical interviews?

We usually remain booked very far out though. But if we can help you any time in the future, please feel free to reach out!

Google and Facebook are known for always using the same set of questions during phone screens. Just google for past experience and you'll be able to compile a good collection of questions you'll be asked.

If this is for your job (and you are not a consulant chaning client every week) then they probably stick with the same frameworks for a long time, so just get to know those and ignore the rest.

If it is for a side project just use whatever you find comfortable. You don't have to learn them all.

E.g. for a side project just use vanilla JS, script tags (not NPM, Webpack etc.) and maybe a view framework, maybe JQuery and that'll probably sort you out. Then focus on building stuff rather than learning new frameworks.

It helps to take a step back and see that the JS ecosystem is a bit crazy right now, but it is quickly becoming more sane and more mature.

For a long time, the tooling available for building complex JavaScript applications was limited. Unless you were Google; the Closure library and Closure Compiler provided tools for building large, complex JavaScript apps long before the current JS ecosystem got up to speed. But they were relatively difficult to learn, and the available documentation wasn't great.

Right now, the JS ecosystem is rapidly relearning and iterating on ideas and concepts that other language communities learned long ago. This isn't all bad, as the JS community does appear to be converging on a decent set of best practices. I've seen a lot of interested in code optimization, and reduction in the size of JS bundles sent across the wire to browsers. Rollup does a nice job here, and I've seen a renewed interest in the Closure Compiler - there's a Webpack plugin for it that does a good job of intergrating it into the JS build process.

I understand your frustration, though; if possible, maybe try not to worry about keeping up for now. Just use JS in a way that works for you, and in a year or two, check back in to see how things are going at the leading edge of the JS community. I can't say for sure, but I believe the pace of change will slow down a bit, and converge around a few major tools and frameworks.

Take a step back and focus on JavaScript the language. Really learn how things work. Then take a step even further back. Learn more about data structures, about abstractions and how to think declaratively vs. imperatively. Rinse and repeat for the rest of the stack.

That way you'll have a solid foundation to build on top of. At some point you'll start to see patterns, and that all the "new" things are just incrementally improved materializations of patterns and concepts that have existed since way before the web was even thought of.

Spend most of your learning/experimenting time on fundamentals (timeless). Learn actual implementations and specifics when you need to, just in time. Avoid learning specifics (lib/fw) just in case.

Source: My own personal experience + the very insightful experience of teaching classes in JavaScript and React the last two years.

Just ignore this JS nonsense until it consolidates. If you build something with it, pick a framework and use that. If you do not, why even bother?

Here's some truth.. if you're somewhat good with math, have a couple years of experience and have built real things, nobody is going to "not hire" you because you don't know the flavor of the month crap. Its going to change anyway. Because its flavor of the month crap.

Don't act as if you couldn't pick up react in a week if it was a job requirement, because that's how easy it is.

Spend your time on picking up a new paradigm. Never did functional programming? Learn some Elixir or Haskell. A lot more bang for your time than js framework #317 that is oh so much better than #316 until next month when there's another paradigm breaking framework that really just reduces syntax by a keyword.

since you've amassed so much JS experience, why not go into the stack, stop chasing the newest EMS standard and just put a product together using the MEAN stack?

time to settle, start earning, and slowly tweak/hone your skills.

edit; mind you, i see it all around me, how chasing the newest fad keeps many of my friends from doing anything. while me and my good ol` linux skills just picked up vagrant and will hopefully be doing DevOps stuffs. I use whatever i need to get jobs done - Bash? no problem! JS? sure thing. Php? Python? some ambiguous framework? give me a couple of days to read up and it's done.

to quote Voltaire; ""A good plan violently executed today is far and away better than a perfect plan next week.""

just be a problem solver, and use your know-how and ability to learn as a tool to fix/do things. chasing dragons is often detrimental to growth.

I don't think you can do it. Just pick what you actually work with, and try to stay up on that.

Someday, maybe, the churn will slow down. But I wouldn't bet on it. Just about the time JS settles down, WebAssembly will be finalized, and there will be a Cambrian explosion of new frameworks, as developers are freed from the shackles of JavaScript on the front-end and can use better languages. Once again, it will take years for a consensus on best practices to emerge, and a thousand flowers will bloom in the meantime.

In its entirety? No. Never go "full UML", it will annihilate productivity and produce abominable software. It also is taught wrong, it tends to be taught as a design tool, but there's such a tremendous impedence mismatch between the diagramming tools and the way the code actually gets written that it ends up doing more harm than good. (not to mention that the people who usually end up creating the UML might be many organizational layers away from the developers).

But there's some goodness in there. The principal of using diagramming as a descriptive documentation and communication solution is highly worthwhile, but again it should be limited to pieces of the system that need such things. And in addition, the level of detail should be just as much as is sufficient to communicate what's necessary -- don't "prematurely optimize" by trying to document every bit of the system in excruciating detail.

There's also often better, simpler ways to document many aspects of a system, a few boxes and arrows work well for many things. Lightweight versions of the Archimate style work well for describing complete systems. Protocols are well described by a lightweight treatment of sequence diagrams, etc.

They'll often go out of date as quickly as you make them, so keeping them up to date and well versioned turns into a challenge.

Because it's free and provides cross platform compatibility (and the diagrams are supposed to be communication devices), we tend to use yEd for most things.

The 3 actually useful diagrams that I have seen in the last 10 years are:

- Sequence

- Entity relationship

- State chart

All 3 are useful for communicating protocols, schemas and state charts.

Sequence diagrams are probably the most ubiquitous, and very useful in explaining protocols. Even RFC-s have them.

Relationship diagrams are often (ab)used to visualize relationships between tables in SQL databases. While it's not very useful for designing, I have actually used them for understanding and simplifying a complicated database schema.I actually believe every API documentation should start with an abstract entity relationship diagram. Abstract in the sense that it should not necessarily represent physical tables, but give an overview of the underlying structure to the first time user. Doesn't even have to complete or correct.

State charts are occasionally useful for obvious reasons. Try explaining TCP without one.

I think it's worth noting that the above 3 existed before UML and UML merely tried to formalize them, so while I don't think anyone uses "UML" anymore,being able to comprehend the above 3 charts is as basic of a skill as being able to read pseudo-code, and saying they are not is use would also be false.

"And there is an explicitly political idea that drove OOP to its peak in the 1990s: the idea of outsourcing. The idea of outsourcing software development rested on some assumptions about how software development should work, in particular the idea of the genius architect, backed by an army of morons who act as secretaries, taking dictation. OOP was the software equivalent of a trend that became common in manufacturing during the 1980s: design should stay in the USA while actual production should be sent to a 3rd World country. Working with UML diagrams, writing code could be reduced to mere grunt work, whereas the design of software could be handled by visionaries, possessed with epic imaginations, who could specify an OO hierarchy which could then be sent to India for a vast team to actually type out. And the teams in India (or Vietnam, or Romania, etc) were never trusted, they were assumed to be idiots, and so, for a moment, there was a strong market demand for a language that treated programmers like idiots, and so the stage was set for the emergence of Java. "

I use boxes-and-arrows sketches a lot. The UML which was so popular around 2000 was this detailed quasi-standard graphical language. It was very centred around being correct, and diagrams being of a specific type of a number of permissible types, and so on. And that whole part I never found to be too helpful.

It is useful to draw ideas as graphics for people who's brains are wired visually. And it can makes nice figures for books and articles explaining structures and concepts. But in neither case does the value predominantly depend on the depictions begin adherent to a standard, as much as other qualities, like focusing on the right part of a larger system, or leaving out unimportant detail, etc.

So nonstandard diagrams offer the author or user more creative flexibility, which is often very important.

I do see value in loosely following UML notation, for the obvious reason that one can immediately see if someone tries to show classes, states, requests, systems parts, and so on. That was probably the original goal behind UML all along, even if people lost sight of it during the fad phase.

UML can be a great communication tool in specific situations but when it becomes a religion your organization will suffer. I'm older than most here, drank the cool-aid that predicted code generation and round tripping but spit it back up before the poison had a chance to set in.

A bonus comment for the youngin's ... When you hear that some new system will allow "the common man" to write his own software without developers, smile and agree with them because they'll come back when it doesn't go as planned and you can charge a higher rate for the resulting expedited project.

EDIT:

I should also admit that I liked (like?) the idea of writing code using diagrams. In the '80s I wrote a program I called "Flo-Pro" in Turbo C that never quite became self-compiling. It wasn't at all OOPsish or FP. In the '90s I wrote several tools in Prograph [0] (now known as Marten) but was stymied by the fact that I was the only one in the company using the tool. In the early aughts, I tried URL tools that promised to write my code from the diagrams - it worked for very simple code but I never saw round-tripping work.

I love drawings in general - my coworkers joke that it's not a meeting unless I have a dry-erase marker in my hand. But those diagrams are invariably system-level, architectural drawings. As others have noted, I also appreciate ERD as a way to visualize relationships in RDBMS. So as much as I like the idea, development stays in the world of text - I'm not holding my breath for some magic bullet.

HackerNews may not be the best place to sample for UML usage. It consists mainly of two communities that have a bias against formal engineering methodologies in the development of software.

I won't comment on the pros and cons of UML. Instead I'll invite you to ask yourself a couple of questions.

1. What other clients do you support who have similar characteristics as this client (and may therefore also benefit from UML support)? If the number is significant in terms of impact to your bottom line versus the time you'd have to spend implementing it, then you should consider it worth your time, and view it as an opportunity to up-sell (if you can) or keep existing customers.

2. Do you intend to attempt to move into supporting large enterprise, and especially government contractors? If so, you might consider UML support just because it is ubiquitous there.

As a communication tool I've sold work with a really busy, boxy class diagram where the focus is on the connections and not a complete representation of all the properties.

Being able to stand in front of a big screen and point to and talk about connections and cardinalities magically draws questions and comments out from the business stakeholders. That feedback helps me get the model to a place where it generally matches what the business wants.

Keeping that diagram alive and updated as we implement the system has served as a super valuable tool for communication with other teams that need to touch the model. Everyone continuously hashes out and agrees on common terms, ownership, etc.

The worst defects come from requirements or design defects. I'm not advocating for giant up-front designs with hundred+ page software design spec docs. But, paraphrasing Uncle Bob, "'no up-front design' doesn't mean no design." There has to be some design of some sort and some documentation of the system being developed.

I think the time to stop diagramming/designing is when adding more detail won't communicate anything more about the model or business process in casual conversations about the system. That's a very subjective line to draw, but it helps me to think that way.

Originally it was mostly because it was the default setting in my Enterprise Architect tool, but it's proven more useful than Archimate (and other notations) because people without architect knowledge understands it much better.

On the business side it's mainly the system integrations, dependencies and information flows that are of value and you could honestly do them in Word if you wanted. Because it's very easy to build upon it, it's also easy to turn the business specs into something I can hand to an actual developer or use as a common language when talking features and requirements.

I wouldn't use UML if I was doing the systems engineering from requirement specs handed to me, and it is very rare that we use more than 10-25% of its full functionality, but it has enourmous value when you are trying to get future system owners to understand their own business processes and what they actually need from their IT.

Yes I do. When you have a team of developers with different model of how the system should work or works, it's usually a recipe for disaster. By modeling, we get to unify our thoughts and idea of the system.

When starting out a project, I tend to lean more towards well labeled conceptual diagrams. I will also use activity diagram, sequence and state diagrams.

While I have often read about people designing class diagram before hand, then writing or generating code. I never use class diagram before code is written. I use class diagram to document an existing system.

It's a tool, if you are willing to be flexible and realize it for what it is, then it's useful.

Back in the late 80's, there was the CASE (Computer-Aided Software Engineering) fad, when it was thought diagrams could replace code.

The idea that a picture is worth a thousand words is not applicable to most of the words one would use to discuss systems designs. It is very difficult to discuss purpose and intent, or to present arguments that the design satisfies requirements or observes constraints, to justify choices, and say how things work, through any sort of diagram, let alone only those of UML (use cases are something of an exception, as they are not actually diagrams.)

On the other hand, diagrams are a very useful adjunct to these activities, and are widely used in informal discussions. This is broadly in line with how diagrams and pictures are used in other technical and scholarly fields: for example, maps, statistical charts and pictures of places and artifacts are very useful in history articles, but are never the full story.

Furthermore, I can usually write a thousand words faster than I can draw the corresponding UML diagram. The UML I am most likely to use will be machine-generated from code and will be used as a supplement to the text I am writing.

If I have some other need (rare), then I improvise. Usually I'm the only one who looks at these, but if a client or someone else needs to, the language is simple enough to understand that I can explain it in a few examples/sentences.

Not exactly UML but I find rails-erd can be helpful to understand a data model, particularly if I'm trying to come up to speed on an existing codebase. It has the very large benefit of automatically staying in sync with the code.

"What's your favorite editor?" pales in comparison to the divisiveness inspired by "how do you feel about UML?"

I used Rational Rhapsody for a few years. We used it for use case diagrams, sequence diagrams, class diagrams, object model diagrams, statecharts+code generation.

Many folks scoff at and draw the line at code generation. By default, tools like Rhapsody seek to box you in to a certain way of doing things. It's not difficult at all to customize but it requires effort to opt out of some defaults. I felt like I experienced significant pros and cons. One one hand it was awkward to use their IDE to edit the code. OTOH it helped encourage a level of organization to the code. Statecharts are very expressive and very clear, I really liked them. There's no limit to the expressiveness of the code you can write. But the vocabulary used to describe the widgets I was working with was new to me, so it took a good deal of time to look up and understand the customizations required.

In the absence of code generation features of UML, the diagramming features are really great. Developers are too quick to treat it like a religion and (on both sides) become inspired to pray at the altar or preach about the evil that lies within. But really, it's just a glossary of visual representations mapped to software design concepts. That's all it needs to be -- conventions like the ones used in other engineering discipline's diagrams. Diagrams with "boxes and arrows" are just fine but there's always the implicit questions: "does that rectangle represent the process executing the 'flabtisticator executable' or the 'flabtisticator class'?

For a while I used UML but whenever I showed them to even experienced developers they didn't understand them. So I went back to simple box and arrows. Easier to understand and also easier to create and modify. Flow charts and state machine diagram usually work too.

I almost have a prejudice against people who use UML because a lot of them seem to be the "architect" types who talk about integration patterns and stuff but don't get much done.

Yes, but not in the formal sense. And i don't get why agile and proper documentation should not go Hand in Hand. There are components and class Diagramms that are invaluable for me when i'm joining an existing code base. Even if they are not up-to-date everytime.

State and sequence diagrams are really cool to discuss dynamic flows and identify potential logic holes. UML-like diagrams are way better then to come up with your own representation of this everytime

I do. UML class diagrams can help you turn real world business objects into model and think about dependencies and relationships of entities. I would say that it is the best tool to model software. Sequence and activity diagrams can help you design and document a process.

A picture is sometimes worth hundred words and this applies to UML as well.

IMO UML adds negative value because, with only a very few exceptions, its semantics are carried by shapes that have no mnemonic relation to the concepts they are intended to communicate. What is the difference between a dashed line and a thin vertical box in a sequence diagram? A hollow vs a filled diamond in a class diagram? Does:

C1 ---> C2

mean that C1 inherits from C2 or that C2 inherits from C1? Does:

C1 ---* C2

[Note: the * is supposed to be a filled-in black diamond, but HN apparently doesn't allow unicode characters in comments.]

mean that C1 contains instances of C2 or that C2 contains instances of C1? What would it mean if the diamond were hollow instead of filled? What is the difference between a solid and a dashed line in a class diagram? A sequence diagram?

The only way you can possibly know the answers to these questions is if you have mastered an enormous amount of trivia. And then what have you actually gained? How is a class diagram better than simply writing out as text, "Class C1 inherits from C2, C3 and C4, and contains single instances of C6, C6 a set of C7s, and an ordered list of C8s?"

In >90% of cases, the information conveyed by UML can be much more easily and effectively communicated by plain text.

For general purpose data modeling, I tend to favor some loose variant of Bachman or Chen notation. UML feels complicated to the point of being hard to read.

For architectural diagrams, I just use basic boxes, arrows, cans, etc. UML also tends to feel complicated to the point of being hard to read.

In both of the above cases, I think my not using UML is because its goals differ from mine. UML seeks to capture how a system comes together as completely an accurately as possible. I tend to think that the code should suffice for that (and if it doesn't, it's time to have a long hard talk about technical debt). I prefer diagrams to just be a gloss that helps to explain how things come together at a high level.

For understanding protocols and suchlike, though, UML sequence diagrams are my go-to. That's a rare spot where I really do want the diagram to capture a whole lot of fine detail, and the UML standard provides a pretty clear, intuitive and uncluttered visual language for the job.

Yes. It is the language designed for software engineers to share designs, logic and ideas with others. I never enjoy the scene that two engineers talk designs in front a white board by keep writing some random words they catched during talk and draw some wired line and cycles. The most painful part is that even they take a picture of it, they still have to argue about the ideas later when they start coding. :-(

UML is actually the first language a software developer should learn. The most ridiculous words I have heard is that a senior engineer "mentor" other juniors say the IBM Rose is UML! And argue about how Rose huge and hard to use.

I really worry if there still have some deciplines exist in software industry, if so many people still obsessed to call themself software engineer?

I do quite a lot. I use it for sketching out and documenting software. I use state machines for, well, state machines, which make up 90% of the software I write (embedded). They can almost mechanically be transformed to sourcecode, but I do the coding by hand. I use it for sequence diagram to sketch out and document sequences of events, and also generate sequence diagrams out of trace logs. And finally I use class diagrams to document the software architecture. For all of these I use plantuml because the text format is simple, human readable, and easily versioned. For the kind of software I write (embedded software with a lot of state machines and strong OO architecture), it is absolutely great. Definitely one of the big tools in my toolbox.

I don't and if you're religious about it, I'm afraid I don't want to work with you (I accept the feeling may be mutual)!

Most developers don't have a complete knowledge of it and don't enjoy writing it; essentially I believe it's because they know it's not an efficient way of communicating ideas with other developers.

Modelling can be useful, but as far as I can work out something like gliffy with lines, boxes and little else is almost always sufficient. I'd imagine safety critical space or aviation systems and other niches are a different kettle of fish.

Been working in a large corp for last 5 years. Never created a single UML chart, maybe I've seen one or two.

Maybe it's because I work in front-end, which "traditionally" is a bit less strict (JS is dynamically typed etc.), but also, I think that typically the codebase changes too rapidly and the fancy graphs can't catch up with that, they get outdated in a few months, and no one bothers to update them or even look at them anymore (they might be useful in the beginning of the project though).

Yes. Keep in mind though that the - perhaps historically, perhaps still - most widely used kind of UML diagram - the class diagram - is just one component of UML.

Other than for explaining particular design patterns I don't find class diagrams all that useful, certainly not for giving you a complete picture of a system that consists of more than a handful of classes.

Sequence diagrams, state diagrams, use case diagrams, basically anything that involves or describes activities: I think those are tremendously useful.

I used to write a lot of UML diagrams in Mechatronics Engineering for a big company, where specs were not supposed to change often.For projects with a long lifetime and a slow change velocity, UML is totally justified.

UML diagrams are not worth it for Software Engineering: code evolve too fast to keep your diagrams up to date.In that case, I replace UML diagrams by simple sketchs / mockups and simple tables.

I'm an extremely visual person so for me diagrams are incredibly useful. I'm constantly drawing class diagrams and communicating via pictures. I want UML to work so bad.

Unfortunately, I think UML suffers from all the dysfunctions of a language designed by many stakeholders. It's just not intuitive, so you have to remember the details. I start practically every handwaivy whiteboarding session with the disclosure "this is not UML but ...".

As with many "standards", we've sucked the oxygen out of the room by saying this is the one true way. I very much prefer having multiple competing specifications and letting the winner shake out. I imagine if we hadn't prematurely standardized on UML years ago, visual programming and diagramming would have evolved in exactly the same way regular programming languages have evolved. Why do I have 30+ choices for what to write my web server in, but only 1 seriously spec'ed out language for drawing it?

UML was useful for visually communicating document architectures in the Web 1.0 world. But what's a UML diagram for a dynamic web application? Server<-->Database, done? If the tool doesn't fit the problem, don't use it.

And then there's the domain specific UMLs, such as Operations Management and BPMN, where the diagram can be programmatically "powered up" to analyze operational efficiency. If you work in a hierarchical organization where you need deliverables that filter to other departments, and there is a perceived value, then someone is going to be tasked to make it. But in a flat organization in startup mode, it's a waste of money.

If you're working across organizations, in public/private partnerships; if your government organization needs to be accountable at diverse levels, then UML is visual language that communicates a lot of information at once--in one artifact. Tax dollars going for new transportation infrastructure in New York City, maybe there's a need to get diverse groups on board. But you're going to pave potholes in Levittown, NY--who cares? Get it done; stop wasting money.

And finally, there is a the language-cultural dimension. Europe is multi-lingual, so it's no surprise the Open-Education Resources offering UML-like education materials are from European universities [1][2], and not American Universities. That's not our language problem (yet).

If you have a customer asking for UML, you need to understand their problems. Once you do that, then you can decide if the problem vector they present is profitable sector for your company.

To put all this in other words, UML is a tool and a visual language. Use it or not, it's not going away--ever.

There was a recent talk about the model-code gap [1]. How diagrams often don't map to the code. The C4 model. "Structurizr." Lack of common abstractions to describe software, in contrast with other fields like electrical engineering. Good to still start out with paper/whiteboard.

@7:13 "1 out of 10 people use UML," in his experience. People adopt ad hoc notations instead.

I'll often use sequence diagrams or entity relationship diagrams when I need to explain how a piece of code works (or even just visualize it for myself). I don't tend to be very pedantically correct about it, but having a picture makes it a lot easier to follow how different pieces fit together. I generally leave out a lot of the less important details when doing this.

I wouldn't generally use it to design code that hadn't been written yet. There's a lot you only discover once you get something working, and that needs to inform the design.

UML use case, activity, and sequence diagrams are perhaps quite useful. I'm too lazy to make them :-) but I find them useful to consult at times.

The class diagrams that everyone is really thinking about when they say "UML" are imho kind of useless. It reflects a kind of obsessive OO purism, and taxonomical obsession, that was quite trendy in the late 90s, early 2000s.

But it turns out in most cases looking at a class diagram doesn't really tell you much about what software does or how it works. And in any case I personally find it easier to look at header files or source files to get a picture of how things fit together. Class diagrams don't really help.

I sometimes create UML diagrams but I try to simplify them as much as possible. Sequence and Entity relationship diagrams are useful but the rest is rubbish IMHO. I tend to use them only when I'm in the planning phase but I ditch them when they become obsolete and the application is ready. This might not be the best workflow but updating diagrams is horrible. You also can't really use UML for functional languages like Clojure. I feel that they are becoming more obsolete with each passing year.

I draw UML diagrams frequently. I almost never persist them, though. As they say, the only thing worse than no documentation is out of date documentation.

I can definitely see an argument for certain types of projects (libraries and frameworks). If you have diagramming capability, and you are in the enterprise Windows market, I think this is a no-brainer. I'd be curious what diagramming support you had if it were not UML....

Having said that, I wouldn't try to implement a full object modelling solution. It's not the kind of thing that help files need. Actor diagrams and sequence diagrams would make more sense to me.

I like how UML class diagrams defines the different potential relations between objects involved in software.

It would be nice if more people (myself included) learned better ways to consistently communicate software design. Lots of ad-hoc meetings result in confusion because often a design is scribbled in ones own notation then communication takes longer. But yet such communication is crucial to large projects.

Some call it architecture, others call it design patterns. Either way its important to have thought-out, standard ways to communicate ideas.

UML diagrams are practical, but there's a cost to creating them and maintaining them. You can argue that many tools have been created to address this problem, but the problem remains... especially maintaining them.

Now, sequence diagrams remain one of the best ways of explaining distributed workflows (e.g: OAuth) that I know of. If you work with an OOP language, a class diagram might be useful to express some ideas. Other UML diagrams are less used.

I'm really lazy when it comes to maintaining docs and mainaining UML is sometimes a pain so I only use dynamic parts of UML like sequence diagrams on a relatively generic level that is less likely to change (examples of call flow between modules/tiers with different responsibilities).

Class diagrams are pretty nice when building a rich domain model since it's pretty easy to move from rough conceptual level closer to designing and documenting the actual implementation while working on the same diagram over time.

Probably it is not. I think I'm late enough that I missed the UML wave, and I also did well enough on the AP CS test that I tested out of the CS 101 Java course in college, and got thrown into the Haskell one instead, so I was never forced to do UML.

Once in a while I'll fire up Visio and sketch out a state machine or sequence diagram, but all I'm really doing is throwing down some bubbles or rectangles, drawing some arrows between them, and tacking on some labels. It's nowhere near as formalized as UML, but it works well enough.

No, and yes. I, and my last few places I worked all use sequence diagrams, especially when dealing with a new feature with a microservices based architecture (private and gov clients).But very basic usage. I do spend a lot of time tinkering with diagrams in http://www.websequencediagrams.com both for work and hobby projects.

I use sequence and communication diagrams, but I find the other diagramming techniques less applicable to the type of work I do. In the systems I work with most problems arise from transitions between states and from communication issues between isolated units. I find that static models just end up having to change rapidly throughout the implementation, so I focus on creating APIs and tests instead.

In recent times, about on the same level as ERDs for databases. So mostly as a quick top-level sketch when designing something (mostly on paper), not really kept up to date when the code/model changes. Goes along with getting away from rigid class models in general, and for UI classes, the relationships are a bit more self-evident.

I don't use UML, nor its predecessors going back to the early 1980's. I draw little pictures to ensure I understand what my code is/will do but that's it. Formal diagrams are as useful as formal documentation written wearing a formal suit.

Web of Trust is a browser extension that claims 140 million installs. The marketing language on the home page [1] is all about how the extension will help users decide which websites to trust.

Their privacy statement [2] includes a section that describes "Browsing usage, including visited web pages, clickstream data or web address accessed;" as one of the categories of "non-personal information" that they may disclose or share with 3rd parties.

I'd imagine most users installing an extension to make their browsing safer would not be happy to know they were also making their entire browsing history available to 3rd party data brokers at the same time.

Unscrupulous business practices are definitely made easier when no one actually reads Privacy Policies...

Here is the blog entry of the Journalist Mike Kuketz, explaining in detail how he uncovered the fraud, unfortunately only in German. This includes samples of the questionable GET and POST Requests, as well as a link to a commit to the WOT sources on GitHub, which introduced the necessary changes ...

I wanted to say: And Google did not removed it. But actually it is also gone in Google extension store. Google also seriously needs to think about security in their Chrome extension store. I've seen more than once ads injected by extensions by the auto update (no real security there). Maybe I've been also tracked in the past. Google needs to actively monitor all extensions for ad injection and tracking code (where are their AI experts on that?) and also it should react faster to reports. In the past, weeks and months go by before a report has consequences for a extension. So the discovery of WOT is only thanks to German reporters.... but it was longer known that WOT tracks you.

What's interesting is how the story completely failed to make the news in the English-speaking net for several days. The story broke on Tuesday (CET), outside Germany it was only picked up by ghacks until now...

I came to the conclusion that one should use only addons which are widely used by netsec experts, because audit is a fairly rare thing these days and one has to rely on when somebody sees something suspicious.

Good riddance, a vile site full of self appointed internet police with handpainted badges with a sense of importance

They falsely flagged a a website I ran a while back (social media management tools via approved APIs) as: pharmacy, scam and spam. Due to this mails from our server were not getting through.

I tried contacting saying they are all false. They updated saying we sold facebook likes and fake followers. We did nothing of the sort and did nothing at all with facebook anyways. I tried contacting again to which I was told we were a scam because the domain has privacy enabled nor had my personal name and address on the site. I value my privacy and do not have my full name and certainly not my address anywhere online.

I asked our customers via a support forum post if they could post an honest review of our site and service which did nothing to the score - it seems a couple of users have all the power. We then got branded as spammers for trying to manipulate our rating (with actual reviews, but as it was against the power users (who had never used our product) we were in the wrong.

This is more or less the same way SimilarWeb collects its data, so I wonder when will they start being treated the same. They operate a number of inhouse extensions and partner with other extension developers to collect the entire click trail of the users. Internal links in your intranet, localhost, "private" google drive links, all is collected and sold. It's beyond me how this shady business is treated as legitimate, including major web and tech publications citing their data reports.

It also really helps that Firefox never deletes cookies by default and never tells you about this. We 'respect' your privacy, yes, we do! Really! Look, you will have only one google cookie when you start a very new firefox.

We really respect your privacy, yes! We will reiterate that until you believe it, but never change our privacy destroying default settings, because we 'respect' you!

Those stories about Adblockers selling browsing history and private data, is just a lame intent to make people stop using adblockers and make us digest all that advertising crap.... Watch an ad is our choice....

on android i used to go pretty extreme and edit hosts file on a rooted phone. you can find maintained lists for it they just zero out the address. for security i would also make all the edits i wanted for different things and then unroot.

for firefox there is also script blocker with the ability to white list adresses also remove history on close.

I've studied Elon Musk pretty closely, and have tried to find others that are similar, but I'm not aware of anyone, at least English-speaking.

The thing that really sets him apart, in my opinion, and something that a lot of people don't fully appreciate - is that he is the lead engineer / chief designer at Tesla and SpaceX.

So, you basically have in one person, someone who is both able to grow a multi-billion dollar company, while also leading the design and engineering of the products. It's very rare to find an individual with this type of skill running such a large company. For example, the CEOs of SpaceX and Tesla's competitors cannot really delve too deep into the engineering details.

If that were it, Elon would still be impressive, but he goes way further than this.

He is not only running one multi-billion dollar company, but two simultaneously. (You can almost say he is running 4 multi-billion dollar companies simultaneously if you include Solar City, and if you see the Gigafactory as a separate entity, not to mention he also oversees Open AI, which is very impressive by itself (he says he spends one day a week on it).

If that were it, Elon would be in a league of his own already, but what makes it even more impressive is that the companies he runs are both in very complex industries, and he is revolutionizing both industries.

Alphabet (Larry Page and Sergey Brin) is doing a lot of things. From what I understand they're the most advanced when it comes to ML and self driving technology. They tend not to ship so they don't get much credit.

Jeff Bezos is in many markets as well though he seems more focused on making money than directing the course of humanity.

All in all I'd say Google has had a much bigger impact on our lives than either Amazon or Tesla / SpaceX has had thus far.

Start with a pendrive / USB boot and try different distro. Try both older and newer debian-based distros like mint or ubuntu which usually have better laptop support than vanilla debian to see if you can narrow down the problem.

But the problem with all these approaches, is the arms race problem. These solutions take developer time, and they can affect end-users. The army of scrapers can easily undo your efforts in short order making alot of these approaches an effort in futility.

It is happening. You can not stop it, only slow it down to the "human" pace. Any scraper performing actions with a browser (be it headless or with head) in a human pace can not be detected. Every human action (on a webpage) can be simulated so any data accessable by a browser (be it behind a login or not) can be retrieved. Certain captchas are also hard to crack but that is about all you can do: rate limiting and captchas.

You can put up ToS all you want. I'm not agreeing to your terms by visiting your website (I'm not even visiting the site, my scraper is. Can a scraper sign a contract? I doubt it). Maybe law is f'd up like that in the US. Is it? Fine, I'll buy servers in Russia. Or some banana republic. Come sue me in the wonderful state of Nevis and see how that goes.

You can do a lot to prevent it. The best way to prevent it is to not have valuable data. The more valuable your data, the more effort we will spend on cracking your countermeasures and we will always win because this is our core business - to you its just a cost center.

Linkedin is one of the most notorious sites for trying to prevent scraping and they certainly have the funds. Yet they can't do shit about it and you'd think that they have it easy because they hide everything behind a paywall. Yet they can't prevent it from happening. Not even close. If they can't do it, you probably can't either.

And that's the really boring part. Do you know how many blank APIs there are in the web? People do their node.js and their frontend SPA bs and then they just dangle an API that is open for the world to scan. I could make a business out of scanning for exposed user data and feed them into a lawyer doing class-action lawsuits all day. Would be easy. Like really easy. So-called "engineers" need to learn how cryptography works. Or just reject unauthorized requests. Its really not that difficult.

To call out one prominent example: The Tinder API has been exposed ca. 2012 and ever since then, they didn't give enough of a shit to secure it. You can still build a tinder 3rd party app using their api.

I've been building a startup for the last six months or so, and a big part of our research is understanding agents (US only, so far).

I'm not sure if the copy on your landing page reflects your overall marketing strategy, but in my experience, most agents are less interested in products that solve pain points (eg, complex website setup processes), and more interested in products that give them an edge, highlight their personal brand, etc. I've learned a lot about this topic from reading industry news, like 'Inman Select'

Of course I don't mean to suggest that a traction problem can be solved solely with adjustments to copy, but branding, etc, is the lingua franca of the agent community, so even slight miscalibrations could significantly affect adoption.

As to the open sourcing, I personally wouldn't, at least not in a fashion that requires lots of your effort to upkeep. The market is so competitive, I have trouble imagining adoption of an open source kit would be wide enough to justify your effort /sacrificing your IP.

What about other distribution channels? There are a number of sites that act as realtor back-end DBs/CMS. Is it feasible to partner with one of those and serve as the official Wysiwyg of such-and-such MLS/Database?

Would love to learn more about your experiences here, btw, if you're up for a chat--brandon@wayhome.io. It's a difficult and fickle market to serve, so I empathize.

Before you throw in the towel, let me give you some things to think about. So I am not directly answering your question of whether you should open source the product or not.

Real estate markets are very local. Are you targeting agents in the UK and Spain ? I am guessing based on the currency/language switcher on top.

In the US, I can tell you that the market is huge but quite competitive. Not sure about UK and Spain but it could be. Have you done some market research and validation before you started building this ? Have you not been able to get a single client yet ? Have you reached out to an agent personally just to get some perspective ?

If I was you, first thing I will do is to ask myself : Why am I building this product. Is there a potential market for this ? If yes, how big ? Are there existing competitors ? If yes, that is usually a good sign that there is some validation but you may have to compete. You also spend a lot of time doing marketing and primarily "inbound". Take this free course from hubspot

Learn from your competitors. Go to Google and type "real estate website templates" etc. See what comes up in your local google search. Study those companies and how they are doing business. Get inspired.

Now, some feedback on your landing page. It doesn't tell me anything on what I get as a real estate agent. Saying "build website" in 2016 is as good as saying nothing. So you need to be more specific on the landing page. For example, in the US, real estate agents use something like MLS for listings. It is some type of agreed upon database (pretty shitty though) they they all subscribe to. So do you provide integration with any MLS if there is an equivalent in UK/Spain ? Real estate agents are not necessarily looking for a website. If at all, they want solutions that can get them more leads and eventually clients. What does it take for real estate agents to get more leads/clients ? Figure that out and you can make tons of money.

Thought I'd throw in my 2 cents since I also explored the real estate market in Canada:

Competition is tough here and I had a chat with a few real estate agents. Many of them told me it's a local market and that they get found through local ads or referrals from clients. Their websites are also suffering from bad SEO - one agent told me that there are other websites taking his properties and are ranked higher on Google than his own website.

The #1 thing real estate agents cared about the most, according to my discussions, was leads. The only thing that they wanted to pay me for was leads.

And as many other people said, real estate agents are busy people and may not have the time to build their own website. Their job is to sell houses and will gladly pay to have someone else set everything up for them - you might want to think about other stakeholders you can partner with (i.e. marketing consultants) that can help you onboard real estate agents.

I think you have to identify what problem you are trying to solve. Your site essentially charges by the number of properties which presumes there is value in them building a site with just their properties.

Do real estate agents have a problem listing their properties?

In the U.S., there are a number of property listing sites and, presumably, there is value in seeing listings from multiple realtors, not just one.

So...

Is your site really solving a problem that realtors are trying to solve?

From what I remember he discovered that Restaurants wouldn't take the time to even setup their sites in the awesome builder they took so much time creating. They found they had to setup the sites for them, then charge monthly for hosting/maint/etc.

You could probably follow a similar playbook.

With realtors you should probably look for realtor companies that have 50 or 100+ agents and try to get the company signed up on an agency/company plan where all their agents would use your system. So you'd want to raise your rates for those, and have a setup fee for each one to cover the time of hiring someone to set them up.

Maybe provide a subdomain pointed at your server.

properties.bigrealtorcompany.com

Ideally you would get connected with reality offices where you are adding properties, allowing them to mark them as sold, adjust price, text, swap out images, announce open houses, make featured in the listings and you adding new ones so you get in a nice revenue cycle of $XX per add, and have a nice agency monthly fee on top of that.

We would love to hear from you. If you have any comments or queries, please leave us a message.

Both of those things signal that you are desperate for attention. You need to hit a note of being available for the needs of your customers, but not sitting around twiddling your thumbs, hoping against hope for the phone to ring.

Perhaps something like "For your convenience, you can leave us a message via this form any time of the day or night. We will get back to you as soon as we can."

You also need to change how you talk to your customers. You want to describe the features of your product in a way that makes it clear what the tangible benefits are. This usually does not come from giving "specs." You need to make that info available too, but that cannot be your primary means for explaining your value position.

I found it by reading the Wikipedia's article on map-territory relation, which I came to know by reading a blog post about Cyberpunk on RibbonFarm. I'm having a blast. The book is a collection of essays in many matters, including anthropology, biology, psychology and others.

- Learn React(complete the video courses I've started), and use it to build the project I have in mind(discovery platform for webdev learning resources).

- Keep making progress at my fiction/comedy writing. I've been struggling with it for a long time, but I've had a few epiphanies recently, and I want to finally make it work. The goal is as always - learn to competently craft my short funny science fiction stories.

But before any of that happens, I have to take a break, cut out the caffeine, and go through several days of withdrawal. It will be miserable, but I really have to make my body rest, sleep, and recharge. I can't keep taking more and more stimulants, it's not working anymore.

Find a better place to work. Just started as a software engineer, fresh out of college. I come home and I am constantly learning, which I enjoy, go to work and introduce new ideas and am shot idea not because of my ideas but beucasue im a newbie. Over the past couple of month has eatten away at my confidence and starting to just blow it off. :(

I've been making a Django app for over a week because I wanted to learn doing web dev. I hope to finish it another 2-3 weeks. So far, it's been a intimidating and yet fantastic experience learning about django, http, html dom, js, jquery, css, bootstrap, sqlite, orm, templates and such.

Stand a project up, running on autopilot, which will make a minimum of $5k/month profit, 100% on my own without the need for any major expense other than time/effort plus simple and cost effective infrastructure.

I would compete on some crazy competition like MIT's battlecode (which usually is a month long event) ! I have worked several years, but none has given me the challenge/satisfaction of programming an AI Bot and compete with similar folks

I would work on the job board site that I have been dreaming about for months. As soon as I'm done with the exams I will go to work on that site. Target : launching MVP by the end of first week of December.

Ugh, regardless of what we say we wish to do on this post, what I'm sure many of us lack is external motivation to do it. One app to help solve that is called Spar, developed by a friend of a friend (https://itunes.apple.com/us/app/spar!-get-better-at-stuff/id...). You set a goal with your friends, e.g. read a chapter every day, and put 20$ or so in the "pot". Whoever does the best at meeting the goal, gets the pot, and if you slack on your goal you lose the money.

Ye old "LAMP" stack (Linux, Apache, MySQL, PHP) is pretty boring, and widely used. Very stable, very performant (and lots of options for caching / indexing / tweaking code when you encounter bottlenecks). Lots of competition in the hosting space as well, and you're not locked into any one company's flavor of "cloud computing platform".

I recently did a project where I wrote the same API in Ruby/Sinatra, Node/Express and PHP/Slim; Connected it to S3, GCloud and Azure for assets and MongoDb for data; and then deployed each permutation to Heroku, Azure, App Engine and EB.

For "under the api barrier", Heroku was the only one that ran everything smoothly; S3 is the easiest to interact with, and as I worked through the project, I switched from Ruby to Node as the prefered platform.

For "over the api barrier", where users actually use the project, it depends on the project requirements. In this case no dependancies was a hard requirement, hence Vanilla JS. But if you have a lot of UI, you'd need a lib for both JS and CSS and it depends on teammates pref, organization pref and legacy.

Server side rendered HTML, simple forms with POST redirects. Little to no CSS or Javascript. Pick your back-end of choice: Java Spring, Python Django, Common Lisp (wink wink). Use a well known SQL server for persistence. Might be boring, but there are still a lot of cases where this is actually desirable, and it's insanely performant.

ASP.NET MVC5 C# + Angular 1, because that's what we do at work and what I'm currently most familiar with. It's a pretty solid way to go if you don't mind Microsoft technologies, either. Although ASP.NET Core is probably more future-proof.

Pick anything that's still heavily used today, that has been around for 10+ years, and it's hard to go wrong.

The only caveat to this is on the front-end JS side of things. jQuery is still solid, but the language and ecosystem has been so not great over the last decade that something a bit newer might be worth looking at (maybe look at 3-5 year old libs/frameworks instead).

In the enterprise world, a boring stack is usually Java 7, 8 if you're adventurous, with Spring as the backing framework, running on a Tomcat server, talking to a SQL database (Mysql, Postgres, Oracle) through a Hibernate layer.

None of these are really great technologies, but they work, have infinite documentation, and it's easy to find people who know them.

Javascript - either no Javascript, or very simple vanilla Javascript. No transpiling, no Typescript, no JSX, no ES2015.

CSS - Regular ol' CSS. Set a limit on number of lines of CSS you're willing to introduce per controller action and try and keep your project honest to that number. Avoid frameworks if possible, pick a simple framework for grid layout if you really need it.

Is picking a a "boring" for the sake of "boring" stack really all that sensible? How about we choose things because of tangible reasons, like test coverage, infrastructural/operational simplicity, availability of development resources, industry/enterprise adoption. IMHO these are the things that make sense when choosing a framework/language. Choosing something just because it's old and boring is illogical.

PHP with some template library. Pretty much gets the jobs done and stays out of your way. RainTPL[0] is the best template engine I've ever used since it is just so simple to understand what's going on.

Cheapest method:Assume the government really want this number, they can have all mailman help keep track if there are leftover mail(a letter is created/given if resident has no mail) after x days.

Technology wise, I cannot think of an easy and cheap way. Camera with vision for each residential door will be a robust approach. Accuracy can be precise by more investment in software from detecting opening-of-door-event to facial recognition of the expected household members.

I worked for a utility and this was an important problem for us as a customer would close their account and move out of a rental and another tenant may move in and start using gas without having an account with one of the utilities (we don't lock meters on moves, this would be too expensive.) The utility company only finds out something is using gas when a meter is read every few months (we had a threshold.) Here is when we contact the tenant and try to figure out whats going on, unfortunately we don't have phone numbers and sending someone around to check was too costly at the time.

You could feature extraction per target home. I wonder if you could use neighbors' information to have better posterior beliefs about the home in question.. Like, suppose Alice lives in the house you're trying to decide, and Bob, Cathy, ... Yvonne, and Zara are all benign 'adversaries' that are willing to help you learn about Alice's occupancy. Is there some kind of utility/wiring/plumbing/logical singleton shared across the whole neighborhood, which could be used for deductive purposes.

Personally, I'm kind of amused by the appalled and horrified tech bloggers I see posting about the sky falling. I keep reading about "life long" Apple users threatening to switch ecosystems because of an SD card slot. Or function keys. I mean, people must step through A LOT OF CODE to have that impact this kind of decision.

My perspective is biased by my moving in the opposite direction. I'm just in the process of considering a transition TO Apple after being a lifelong windows user. My current build is a top of the line XPS 15 (2015). It's... disappointing. The touchpad already broke. I went through at least 3 warranty visits before the wifi finally worked halfway decent. Windows is becoming less and less what I want it to be. I use it purely for coding, but when I do jump online for a few minutes it manages to be slower than my ipad. Basically, I want a simple, fast, productivity OS that just works (sorry). I don't want it to show me ads and I'm beyond the point where I derive any satisfaction whatsoever from tinkering or configuring it to be perfect. I just want it to work well and work consistently.

Although consensus seems to be that their software is getting worse, from what I see it feels like Apple is the one making the devices that can accomplish what I'm looking for - and a big part of that is the hardware. Still, I'm interested to hear what people say about elementary OS.

My personal laptop is a 2010 MBP. I was waiting to replace it until, well, I saw the new one. Now, I'm really undecided.

I'm planning on borrowing a laptop to run Debian on and see how much my workflow changes. I spend a lot of time in vim and the terminal in general, connected to mostly Linux machines, so in that sense, at least system directories will be more similar.

Things I know I'll miss: excellent hardware, Omnifocus, Omnioutliner, 1password, a windowing system designed by people with actual functional aesthetic sensibilities. And I'll have to figure out an alternate phone backup, because I won't use cloud backup and dislike Android (not enough to be unwilling to use it, but enough that re-purchasing software to use it is really unappealing).

Things I won't miss: watching Apple turn excellent general purpose machines into appliances that don't respect the user's desires, being asked to pay ~$200 and my escape key muscle-memory for an goofy emoji toolbar, and every release coming with 5 more inscrutable daemons that want make connections to seemingly random hosts at seemingly random times, which my machines are not allowed to do.

Actually, just the act of writing this out made me firm up my conclusion; I'm no longer in Apple's target market. So no, I won't be purchasing the new MBP. Better to start migrating now and I'll worry about the phone conundrum later.

As far as the actual question, if I'm using Linux at home, I'll ask for a Linux laptop for work. I'd rather not waste time keeping current on OS X if that isn't what I use when not at work.

I'll paste a comment I wrote earlier under a different, less relevant thread:

As a convert who used to be an ardent Android supporter, I've learned a very important lesson after switching. It's not always about the numbers. In fact it's never about the numbers. You can't quantify sheer quality. You can't quantify how something makes you feel. I understand this can be easily retorted by "Well I get that feel from my Samsung Galaxy N, it's totally subjective", but I think that's just being dishonest. I've seen people mention that they're considering switching back to Android after the headphone jack thing, or switching to a PC laptop after the touchbar thing. For me simply touching the surface of ANY premium laptop currently on the market is enough to realize that Apple is light years ahead in terms of how they engineer their devices to feel. Simple things like opening a lid. Using the trackpad. The force touch. How the ringer switch clicks into place. All of it screams "quality". Not like 15% higher quality, but like light years higher quality. It's my experience anyway. It's like -- yes you can take the best mechanical Breitling and ask what does it do that the average Casio ProTrek does not? And there may be not a good answer for that in terms of numbers. But just take both in your hands, and try to objectively say -- which device you intuitively want to interact with more? Which one attracts you with some inexplicable magic? Which one your fingers are craving to touch and understand? Imagine having that feeling every day with a daily device. Imagine having that feeling as the norm. How could you opt in for something less, despite the numbers?

No, and perhaps that is why I and many others continue to be somewhat disquieted with Apple's stewardship of its Mac platform: It would take much more to make me switch. Apple would have to treat its professional users much worse than they do today.

The corollary to this being, it could get much worse. The best parallel I can draw, if you'll permit a terrible political analogy, might be idealistic Bernie supporters slowly realizing they're going to end up with a choice between Clinton and Trump.

No, not laptops. I do run a few hackintosh desktops though. Macbooks are still the best (unless you are a heavy gamer). Over the years of having used a variety of machines, I haven't found anything close.

Build/Reliability: Probably more reliable than my IBM-era thinkpads. Excellent build quality, NVME, good battery life, slim aluminum frame, and one of the better notebook displays with retina. Trackpad is the best in the industry period, no one has anything as good or responsive.

Support: Very big support network. I can walk into a store and get a loaner, fix, or a brand new machine. If you don't have your own IT department this is a huge value to your startup/small business.

OS: If you want to develop for iOS there really isn't an option, so that's not a fair comparison. However, Apple supports practically every professional level software suites (Adobe, FCP, etc). OS X is also certified Unix with a polished ui and has pretty good compatibility with most of Linux/GNU with homebrew.

With so much changing, old "lock-in" factors don't really apply. New power cord. New monitor adapters. I think the switching cost feels like getting a different brand already, so it's natural to investigate alternatives

Plus, I would like more memory. 32 gigs specifically. My dev environment plus all of these electron apps like slack are filling up 16 gigs fairly consistently.

I did and I am happy that I have, I prefer the linux machines, though to be honest it does not matter all that much. The terminal is great (on both system) and most of what I do I can do from within my IDE (IntelliJ) which also runs great on both systems.

I don't use computers a lot apart from when I am working, and for the leisurely things I do it does not matter which OS I am using, as everything runs in a browser nowadays. https://imgs.xkcd.com/comics/mac_pc.png

I'll take the current MacBook Pro, if it's maxed out on RAM and has enough SSD. But that's for work, not personal use.

For personal use, since my current MacBook Pro is already maxed out on RAM and SSD, I'll most likely wait until 2017 before I seriously consider upgrading. There just wouldn't be enough bang for the mega bucks.

Went to a Microsoft store to buy a Surface Book. They are very expensive and have roughly same specs as a MacBook Pro. I really like the look and feel of the Surface Book and I was hoping it would replace my MacBook Pro + iPad Pro. I'm still mulling over the purchase since the keyboard froze up when I was checking it out and it reminded me why I went to Macs 10 years ago.

For me it doesn't seem like there's really any difference between different laptops. I'm on a 15" MacBook Pro at the moment because I needed a Mac to work on an iOS project, but now I use it to code financial stuff.

Everything I do is on remote connections of one sort or another, and OSX has a simple way to swap out one virtual desktop with another. Everything that requires real computing power I do on a cloud, and everything else I think would work fine on any reasonable machine.

I'm sure a windows/linux system could do the same as my MBP, and in terms of work it wouldn't really matter as we use windows and linux together. I think more or less any laptop in the price range would be able to drive multiple screens, and it's really just a question of minor things like whether keyboard/trackpad feels nice.

So it is a bit of a hair thin decision. If this whole no-ESC no-Fkey thing seems to go badly for other devs, I won't get another Mac. I need F keys to step through a debug, and it's annoying to change key bindings.

I have a 2009 MBP that I use at home. Still does a great job for what I need and I'll do some iOS development on it.

Newer computer is a Lenovo Flex 3 with Win 10 I got for under $500. I've been on a MB/MBP for almost 10 years now at various jobs. If I really need a MBP I use that. I don't see myself buying any more apple products though (including phones/ipads).

I will choose the non-Apple laptop, because I already have a late 2013 rMBP, which still runs fine and I find in many ways superior to the new MBP.

Hopefully it will be a Dell XPS 15"or Lenovo ThinkPad P50, as I just can't stand working with any screen smaller than 15". And then I'll dual boot Windows + Linux or even triple boot Windows + Linux + *BSD.

On a 4 yo Retina and couldn't be happier. I'd be paying to upgrade a fraction of a Ghz. It's Intel's fault not Apple's, but still don't see the need I did 4 years ago.

I've been using my laptop a bunch in my bed though, the Surface Book is detachable, and a Razer Core could give me multiple monitors when I need it.

It's probably going to be a year before another Apple innovation, and at this point the only thing holding me back from switching is the feeling that these other options have some sort of catch. Instability that will make me throw it out a window, or being ignored by the largely Apple development community.

The LinkedIn/Slack stuff is nice, but Microsoft should just invest hundreds of millions on improving Windows dev projects like VSCode.

I would choose the new MBP. Mostly to try out the Touch Bar. I'm intrigued by the possibilities of a context-specific, programmable function key area. Will it be useful? Will it be an annoyance?

Different users have different goals and pain points. More than anything I want a computer that fades into the background. I want to get work done using computer. I don't want to work on the computer itself. I don't want to tinker with esoteric configurations in Ubuntu. Or troubleshoot OEM driver issues in Windows (or wait for Windows to install updates on boot).

I have recently tried to connect my old iPhone5 to my very old MacBook with Snow Leopard, and I could not open the phone to transfer some photos. I connected the phone to PC and got access to the catalogue righ away. I'm litterally pissed of at Apple and the next time I buy a computer I want to be in full control of what is going on. (having said that both the laptop and the phone work quite well despite their age).

No. I own a 2015 15" MacBook Pro, fully loaded except for only 512 SSD. I'll wait for the next refresh when, hopefully, they'll have Kabylake, 32 GB of LPDDR4, and maybe they will have rethought the SD card slot. By that time developers will have figured out what to do with the Touch Bar and knowing Apple they will have sorted out any hardware problems.

I really wanted to upgrade. Every announcement Apple has I am the guy in the take-my-money meme.

They just didn't do it this time. Between the 16GB limit, the lack of ports, no magsafe, and removing the function keys that I actually use quite a lot.

32GB haters: I'm currently migrating a huge database from mongo to postgres and I run docker containers in development.Function key haters: Yes, I actually use them and every time I've bought something where virtual buttons replace physical ones it's been worse, at least in the first few generations."Just get a dongle" haters: I know, they make usb-c everything, but my current set of MacBooks don't require me to carry anything but my Thunderbolt 2 ethernet adapter and at $80 I guard it with my life.

What I'm planning to do, though, is starting to use Linux on a VM on my MBP at home, get used to it, then get a dedicated Linux machine at home, then perhaps when my MBP is old i will keep the Linux as a machine for working, and will get myself a Mac Mini / iPad for generic home use by the whole family.

I bought a pixel, coming in a week or so. Can't wait. Glad to be able to listen to music and charge my phone at the same time, glad to ditch itunes and its increasingly aggressive efforts to ruin my music listening experience, etc.

Also just had my company buy me a new macbook pro because I need it, but didn't buy my own (which I'd usually prefer) because I'm keeping my options open.

I won't be switching yet, because all my Apple kit is <2 years old. Barring some sort of disaster, I'll have it for another couple years at least.

But they're definitely on watch, as far as I'm concerned. It's not just that I'm disappointed by the new hardware. It's that their software - the real thing that got me to switch to Apple in the first place - is getting increasingly bad. The bundled apps, both for OS X and iOS, are a UX basket case of early 2000s Windows Media Player proportions. I wish I could go back to the skeuomorphic era; those apps were goofy but at least they didn't do shit like quietly deleting music from my phone "to free up space" when I still have 8 gigabytes to spare.

And I'm getting more and more pissed at Apple for harassing me 5+ times a day to upgrade iOS, which I am not going to do because, seriously, now is not a good time for me to do any OS upgrades and I really wish they could understand that I do not live my life by their schedule. But Microsoft sure doesn't do great on that latter point either, and I have definitely lost work when my Win 8 VM decided to reboot itself without my permission. At least Apple is polite about being a dick to me over the OS upgrades.

That said, 2 years is a while, and both companies could go either way from here. And as far as I'm concerned, Unix running Windows in a VM is no less functional than Windows running Unix in a VM.

But Microsoft is shipping hardware I care about, whereas Apple seems like it's ready to charge back into the hockey puck mouse era. I switched to Apple as my primary platform at home just after that period ended, so it'd be fitting to switch away when it starts again.

About the only thing I'm confident is unlikely to happen is that I go back to Linux as my primary OS, because, seriously, Linux as a desktop OS is like something out of a Samuel Beckett play.

No. I actually really like Apple hardware, and can usually deal with the limitations. I was hoping Apple would offer a USB-A port and 2TB of storage on the 13" MacBook Pro, but I still ordered one without. The graphics and memory limitations don't bother me much.

However, I really keep hoping someone comes out with a competing operating system and ecosystem similar to Mac OS, but I haven't found anything that compares. Elementary is the closest I've seen from the open source world, but it needs a LOT more features and polish. I like Mac OS, but the quality issues and general product direction in the past few years have me itching to be able to replace it if I need to.

Thinking about Hackintosh-ing. Can take or leave the hardware for the most part (especially on desktop, but they do still have the best trackpad), but there's nothing better than macOS for what I want in my dev environment.

The new MacBook Pro refresh is too expensive. $700 CAD more than the equivalent 2013 model. I'm not going to pay that much for a Touch Bar that is a neat addition, but is not something I would opt into as an optional paid upgrade.

I will be waiting for the next model, and if pricing doesn't drop by then, it will likely be the moment I need to look elsewhere.

$2799 + tax = $3200 for my 2013 was right at the boundary of what I am willing to pay. $3499 + tax = $4000 is going too far.

To answer the OP's direct question: if it's an employer paying, then yes I am taking a MacBook over anything else.

I actually am switching jobs in a week; I was offered the choice of a 13" or 15" MBP. I do web development, so Windows isn't really an option. Unfortunately, I can't choose Linux, since it doesn't run whatever management tool the org uses. But if I could have an XPS or ThinkPad with some flavor of Linux, I would probably do it, just to be contrary.

I don't need more than a text editor, a browser and a commandline to do web development. So I would be fine with just Linux if that's all I ever did.

To do anything at all with iOS I need a Mac. So I expect that I will always have one around as long as iOS is a thing for me.

Windows is my favorite desktop and it is the best performer in my opinion. I absolutely need it to do work for most clients. Windows is the one that I will probably never be able switch away from completely.

Actually I did the opposite. Just bought my first Macbook ever. And not even the Pro but a Macbook Air! I know, bad screen and all. But I wanted to get into iOS development and I couldn't justify spending even more. But apart from the screen I don't think it's a bad machine. The XPS base model with 4GB -at leaste in my country- is more expensive.

It depends. My current laptop MBP Retina will probably last a long time. If USB-C support is good and the new function row turns out well, then I will probably buy it. If not, I'll probably go for something else (maybe just another MBP Retina if they're still up to snuff).

No, my next laptop will be a MBP. My brand new Thinkpad at work has poor power management and wakes up from a sleep sometimes, I thought Windows 10 was pretty good but it has random issues that make me wish I was using OS X, and I don't have time to spend messing with Linux config these days.

I don't plan on moving away from Apple hardware. Apple hardware isn't always the best bang for the buck, but the software ecosystem seems much more usable to me. Occasionally Apple makes changes that irritate me, but none have been so horrible as to chase me off. Yet, anyway.

Not me, I'm sticking with Apple even though I mostly run Win10 on my Macbooks. I looked at the alternatives and they are either crappy build quality, huge heavy bricks, or just as expensive as the Macbooks. Might as well stick with Apple since I trust their hardware.

No, at least in the foreseeable future. As a dual career developer and pro photographer/illustrator, apps/utilities are more important for my work than the underling OS and Linux's creative toolkit is not there (yet?).

No, I still run Adobe apps frequently and have switched back and forth between Macs and Windows a couple times; have settled on the Mac mostly for build quality (especially touchpad performance), nicer OS experience, and Time Machine.

Macs are horribly expensive in Brazil these days (US$ 5-6k for a decently configured MBP). Next year I plan to buy a gray-market Mac Mini and a fast notebook for Linux, and try a "Hackintosh" VM in it.

I realize you asked about work machines supplied by your employer, but I'm going to answer for personal machines anyway.

My home desktop is a 2009 Mac Pro. I also have a personally owned 2008 Mac Pro that I keep at work. They are both too old now for the new version of OS X, so it looks like they will stay on El Capitan.

At some point, I'll either need something that requires an OS later than El Capitan, or the hardware will die. At that time, I would not be surprised if I moved to something else. A lot will depend on what Apple's desktop lineup is like when the time comes.

I would want to be able to move the SSDs from my current Mac Pros to the new machine(s), and nothing in the current Apple desktop line seems designed to make that easy. I would be reluctant to buy any of the current Mac desktops with the Apple upgrade to SSD because that raises the price too much.

The iMacs are also problematic because of the built-in monitor. I don't want to have to keep a separate monitor for my Windows gaming PC, so prefer a Mac desktop without a monitor so that the Mac and PC can share it. For a while iMacs had a feature where they could be used as a monitor for another computer, but I believe Apple dropped support for that.

I suppose I could use an iMac and use Bootcamp to boot an external disk with Windows for gaming, but I'm also not sure about the iMac from a gaming performance point of view.

Another piece of Apple hardware that may be endangered soon for me is my iPad. I've got a 3rd generation. Like my desktops, it is now too old for the current OS. (And even the last version of iOS Apple released for it had some of its most touted features disabled on iPads as old as mine).

I'm seriously thinking of something in the Surface line when it is time to replace the iPad. That's because I'm getting annoyed at the multitasking performance of the iPad, particular of the browser. I'm tired of being on some big page, like a heavily commented Reddit thread, switching to another app or another tab within Safari, then switching back and having the browser have to reload the page. This is especially annoying if I was writing a comment and switched away to get some information I needed for the comment. I end up having to select-all/copy what I'm working on before switching away, so I can restore it if the page reloads, but then I cannot use copy/paste to copy in whatever it was I switched away to look for!

I believe that Surface is running more of a desktop OS with tablet enhancements than a separate mobile OS like iPad uses, and so I'm hoping that it would multitask more like a desktop system does...and so switching between browser tabs, or between the browser and another app, would not cause browser page reloads. I've yet to look into this in detail, though, to verify this.

My iPhone is great. I see no reason at all to consider switching to something else in the phone department. It's just tablets and desktops where I foresee problems.

I'm the guy whose Elementary OS post was on HN the other day -- and, incidentally, I tested it because I'm more concerned with upgrading my home desktop than my laptop, and because I need Docker, SSH, Visual Studio Code and Remote Desktop (the rest is all secondary) and prefer its looks.

(I also need to have something to use that isn't Windows at home to both keep an open mind and stay in the UNIX universe - which is how I got into OSX in the first place)

I work at Microsoft, wrote http://taoofmac.com for 14 years, and have a Lenovo Carbon X1 as my work laptop (which, incidentally, has a touchscreen I actually use, and USB A). I got it a year ago and had no choice in the matter.

I'm not crazy about my work laptop (I prefer smaller, more portable machines, and plan to replace it with a Surface i5 at the earliest opportunity solely because it's the most compact and lightweight machine on the roster with a decent enough display and battery life).

Now that I've answered your question literally, let me answer it in the way that makes sense for me, as a paying Apple customer: I want expandable hardware with standard ports and adequate performance for my needs.

In terms of laptops, the MacBook Pro Escape would satisfy only the latter (and even then I would prefer a better GPU).

I'm holding out for something like a new Mac mini (I prefer small machines, and like to pick my own displays), and at this point I am pretty sure I'm going to have to buy a bunch of dongles for it too (if it ever materializes) and that I will never be able to expand it.

I also find it frustrating that I can build a Hackintosh for _half_ the price of a current Mac mini that has a comparable (larger, but bearable) volume, fully standard ports, vastly superior repairability and much better performance (google for Snazzylabs hackintosh).

Most people complaining about the MacBook Pro do so because it doesn't match their requirements for performance (with or without Kaby Lake, GPU, battery or thickness compromises) or expandability (either aftermarket or lack of standard ports), and because expectations were too high regarding refreshes of _all_ the Mac product lines (even though rumors only hinted at laptops).

In short, your question has little to do with what people are actually complaining about. Even though macOS has evolved relatively little under the hood and recent versions have had a few more bugs than usual, few complain about the ecosystem or the OS.

We just want more powerful, expandable and flexible hardware instead of designer cutlery.

(And I'm going to be pretty annoyed if I have to buy a dongle with a MicroSD card slot on the end, too - THAT they would most certainly have room for.)

Did you try to talk to your manager about it? Maybe the company can help you grow into that role if there is a room for it. Moving from FE to BE looks like a career change in a way, especially if you only know JavaScript in the front end.Also, I would suggest you start a side project to play around with backend technologies and you see for yourself if that's what you really want to do in the future.

I am still in college (masters student) but have done a good bit of web dev both as a freelancer and at internships. I discovered after a while that it is not what I want to do long term, and have since tried to move away from front end.

I think the answer largely lies in where you have the interest and willingness to learn new tech. Moving to full stack would probably be an easy transition, as knowing both front and back end is very marketable, and there's even stacks which require minimal retooling (read: node.js). Alternatively, there's things like ML/AI, vision, control, embedded systems, crypto, and quite a few other sub disciplines which you might find more interesting, at the cost of a steeper learning curve. MIT has quite a large number of courses online (even in video form) with OCW/edx, and there are certainly quite a few other resources available for learning if you have the time/interest/energy. Picking up new languages is probably a good place to start, and it becomes very easy once you've written a few thousand lines in a couple different languages since there's so much conceptual overlap.

In terms of experience/resume items in order to get hired in a different specialization, I think that small toy/fun projects that display knowledge in a given subject matter are very good in terms of marketing yourself. Of course, this route takes a fair amount of time, but can be very rewarding and interesting if you pick projects that align with what you find cool. What you choose to do doesn't even have to be novel/groundbreaking to be very rewarding. It's also imo easier to learn things if it's in the context of needing solutions to practical problems. If you do go this route, I highly recommend making a small website that showcases what you have done. I did this, and have heard first hand from several managers that it was a primary factor in me getting an offer. I've even bombed interviews but still gotten an offer because of my website.

On the bright side, I do think that front end is a very useful skill in general - I use my web dev skills to display my other work and occasionally to pay the bills. If you do decide to pick up a different specialty, your time thus far will not have been wasted.