I tweeted this yesterday and the response was not good.
// Detect dark theme
var iframe = document.getElementById('tweet-121570632857390694...
For further actions, you may consider blocking this person and/or reporting abuse
Displaying a subset of the total comments. Please sign in to view all comments on this post.
CSS and HTML are sufficient to build 99% of all websites.
Add a little bit of Vanilla JS. that's it
Like the sprinkles on a cake... 👍
OH DEAR LORD, YES.
Your web server is coded in HTML and CSS? How does that work? 😜
David was talking about web*sites* ;)
Super high coverage testing is sometimes a waste of time 😬
💯 coverage is usually an indicator of highly coupled testing, which leads to very fragile tests, which leads to the tests being turned off...
Which leads to anger, anger leads to hate, and hate leads to suffering.
For every metric, there is an equal and opposite metric.
Test coverage is good to know and track, but it can hide problems if it isn't a factor considered alongside a lot of principles and qualitative decision making.
Yes exactly; test coverage isn't the goal in itself and I think sometimes focusing too much on a percentage coverage is a distraction from creating an actual robust pipeline.
See also: snapshot testing in the frontend. Very easy to achieve close to 100% coverage with tests that are easily ignored and overwritten when they fail 🙄
Who writes the tests to test the tests?? 😵
Coast guard.
Full Stack Devs really exist.
What is a full stack dev? A "jack of all trades"?
Yes, we exist. I design, write markup, styles, and handle back-end code and design database models.
But can you solder? 😜
One of the fun games to play with people who call themselves full-stack devs is to see just how "full" their stack is. So often it's just a bit of JS and PHP.
I can solder 😂😂
Exactly, I have also seen bad examples of full stack. But that doesn't change the fact.
I ask because I think people use the terms "front-end developer," "back-end developer," "full-stack developer," "Java developer," etc. in different ways.
Sometimes an "XYZ developer" term seems to describe the skill set possessed by a developer, and other times it is used to describe the specialization area of a developer.
When talking about skill sets, the term "full-stack" makes some sense to me: it emphasizes that a developer has learned a little about a lot and is comfortable diving deeper anywhere, including new territory.
But when talking about focus areas or areas of specialization, I think the term "full-stack" can be confusing: it seems to say "I'm good at everything," but a) that's not true, and b) every tech stack is different.
Devs can build their portfolios on WordPress
This is a great one.
Wordpress isn't exactly an "elegant solution" these days, but it is a hardened one with basically every use case imaginable covered. Any user-facing flaws can be overcome with tooling and config, same as any comparable software.
It's also very useful to learn Wordpress. The company behind Wordpress just raised another $300m. The software isn't going anywhere any time soon.
True Ben.
Headless Wordpress with Gatsby kind of well optimised frontend will be a killer combo for mid sized projects
Use cases,
Can second this. Been building a full-stack app for a few months now using WP as the backend + GraphQL API and React Frontend. Also use some serverless functions to supplement functionality that can't be done in WP.
It's been amazing because as a single dev, I can work on what would otherwise be a huge/impossible project by leveraging WPs' CMS, authentication features and plugins.
The only thing slowing me down is the WordPress GraphQL ecosystem is still almost non-existent
I'm going to be looking into Gatsby and next.js this year. One question - how do you handle updates on Gatsby when a post or something else is updated in WordPress? Do you have a hook/action that is triggered and posts to gatsby to run a new build?
I used wordpress once in 2003 but I haven't built a single wordpress site ever since!
I recognise what people have done with it, and it's maturity as a platform, but I count myself lucky!
It's 5pm I want to go home.
My boss makes a point of telling us he doesn't pay overtime. When I first started I was staying until 6-8 PM. Absolutely not worth it.
Not paying overtime is pretty normal. But staying that late definitely not normal
But did your contract have that clause which states working extra hours to get the work done?
Yea. People are working themselves hard. I think some people are worried about their prospects or they really love their job.
It would definitely be the prospects. I've worked with companies that do have a good balance though.
JavaScript is well-designed: most of us simply don't use it effectively and too frequently blame the tool for our problems.
It honestly irks me a lot how people cite the infamous
0.1 + 0.2floating point arithmetic error as a justification to ostracize JavaScript (even though most programming languages suffer from this issue as well by virtue of floating point limitations).Like, seriously? Are tiny nuances really that evil so as to dismiss the programming language altogether? No, right? Python suffers from the same error, but is nonetheless one of the most loved languages out there.
You are definitely correct about people not using it effectively. When people write arguments against the languages, it's always because they don't use it right, as in non-"Pythonic" code for Python.
No, I would cite -- github.com/aemkei/jsfuck
Most importantly,
[1, 2] + [3, 4]that I learnt from Python. I know that there is.concat()and spread operator, but still...Another thing is
varhoisting, but it can be made understand, really.I hope I'm misunderstanding, but this style of example "learnt from Python" always puzzles me. Specifically, why do devs expect things to work the way they do in some other language, rather than learning the constructs in the language theyre presently working in?
I do suppose that the language should be failsafe. Even TypeScript doesn't warn., nor throws an error. Even Python is safer. TypeScript is partly safer, and some part more dangerous than Python, due to JavaScript-based.
RTFM, partly, is OK. But reading the whole EMCA specification is crazy.
Also, I cannot expect tutorials to teach everything.
I also expect the language to be "guessable" rather than being told to do so. Otherwise, throw an error early.
Productivity doesn't wait for you to finish learning...
But knowing additional paradigms might be helpful. Knowledge should add-on rather than replace.
Still, end-in-end, I love JavaScript (not even saying TS), more than Python.
Although it was designed in 10 days (in a way) it is quite simple and good enough I would agree. I just would never use it for backend as I prefer type safety and having some thread control. Dynamic typing and such things could be "shoot yourself in the foot" for some devs and then they blame the tool.
POC are likely the first production release
¯\(ツ)/¯
Sad but true. I haven't been in the game long, but I feel like the whole "move fast, break things" mantra is often interpreted as "ship your prototypes."
Most software products I’ve seen have at least one feature that just screams “we have a demo on Monday, can you code this over the weekend?” And then that’s what goes to prod because there’s another demo on Friday for some other feature.
Haha yes
"we have a poc, so the Software is already complete. There is only some logic missing!"
Man I think I just found my support group 😢
learned this the hard way
Scalability can be a premature optimization
It is, always.
Don't need it, yet doesn't come into it.
Agile is rarely implemented properly. It usually ends up as shorter timeframe waterfall with less documentation.
And called incorrectly. We do Agile is like saying We do Green. Maybe Agile Methodologies?
I call it FrAgile because the Agile pieces tend to fall apart pretty easily and then it’s just a poorly planned Waterfall project...
That's just true, not unpopular, just not talked about.
I guess, that's not that unpopular.
Some “do agile“ because they're trying to come across hip, but once you look inside it's (like you said) plain old waterfall in biweekly sprints.
I've started asking in depth about user stories, effort/story points, on time deploys vs overtime hours in interviews and literally every company, even large blue chips are stumbling on it. They don't know their process, they think user stories are a waste of time. But then you ship the feature and everyone is all "damn we can't do X" sigh
Basic for loops in JavaScript are fine.
Depends what you're using then for. For performing operations on every element of an array or object, Array.prototype.map is really nice. But I definitely agree that for loops as opposed to Array.prototype.map, reduce and for each are never really bad; they're just sometimes not the best.
As soon as you need to have async code in your
forEachcallback you need to switch your code to the for loop again. So if there is any chance this might happen, pick it right away...Nope, you can Promise.all()
How,
.forEachdoesn't collect the returned value, you would need to switch to.mapand there are quite some cases where you don't want to fire all of these things "at once".Then you can use await and Array.prototype.reduce. It sounds a bit awkward but is actually straightforward.
PHP isn't dead and it won't die any time soon.
JavaScript doesn't suck, but a lot of JavaScript developers do.
PHP is definitely not leaving any time soon. It's still the easiest way to deploy a functioning website. Traditional hosts are not the sexiest thing in the world anymore, but they're still running strong. Guess why? Push one index.php file through their web FTP interface (urgh) and you're on the internet.
I so fucking agree, even though I stopped using php while ago.
Burn! Okay how you measure your skill against others, thats nothing to do with languages what so ever. What do you measure 'a lot' as and 'bad' as?
I don't. To be honest, I would count myself in on devs who suck at JavaScript.
But I think JavaScript gets shamed a lot not because something's wrong with how the language works, but because many users expect it to work in a different way than it actually does.
Some devs come to JS and see the syntax, thinking "Yep, I know C (or C++ or Java or some other language) - I can work with that too.". And then they skip learning it as a new language and instead start using it straight away. But then something doesn't go exactly as they expected it to and they jump on the JS shaming train.
For me I started my career in the front end, it got to the point where I wanted more. More than node, more than typescript. Knowledge of programming in general is my goal, my first dip into another language was lua, not syntactically similar just a really interesting simple scripting language, that has deep ties within C, I then tried to tape node and lua together with WebAssembly and c++ because why not. It's true that I am accustomed to C style dialects, but it's also true that I have never had such expectations that everything is like JavaScript. I don't think I have met anyone who has had this expectation, but in my bubble all the developers in our team are full stack with a strong lean towards whatever.
I believe in learning programing concepts not languages, to do this I have delved in to a number of backend languages which I am starting to loose count, (being good at a language was not the point, learning was) Most recently returning to Rust, I find this language is outstanding.
I have not yet taken a stab at PHP but I have wrote a few posts about my shameful predudice against it and why I should give it a chance because honestly PHP has probably got a lot to offer in the server department. Anyway I find this opinion interesting but not really quantifiable.
Code Review is a terrible reactive concept that is overly relied on by teams and used as a crutch for bad communication. Pair Programming is significantly more effective at spreading ideas, communication and critiquing code.
I agree with your thought on pair programming, but I haven't experienced your view on code reviews. Are you saying that pairing can be a viable substitute for retroactive review?
Unfortunately pairing doesn't happen much in my current environment, and I don't do much to encourage it. In its absence, I think code reviews are better than nothing, but reviewing code effectively is just as challenging as delivering constructive feedback (because that's exactly what it is) and there aren't nearly as many devs who are good at this as there ought to be.
Hey Daniel! :)
I find that often by the time code is up for review it's "too late" to make important changes. As you're wrestling with factors like the sunk cost fallacy and the de-motivating effects of suggesting that a colleague re-do their work seemingly to appease you.
Not only is it often "too late" to make changes but sometimes it's also hard to convey larger feedback via text. Complex changes are often only realistically conveyed in person going through piece by piece. Naturally over time though the amount of "explaining" is asymptotic as you get more and more inline with each others viewpoints.
My take is not that code review is bad (it's important to stress this point) it's just that I see code review is used as a crutch for not having adequate conversations prior and during the creation of code (since it's reactive in nature). And pair programming in my opinion is superior at type of communication.
However I know that my opinion is unpopular since I'd say the majority of developers I've worked with would admit that they dislike pair programming, which seems to tally your experience too so until the day comes that the industry invites more pairing I'll be over here shouting into the void! 😂
Thanks for elaborating!
Honestly I quite enjoy pairing, but I've recently found myself in a remote work position that is also separated by about 8hrs from my teammates, which makes any sort of synchronous communication difficult. I've been experimenting with opening up a PR as soon as I make a first commit to a branch, and tagging my teammates with the hopes of exchanging feedback "early and often." I've met with mixed success, depending on how available my teammates are.
For large stories, I try to push my team's / teammates to use a two-phased PR: one for the interfaces/design, a second for the code.
This promotes discussion on the approach early on.
I agree. I always found it daunting looking at a PR with 40+ files changed without even knowing what the PR should be doing. In the end, it always seemed to just end up being more efficient sitting down with the owner of the PR and them walking through what changed and reviewing it with them.
Oh and also actually getting the person to RUN the code to see it actually is doing what they expect it to do rather than assuming its working correctly.
git rebase>git mergeThis is semi-accurate. I'm specialized in front-end, but have built a TON on the backend.
HOWEVER, I don't look at a backend specialist and say "Anything you can do, I can do", I simply approach every conversation with humility and acceptance that there may be a better approach, and I can't possibly know everything there is to know about all aspects of code.
I'm not bad at backend. But I can realistically assess that while I might be able to architect a cutting-edge front-end with all the bells and whistles, I can simply do an adequate job on the backend. That said, I have had the experience of writing a breadth-first sorting algorithm for a backend implementation covering millions of nodes that completed in 5 minutes vs the previous 6 hours (written by a backend specialist who I would say is VERY good)... so I definitely wouldn't say I'm BAD at the backend...
As a community we need to embrace the fact that there are universal coding patterns that can be applied on the frontend and backend. While I might specialize in tools for the frontend, that doesn't prevent me from using those patterns in work on a backend.
This is what I'd call "experience" though. How long have you been working in the field?
I do agree with you, though. People will have to come to terms with the fact that any decent web developer can learn most parts of the stack just fine with some effort and a tiny bit of interest.
Define "working" ROFL (Kidding)
Getting paid? A little over 10 years now.
But writing web code? Let's just say I remember writing code at a time when CSS didn't exist.
And absolutely it takes experience. I would look sideways at someone calling themselves a "Full Stack Engineer" on the first day of their first job without some significant background information haha.
I'm 3 years in, have worked on production environments maintaining and developing PHP/Node.js back-ends as well as React/Vue front-ends, and CI/CD infrastructures...
I'm still having a lot of trouble calling myself "full-stack". I'm way too junior to pretend I know both well enough.
First: Sounds pretty "Full Stack" to me. Second, make sure you have a specialty that you feel like is your "go-to" (Front-end, back-end... and even though "DevOps" is a mindset, it CAN be a specialty too).
If you've got that, but you wouldn't "little Bobby Tables" if you touched another piece of the stack, then you're full-stack.
You DO need a realistic assessment of your own skills. If you're mid-level in the front, but junior in the back, be honest about it and ask for mentorship and guidance from a senior backend engineer, but don't be afraid to pickup those stories either :D
xkcd.com/327/
Pretty much the opposite situation for me! I'm primarily back-end, but learned JS, then React/Vue, then CSS out of sheer necessity, then realized I wasn't half as bad as I thought I was at it. I still suck at layout, especially when responsive, but I'm getting decent at scaling things in mostly sensical ways.
I'm probably getting to mid-level in back-end at this point, maybe? And I learned DevOps-y stuff by scaling up my team's growing architecture past their FTP and manual CRON jobs on a single VM.
I don't know, I feel like I'm just one big unpopular opinion. Where do I start.
Oh, lighthearted, AI will not take over the world because humanity will have already subsided control before machines could create a plan.
I use Spacemacs in
evilmode 😀I've used "Programmer Dvorak" for the last year and love it, but it has ruined my ability to type on other people's computers 😆😭
Most definitely. I use Mac at the moment, but I'd order them as Linux > Mac > Windoze
The only problem I saw with YAML is that it is overdone.
noandyes?safeDump/safeLoadshould be default, and probablydump/loadshould be renamed tofullDump/fullLoad, ordangerous, or just use a customEncoder/DecoderI saw no problem with indentation-based languages, though. That is why Markdown is popular.
I have my own post on it
Stop Using YAML
Jesse Phillips ・ Oct 12 '19 ・ 2 min read
Likes goes to TDD and dynamic typed things. Vim I disagree I think editors should be a matter of taste and never to be discussed xD.
You don't understand, vim stands for VI Improved. You're missing out on some very nice additions, like multiple undo, by sticking with vi.
Closing your eyes to the changes happening will just just hamper your growth. xD
IDEA is way better than Eclipse and Netbeans.
All jetbrains ide's are just awesome.
Amen.
You need a BSc in computer science to be a good developer
Counter unpopular opinion: being a good developer has less to do with your knowledge of computing science (e.g. algorithms, runtime complexity, hard maths), than your ability to communicate your solutions to complex problems in non-technical ways.
You need a BSc in CS to be a good computer scientist. But not every computer scientist is a good developer. Most good computer scientists I know are more of a mathematician than a dev.
Or as Paul Graham writes in Hackers and Painters: "Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia."
Hmm, never heard of that one but good to know how my region became like it is - thrown together by an accident of histroy xD.
Anyways exactly what might be the problem: software development != computer science. Some people mix these two so it might be the reason for confusion.
What if you just watch computer science lectures from universities. I can't afford to go back to uni I'd be 200yrs old before I paid that off.
A lot of them have BSc in something else, a lot of them have no BSc at all. So it's not unpopular it's in fact untrue. Although I have BSc in IT which is a bit different, most of my knowledge comes from work or learning by myself in spare time. Now I know more people without BSc in computer science that are way better than me.
It's not defending something it's just a good argument. Don't remember that many popular developers that had BSc while becoming famous. basically I want to argue that you can learn outside of university.
Native mobile development makes sense.
Are you telling that my job is an unpopular opinion ?
this makes me sad :(
Makes me sad to, there is so many tasks that are just better on native.
You don’t always need to write tests.
I do think we should write pre-Pull Request / pre-Merge tests, though. I saw this a lot with GitHub Actions.
Pre-commit is optional, but should be done.
Using
from whatever import that( Atleast Python)is better than
import that from whatever.What about:
use whatever::{that, and_this};Bonus pts for guessing the language.
Rust!
And maybe typescript too...
Arguably the most interesting module system out of any language, Rust, I don't have any prizes, but this gives me an idea for a post "guess the language".
♥️ Typescript as well, ♥️♥️ for Wasm bindgen TS and Rust it's so beautiful!
Yeah, I love Rust! The module system just works. I've never had issues like the include hell with C and C++
Anything which can help the IDE/ text editor to autocomplete.
Material Design sucks!
Material Design absolutely sucks so much.
I actually love MD, but it's a pain to work with on the frontend and it's very overused.
We've hit peak React.
I would go farther... React is in the same place jQuery was circa 2009-2013.
Once something is so ubiquitous that it starts becoming synonymous with front-end programming, people start to think it is the cause of their problems. So they look for and build alternatives... Which is how we got the last decade of "Whack-A-Mole: Framework edition"
I'm interested to hear more as I haven't been in the industry for that long: do you have objective reasons for thinking React will go the way of jQuery, or are you basing it more on previous cycles of hype->obscurity?
My general thoughts are that just because something happened a certain way in the past, it doesn't necessarily mean it'll play out exactly the same way again (although it may, of course).
The only clear challenger to SPAs/React I currently see is WebAssembly. That would be a paradigm shift in the way that React was to jQuery. However, I think even WASM won't eat at React's market because WASM will typically be used for games (it'd be over-engineering for most other purposes).
The final piece I see is economic. The longer React remains in demand, the more companies and startups build their entire apps and tooling around it. With all these vested interests, it'll be extremely hard for a challenger to match React's ecosystem in the coming years.
Just my thoughts though, happy to be proven wrong
First: SPAs and React are not synonymous. I do need to make clear that the SPA design pattern will probably never go out of fashion, but Angular, Vue and React (with the appropriate routing libraries added in) all provide a SPA experience.
I'm definitely basing my opinion on previous cycles, but there ARE objective reasons and parallels.
JQuery is still a powerful library that is still in use today (As we see in these comments). I feel certain that will hold true for React 10 years from now.
JQuery saw its "necessity" eroded by the evolution and adoption of its central features into the W3C spec. The things that forced you to need jQuery became native JS.
React is beginning to see that as well. Web Components eliminate the need for React as a means to separate concerns in your code. Just as document.querySelector and the DOMContentLoaded event replaced core jQuery functionality, you're starting to see Svelte and Stencil fill the component gap by offering solutions using spec-compliant web components (Stencil is WC first vs Svelte as an optional compile-target). You COULD do without either, but they give compile-time convenience and abstraction of boiler-plate that is impossible to ignore.
That's my biggest "objective" idea about React and the other current frameworks. The idea for these frameworks was born over 10 years ago with Angular. It was a reaction to jQuery and how, no matter how easily you could traverse the DOM, there was no way to create a simple custom HTML-tag that could easily import a new component. It wasn't part of the spec, so people created it. Now, a decade later, it IS part of the spec, but people really like the habits they've developed over the last decade haha.
That said: The EXACT same things about "economic" dominance have been said about JQuery, PHP, Java, C, FORTRAN, and a million other languages/frameworks. I just don't think it holds-up in the face of history is all. Just like there is a ton of work in the industry today and for many years to come in Java and PHP, I think React will see the same slow decline over the next decade that jQuery, Java and PHP have. (Note: Java's decline from number one by an astronomical margin to sometimes number 2 is STILL a decline... don't @me LOL)
That's just my (unpopular) read on the situation. I won't feel a bit sheepish if I look back on this post a decade from now and React is widening its dominance over the market and no one learns vanilla JS anymore haha. I just don't think its "necessity" now is anywhere near the same as it was in 2015 or even 2019, and that will cause a decline in use in the next few years as people start getting tired of using the new "hooks" or other FOTM they decide to introduce as a reaction to new innovation in the marketplace.
Thanks a lot for the great reply - that was very insightful and I definitely learned something. Particularly the part about web standards: I'd heard it before (how frameworks are basically a faster way to iterate with proposed web standards), but hearing it again helps me see the bigger picture.
I still think if we were to see a decline in React usage it would be a long way off. But your comments highlight the importance of diversifying one's skillset and keeping up-to-date with other technologies, so thanks for that
Another reason React will decline is the baseless assumption that "DOM is slow". There will always be something faster that comes along.
Continuous integration means integrating continuously.
Dependency injection means injecting dependencies.
I'm very sad that "Continuous Integration" doesn't mean what it's supposed to mean anymore. "Of course we do CI, we have Jenkins".
Communication is just as important as code.
Also, visionary and design.
It's more important.
Java is OK.
Object oriented is fine too.
Functional programming is not great at everything.
Kafka is not solution to everything.
Microservices are not faster but more scalabe (there's a huge difference).
Microservices don't decouple your code, you (developers) do.
Coupling is not the biggest issue...
TDD won't make your software better, better UX will.
...
There's a lot of them, and there's a lot of them in previous comments :D.
RxJs can be used in the backend. And it's DOPE.
RxJava is quite popular why wouldn't RxJS be? Because node supports async/await? I gotta know why people dislike Rx
It actually is popular, its heavily used in NestJs development. I think people dont dislike it, many havent tried it
Why have you listed it as unpopular then? Don't get it sorry
I believe it's a growing trend. Ive told other devs about this and seems to be unpopular for some.
I've only ever tried RxJS with a React app and I loved it. The issue was I felt it's something with a lot of potential, but hard to find a concrete use-case for. Like I'm walking around with a hammer and everything looks like a nail. Or maybe I just don't properly understand it.
Could you provide some innovative uses of RxJS? Backend or frontend. RxDB is something that looks cool, basically like Firebase
Turning Javascript into a backend language so you "only have to learn one language" was unnecessary.
Yes. And in fact Ryan choose JS simply because it was the only language at the time with an event loop. Pure coincidence.
An event loop was added to NodeJS to handle concurrency as it was the only viable option - not a strength.
Other languages have the freedom to use multi threading instead for concurrency.
I wrote a post about this.
dev.to/michaelcurrin/javascript-s-...
nope. Event loop wasn't added to node. NodeJS was was born because all other runtimes had no event loops.
Ruby on Rails remains the fastest way to build a usable web application.
Beat me to it!
As long as it works... it's fine.
What context do you have in mind?
I think "it's fine if it works" makes sense for rapid prototyping, proof-of-concepts, and other "throw-away" code, but when it comes to code that will be shipped and therefore maintained, I lean towards "good enough to work is not good enough to ship."
True, though I meant more for personal growth etc... and not business needs because there always seems to be a pressure to do better or write less with "more advanced" languages. A carousel is a carousel regardless of what tech was used and how it was hacked together and I think that you should be proud regardless. I'm probably wrong though...
Good to see developers and the like still being practical as ever though 😂😂😂
Fully agree, since the statement without context could also be applied to social injustice that just works for most people.
😂😂😂 Making vague statements keeps me out of trouble 😂😂😂
As long as a questionable bit of code has decent tests I'd let it in the codebase.
Not necessarily unpopular in the traditional sense, but things are not always black and white. There's the "it depends" opinion that can be lost in the cracks or I'm just hypothesizing here, but maybe some developers do not want to take the "it depends" stance.
For example, keep it DRY. A lot of discussion has been happening around this the past few days. These are just some Tweets I found
I'll leave you with Jay Phelps Tweet because it made me laugh. We got a whole lot in the toolbelt. 😉
And in the end, all the above leads us to healthy discussions hopefully, like finding the right abstraction which is a good thing.
DHH is right regarding monolith apps.
What is DHH?
David Heinemeier Hansson, creator of Rails.
en.wikipedia.org/wiki/David_Heinem...
I don't try to get into debates because you can go in circles, but we've largely subscribed to "majestic monolith" ideology.
m.signalvnoise.com/the-majestic-mo...
Here's 2...
#2 is how I (re)learned the hard way why reinventing the wheel does suck, esp. when the wheel is authentication, caching, and keeping data in sync between the server and clients.
Right! But there is a startk difference between bringing in a few libraries to help out and loading in a framework to only use a fraction of the functionality.
That's not unpopular. That's just the truth ...
Ooh I like this! But don't think I could inflict that on anyone 🙈
You almost certainly don't need a big data solution like Spark - in fact you can probably run that "big data" process in memory with a hash table ... And you can probably do it on your laptop while also running Slack
'Cloud' hosting is inferior to a standard VPS for most users
Why? Got a blog or video to explain?
Also, what is VPS and how much does it cost?
For beginners dev, hosting shouldn't cost a penny.
VPS stands for virtual private server. It is basically just a computer with certain specs you have full controll over. This means you can host anything on it, a website, a game server, mine bitcoins, whatever. I have one for just €5 a month, though the specs are not that great.
When I say cloud, I am referring to the services offered by Google or Amazon. The main difference is the "pay-for-what-you-use" policy, instead of a fixed price per computer you pay for the amount of processing power you use. The dynamic scaling ususally needs to be done with some API which leads to vendor lock-in, plus if you use a bit more in a month it actually quickly gets more expensive than a VPS with similar specs.
I agree for beginners you shouldn't by either, better to use GitHub pages, Heroku, or PythonAnywhere. However, if you need non-trivial processing power or a custom domain or anything outside the limitations of those services, get a VPS.
Also, don't get shared hosting. It's barely cheaper but usually you are restricted to PHP and when you need anything that requires root you have to go via customer support. The only advantage is that you don't have to set up email yourself.
BDD (behavior driven dev..) is totally mis-used and writting tests in GHERKIN style makes no sense.
** Specially if no business people are looking at the code at all
I agree with your opinion on Safari as it just integrates best with macOS (UI, performance), would be very cool by Apple if they'd pump up the DevTools though as regarding that nothing beats Firefox (for now).
My unpopular one: 99% of all websites can be done with HTML, CSS and a bit of Vanilla JS.
To me, TypeScript is just like Babel JavaScript with typing. You can always cast to
any, or// @ts-ignore. And, the configuration withtsconfig.jsonis relatively easy. Nowadays, I use ESLint as well, so it gets a little complex.It is the best "dynamic" typing language IMO, but not strict enough to compare with static typing. Still, being partly dynamic can be massively helpful.
Engineers should be expected to spend a greater percentage of their time doing analysis, design, UX and product work.
Indentation-based language isn't bad. That is why Markdown is popular. I even suggest this.
Only needed to be fixed by linting rules.
Yes you can 😁 - think of it as a forum.
You don't need to pick between development time and quality
Don't forget to do tests for the tests.
I have no qualms with TypeScript, but I'll admit i tilted a bit when i interviewed a .net dev whose reasons for using Typescript amounted to "i dont want to learn anything beyond classical inheritance and imperative programming".
Typing options are a great addition to js, it just saddens me when they're used in place of learning the language and the paradigms it offers.
Jquery is an awesome JS framework even in 2020
jquery is not a framework, its a library of helpers ;)
I can't name another framework that has had such a profound impact on my career, I will give you that.
Jquery is still bloody amazing. What it set out to do was ensure compatibility across browsers. Doesn't mean to say certain features are not outdated, but to sit there and criticise is juvenile.
unit testing can sometimes be overlooked... :v <3
I could, use
<form>and make the magic happen on your backend/server.There are apps that are totally bug-free. Reality says the bug just hasn't been found yet
Squarespace would have been a great solution for 80% of the sites I’ve ever coded and it would served the end client better for substantially less money. The agencies I work with love a good up-sell though: WordPress, custom design and a custom coded theme it is.
Also, tech is fun but we’re kind of paid to ruin the world.
Single Page Applications are an artifact of over engineering, faux productivity and large tech companies biding for mind share in the developer ecosystem. SPAs are uncalled for 99.9% of the time.
"Modern" web development is done by using complexity to deal with complexity. Have an issue with your build tool? Create or use a newer build tool. Can't handle REST for some reason? Try GraphQL or gRPC, or another large company backed protocol. What could possibly go wrong?
"Modern" web development is misleading and toxic. It implies the older way of building web applications are relics of the past when a vast majority of the web and current day development is done using the older methods. However, the term "Modern" is a great way for companies to market and sell their SPA frameworks to young developers and rope them in while promoting their brand.
Frameworks are double edged and not good for developers also they are slow and the best way they could make up for the lack of crappy coding is to push some stupid idea of materialization that is some how trendy to show what the page may look like before it's loaded people are so lost
FLOSS is most important product delivery and development method.
Also Free Open Hardware is important for development of science and different communities.
Its not about few rich guys accepting an idea and investing into it, but its about a lot of poor and rich people working on for them important ideas in their own communities.
Sorry its a bit long comment but that are two most important issues I think are unpopular still if you look at whole industry at large.
1a. You learn little to nothing about a developer candidate through live coding/whiteboarding challenges (except maybe that recent CS/boot camp grads and job hoppers do better at them than devs who actually solve real world problems on a daily basis); meanwhile, they learn a great deal about you and your company if they're paying attention (none of it good, e.g. "I'm smarter than you" attitude, micromanaging culture).
1b. You're more likely to detect BS from a dev candidate if you have them at ease in an interview, particularly the first technical round (conversational, trading "war stories," etc.).
1c. A take home code challenge, followed by code review interview, will actually teach you what you were trying to learn in the live coding challenge interview (by making them justify their decisions, even if - also unpopular - they swiped code from some repo, Stack Overflow etc.), without making you and your company look like micromanaging dicks in the process.
In a decade from now, our current, continued adding of more and more management tools, frameworks and abstraction layers on top of existing technologies will be considered one of our biggest mistakes & main causes for a huge brain drain in the entire technology sector.
especially the mobile version.
Worrying about performance to early can be unnecessarily expensive.
Rumor has it they are moving to a Chromium base code?
Kotlin == Swift minus a couple of features.
Software branching is harmful.
JavaScript's const was a mistake.
Why do you think so?
Because everything should have been made immutable by default, let should have been const and var should have been let.
Reactive programming and especially RxJS is overrated.
The Spring framework isn't a silver java bullet
Always release on Fridays. If you end up working on the weekend, spend 5 minutes reverting your release and lots of hours to increase your trust in the system.
Simplicity over DRY. This may be popular though
Your beloved language, tech stack, etc is useless if the user cannot use it or has a hard time using it.
When I code, I don't like using what I consider "bloated" IDE's like VSCode. I like Sublime Text3 with Anaconda plugin for linting and PEP-warnings.
It's okay to not use the terminal or command line for every fucking task possible.
I like ts a lot, specially with a high configuration of tslint when the team are huge. It never where so easy to team code.
Not every back-end with JavaScript is good
Windows is now a great SO for software development
LESS should die
Tailwind css is only slightly better than online styles 😜