You can also rephrase the question as:- Are you assuming full ES5 support when building libraries?- Are you assuming partial ES6 support when building libraries?- Are you pushing shim responsibility to the user?- Are you ignoring browsers that are 1% or lower in market share?- When should a library stop hand-holding older systems?What's your opinion? When should a library shed off legacy...
I'm not talking about Twitter snark or HN snark where an all-out nerd war can happen in a snap and nobody really cares. I'm talking about snark thrown in a Github issue.How do you deal with that while maintaining composure but not totally ignoring the poster?
I have been doing web development for as long as I remember. I get by with tools that are needed for the job. I don't fancy the new and shiny. I just get things done fast and done properly.But I feel like I'm always a step behind the rest. There's this guy in the team knows how to operate Amazon, or this guy who that knows how to use Spring, or this guy that knows how to scaffold a Java app in...
I'm a member of an open source project. I tend to issues, answer questions, do house keeping, review some PRs, such and such. But I feel out of place because although I tend to the matters of the repo, I don't really know how the internals work, therefore I could not contribute the most essential part of it all: code.Other developers in the project are having these cool discussions about...
- HTML: Vanilla
- CSS: Bootstrap 4 (SCSS) + node-sass
- JS: Any framework (ES6) + Rollup + Babel
Deployment:
- Repo: GitLab
- Host: GitLab Pages
- CI: GitLab CI
Math [Uhm...math] <-> Computer Science [algorithms] <-> Computer Engineering [robotics] <-> Electrical Engineering [electronics]
It's even fun to think about if you involve communications. It becomes a three-way.
(Between CS and CE) -> Communications Engineering [radios] -> Network Engineering [protocols, wifi] -> IT/DBA/Web [closer to web]
If native apps aren't an option, use Chrome or Opera for Android. They both have bandwidth-saving features. Your pages are crunched by Chrome/Opera servers so that they come in smaller to your mobile device. Should you want to continue using Firefox, Opera offers Opera Max. It's the same data-saving feature on the Opera browser, except packaged as a separate app and does compression on all device traffic where applicable.
Further, I don't think the bandwidth savings are that great if you disable JS. Resources like JS and CSS are cached by the browser. Assuming you don't always clear the cache and let it work the way it should, they only impact is the initial loading of pages where it has to load all resources. Further accesses are retrieved from cache when possible.
Again, use a native app or just use the app the way it's supposed to be used and save yourself the headache. Disabling JS is like trying to drive a car but insisting on having the engine removed.
Got a question? Ask Stack Overflow.
Want a reference? Get a real book.
Want to learn programming? Go practice.
...suggest you your breakfast, lunch and dinner.
"you probably need a pizza today"
JavaScript is becoming terrible these days with all these foreign concepts being pulled in. It's not like the language doesn't work without them. It even gets better, ES7 has the async keyword that's totally different from generators, but is geared to do the same thing. So you now have 4 ways to deal with async stuff: vanilla callbacks, promises, generators and async functions.
---
On a side note, the people who lead JS included `const` in the spec. Now people are using `const` to denote value holders that won't and should not change values, happy ever after right? Wrong. The same people that are leading JS are making fun of people using `const`, saying that you're probably brain-dead to need `const` to keep you safe.
That's the kind of people "leading" JS.
Not really. Chrome dev tools has an "async" option which allows the stack trace to follow through async calls. You will see the async caller instead of the async execution mechanism in the stack. Further, you can black-box frameworks so you only see your code.
> The danger I see with promises is they can be used incorrectly.
The real danger of promises is the different implementations that existed beforehand. For instance, jQuery promises weren't standards-compliant. Their implementation of `then` (which came from `pipe`) wasn't the same as the native one. Getting used to one, you'll easily write wrong code for the other.
> generators will provide more fine-grained control.
Depends. It's a foreign concept in JS, making it harder to follow as opposed to promises which are nothing more than stateful objects. Also, one's mental model will change with generators. One has to look out for that tiny `*` to know the code is "generator friendly".
"slipping" can happen if:
- The dev tools can't determine where to move the breakpoint (i.e.: if you significantly changed the file). Just re-assign the breakpoint.
- It can also happen when you use a badly-constructed source map. Disable source maps and work with raw code, and contact the tool-maker about this.
- Sometimes, the dev tools will just go crazy. Just close and reopen.
- debugger. You have no choice.
Both.
Master one, but learn enough to be able get around with the others. Also, learn the language, not just the tools or the new and shiny things. Tools and frameworks come and go, but the language itself will always progress.
> I feel like I am not doing much designing and not really learning a lot.
Work-related code, especially the monolithic, enterprise-y variants, isn't the best place to try something new. Try contributing to open-source projects. They're always in need of additional hands and move relatively fast enough that new stuff comes out regularly.
- Life's too short to deal with cross-browser incompatibilities.
- jQuery too heavy for you, there's Zepto.
- Not at all times you are in control of your stack, especially when you just inherited the project.
- If you happen to work on a Drupal project, good luck with ditching jQuery. It's built in.
- Clients will always ask for "cross-browser support up to IE8" without knowing it's a dead browser.
- What matters to clients is that it works. They don't give a beaver's construction project what you used to build it.
I'd wouldn't say "Why you shouldn't use jQuery", but more of "when to and when not to use jQuery/vanilla/CSS3".
Integration: Automated UI testing.
Functional: Humans, lots of them.
Startups usually have very small teams. Take advantage of tools that do stuff for you. Also, having other members of the team take part in testing is a means to get to know the team better and learn something new.
But... but... jQuery? :D
Anyways, in real-world development, jQuery is still the #1 go-to tool. A little above vanilla, but not too much abstraction. It's just right.
By the way, there's
- fetch to replace that old XHR. (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)
- Promises which should come with fetch, and also replace success and error callbacks in jQuery (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)
- document fragments to create DOM elements and do manipulation in memory. (https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...)
- The management will try its best to keep the person. Raises, counter-offers, benefits will be put on the table.
- The management will try its best to delay the leave until a replacement is found.
- A sudden increase of communication and praise from the management.
> How does the replacement process work?
It depends on the contract. Some companies can use the notice period as defense. Some can hold you for as long as 6 months, using that period to keep you as well as find and train your replacement. Some companies won't let you leave unless a replacement has been found and trained to a sufficient level. This goes as far as making you find the replacement instead of the management.
---
Normally, there wouldn't be a "solely-responsible engineer". If the startup was managed correctly, there will be at least one other person who knows what the other person is working on. That way, even if the weakest link falls off, the entire company doesn't suddenly tip over. Startup people have fancy names for these things. A team that knows a bit of what everyone else is working on is called a "cross-functional team". A developer that's part of that team is a "full-stack developer". It's just a fancy way of saying a developer in this team has more work to patch up management and HR issues like say, losing someone suddenly.
React has already been there for a while. It's probably winding down phase of its hype cycle. Everyone's getting accustomed without all the "wow, this is effin awesome. you should try it." going on.
Optional is great and I'm siding on building APIs on the user-land side if possible.
Unfortunately, having n different libraries basically doing the same thing is just annoying. This thing you call "competition" is just developers egos gone berserk. There's no point in building 2 things that do the same thing, unless it's definitely better (which is good) or unless the point it conveys is "I'm better than you" (which most devs are, really). I mean look at this guy who tries to overtake jQuery 10 years after jQuery started: https://github.com/drduan/minggeJS/blob/pr/95/README_en.md
That said, Lodash and Underscore should just merge. Zepto and jQuery should just merge. Immutable and Mori should just merge. Inferno and React should just merge.
That's because 1) npm isn't immutable. The owner of a package can delete the package on npm. 2) Developers (re)-download the entire dependency tree prior to build. A missing dependency down that tree will fail the download.
> Why did everyone else's code refer directly to that guy's repository, and not some centrally-maintained clone thereof?
The "repo" everyone's talking about is npm. npm is the centrally-maintained storage. What happened is that the guy pulled out his modules from npm.
> So if a project goes down, the package stays on the RH server and you can still get it anytime you want.
That's what everyone wishes for npm actually, for that package to live forever once released to npm. Sadly, again, npm isn't immutable.
But again, there's this suggestion of "bundling before release", making a dependent self-contained. That way, in the event a dependency is missing, the worst it could do is just paralyze the dependent's next build but not make the existing build unavailable.
If you have `foo` that depends on `baz 1.1` and `bar` that depends on `baz 1.2`, then the bundle will consist of `foo`, `bar`, `baz 1.1` AND `baz 1.2`. However, `foo` will not be aware of `baz 1.2`, `bar` will not be aware of `baz 1.1`. They work with their respective dependencies and all is well.
`foo` and `bar` should not even reveal implementation and should not even care of each other's implementation. What `foo` cares about is `bar`'s API, `bar` should care about is `foo`'s API, not their implementation, dependencies etc.
An analogy would be jQuery and it's dependency to Sizzle (which, coincidentally, is bundled with jQuery). Would it matter to you if jQuery 1.7 used Sizzle 1 and jQuery 1.8 used Sizzle 10? No. What matters to you is you're using jQuery, and what you see is a 0.x.x bump of jQuery, not the x.x.x bump of Sizzle.
Everybody is a Genius. But If You Judge a Fish by Its Ability to Climb a Tree, It Will Live Its Whole Life Believing that It is Stupid
- Einstein
> Completing assignments faster than me.
They're either really ahead of you, or they just ask on StackOverflow faster (probably the latter, definitely the latter). Besides, if they were really good, why go to a bootcamp? That doesn't make sense. :P
While coding speed is good, in real life, it doesn't matter. There are other things that matter besides speed, like code quality, maintainability, architecture. In real work, management takes care of you in terms of time. You'll always be given a reasonable amount of time to finish things.
> I was deemed incompetent and let go
Past is past. Let go and move on. Past mistakes, present experience.
> The bootcamp teaches Rails and javascript. I'm wondering - would a job in drupal have an easier learning curve? How would it be different?
I can say working with Drupal is pretty nice. Most of your time, you'll be site-building - configuring sites via an admin panel, looking for modules that satisfy some requirement, download themes, maybe tweak some CSS. The only time you get to write code is when you need to tweak something not built-in, or when you need to alter default behavior. For the most part, it's in PHP which shouldn't be that far from JS in terms of syntax and quirks. jQuery is built-in to Drupal, so as long as you know jQuery, you're safe.
If you have a Drupal job offer, by all means go for it. You'll have to grind gears at first, Drupal's documentation is terrible (I'll give it some slack, terribly organized) and the forums replies gap months (but hey, it's open source. everyone's a volunteer). But once you get the hang of it, you'll never leave it.