The web is a giant fucking pile of dog shit in 2016.
I made 3 manual edits to a css file to fix a couple of incorrect background colours in our web content the other day. I was a good boy and made a pull request for those same changes in the git repo.
Our developer explained that he doesn't actually edit the css file. He would have to work out the change in the hue (as a percent of the base colour) and update that in the sass file, then use gulp to compile a fresh version of the output css.
He said that this was a simple build process to get set up on my machine so I could do it myself in the future.
He uses a mac. I use windows.
4 hours later after hitting so many hurdles I finally got it working. I can't even recall all the issues, but do recall that I side stepped them all by moving to a particular version of npm which actually used a sane system for storing the dependencies.
With out that version of npm this simple build process required 15,000 files in my node_modules subdirectory in a structure so deep and convoluted Windows couldn't create them....
Of course now that I'm armed with the toolset to make these changes I've reverted to testing changes in chrome dev tools and emailing him requests.
You would think people learned a lesson about packaging every tiny item as a dependency with left pad, but apparently yesterday it was downloaded 16104 times.
Aaah, good luck. For me it's basically gotten to the point where if the build doesn't immediately work on Windows, I just fire up a Linux VM and work off of that.
And that's not just for front-end projects, but for open-source projects in general. Windows support is often really lacking in an environment where devs seem to use Linux and Mac almost exclusively.
so when you clone repo or edit it directly in github you don't have option to edit wrong file (compiled css file for example)
but i agree that js community has everything very complicated for learning
but it's not that bad for everyone that already knows how tings work here
But you ideally shouldn't have your CSS build product in the repo if you're using SASS. That would avoid the confusion of editing the wrong file (the compiled output artifact, which ought not to be in the repo).
That's when I knew things were about to get interesting :-)
I wouldn't say it's malice. I think they simply don't know better.
It can be hard to learn everything that goes into a big front end app these days but when used correctly all those tools are there for a reason.
You shouldn't use any of these tools just because people tell you to. If you can't see what problem something solves, then start at a simpler/lower level of abstraction until you run into that problem, and can appreciate the tool that solves it.
Of course, this advice doesn't apply if you actually need to write a production app, and aren't just playing around for learning purposes :)
Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.
WPF, XAML, iOS, Android, Qt.
None of them suffer from the same craziness of the web world.
I used to do web and don't miss it. Actually it was my experience in Web projects that changed my mind that web should have stayed HTML/CSS.
After a few years with a framework, for all it's worts, you know it inside and out, limitations and all, and you can work around them. For web stuff it feels like everyone excuses having a million and one solutions by shrugging it off and saying "figure out your problem then find what works for those problems". The issue being there are N frameworks for my problem and I only know N/2 of them well enough to even start evaluating if they solve it, and if there are limitations a new feature comes up against, I'm back to square one in searching for another little tool for this new requirement.
There's something freeing about only having a few solid tools at your disposal, vs a million smaller ones with divided mindshare, even if it can be limiting.
If you have problems explaining why features need their time, it's not about your frameworks, it's about explaining the clients in all honesty what happens. Or, if you want to get paid enough, you simply factor in some risks into your budget planning and up your budget. They don't have to know that you only needed 2h to get nearly everything up and running and 6h for that one sneaky feature. Use asymmetric information (https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...) to your advantage. It's not about the toolset, it's about your mindset.
In other words, all of the time saved to get to 80% is lost, and then some, because the framework can't do what my project needs.
I've seen this time and time again, with every framework I have ever used.
But I've never experienced this problem on projects where I'm able to choose my tools. I use Django and Vue.js with webpack and I can estimate the time constraints for each feature accurately using that stack which is most important for me.
Maybe you've used too opinionated frameworks in the past. If that is the case, loosely coupled frameworks like ampersand.js or very flexible solutions like Vue.js will be a pleasure for you.
In regards to the Pareto Principle: The 80/20 rule means that you need 80% of your time to finish those 20% outside the scope of your framework, not 20%, so your observation fits with this.
If you do keep up, you'll get amazing job offers.
If you manage to really be on the edge, you can give talks as well, expose yourself as a consultant.
That's much easier in JS than with Ruby, Python or whatever else.
The new problems I'm working to learn to solve are with ML, NLP, etc. I'd like to step away from web services completely soon, and just live completely with data.
Backend can be hard as well when looking for specialized stuff like Elixir, OCaml, Scala, Rust, etc. On the other hand, pure Ruby - Python - Java - C++ that's fairly common and not as likely to fetch high salary, since you'd be competing with a larger talent pool.
I've found for FE work, esp for someone with good sense for the visuals, typical off-shore contractors in Asia do not provide the adequate skillset
"Easiest" area of programming to get a decent job and enter the industry. It's so much easier to find a job in big cities if you know Angular or React. As long as you keep yourself up to date in frameworks and tools you can theoretically stay employed for a long time.
That said, I have heard of plenty of people who had done the above getting burn out or bored after about a decade.
Don't find it surprising that the author intentionally makes his/her story more complex than necessary.
For example, you can use "Typescript+WebPack" instead and ditch all the blah-blah on Babel/SystemJs, but that wouldn't help the naritive much, now would it!
I was talking to somebody at a place where they're throwing away a big custom code base in favor of gluing together a bunch of aaS stuff. Four years ago, the system was cutting edge. Then they had a big round of layoffs, and they only now can afford to do new work again. One of the big factors in the decision was just the cost of getting everything up to date. There was a bunch of failed flavor-of-the-week stuff that needed to be rewritten. There was a bunch of technical debt from using cutting edge stuff (e.g., library versions pinned to particular GitHub hashes, forks of libraries to get that one feature or work around that one bug). And there was just the proliferation of different technologies picked because they were the "best" for the local problem, but definitely not the best when you account for operations and maintenance cost.
I'm hoping that the roulette wheel eventually stops spinning and the JS world settles on something, anything where I can be confident that somebody can come back a couple of years later and be able to extend it without having to throw everything out.
What is worse, a lot of employers have already decided that if your app isn't written in React + Redux + whatever-is-hot-today, it isn't worth doing. I like to keep my stack fairly simple, and my approach apparently doesn't work.
I still do a fair bit of front-end development, but only when its on my own terms.
The front-end is harder IMHO, but as another poster mentioned, the opportunities are tremendous.
And in 2015 you would have been just fine learning Ember or Angular 2.
And in 2014 you would have been just fine learning Angular 1 or Ember.
And in 2013 you would have been just fine learning Backbone and Ember.
And in 2012 you would have been just fine learning Knockout and Backbone...
In nearly every circle of developers I know, they insist you learn plain, vanilla JS first. Jumping in Angular without knowing what a JS object is, understanding how closures work, understanding callbacks, or understanding how JS's "this" works in detail. All things someone should be fluent with before they go jumping into Angular and React.
Also knowing there's a HUGE difference between Angular (which is a full MVC framework) vs. React (which is just the View part of an MVC framework) is a small, but important detail for someone just starting out.
I would actually recommend React over Angular for a beginner, because (assuming Angular 2 here) they're going to have to learn Typescript too. That's a big undertaking.
A beginner could also use plain old ES5 with a JSX transpiler right in web page with React.
VueJs might be a better choice than both of those, but much more limited job opportunities.
That's totally fair and then I would completely agree with your comment.
From a pure computer science perspective, I feel the data structure, algorithms leveraged on the backend side has greater complexity potential.
While criticizing the current state of affairs, it
gives a nice overview of many of the emerging technologies
and how they fit together, even if for some tasks
it feels retarded to pull such an entangled mess of
You can then go insane diving into any particular one :)
Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
My preference, and I think it is born out by successful long-term projects, is to always keep everything to a minimum. A lot of people say things like, "that's not the optimal way" or "you could make the page load faster" or "you could integrate with xyz".
But, at the end of the day, you have to measure bang for the buck. Bootstrap - VERY high bang for the buck. Jquery, likewise. Pretty much everything else doesn't start yielding dividends until you are at a facebook-level application.
Which, frankly, is fine for Facebook-level applications. But the problem is that people are using these for everything, which is totally ridiculous. How they find people to pay for all of this is what really blows my mind.
Large companies love to get cool haircuts and wear torn jeans and talk about building fast and being agile and yet, they continues to build frankenprojects.
Again, I'm not familiar with flavor-of-week web dev stacks and I'm not defending all of it, but there are clearly steady-state benefits to tooling, even if the initial setup often ends up being a maze because it isn't in the critical path of core developers.
I think there is huge benefit to be gained from projects considering the aggregate bootstrap effort required to get the whole stack running. But I still think this fragmented, modular approach, even with the downsides discussed in this thread, is better than the likely alternative: depending and waiting on a company like Microsoft to deliver a monolithic development environment for which a Product Manager has spent literally years crafting and honing the bootstrapping experience before release.
As a matter of curiosity, would you mind unpacking this statement?
Not really sure if you mean to say the piece imparts a moral lesson. Or perhaps it relates to the writing aesthetics; Or something else
In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?
But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery.
All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about.
But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do.
If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
1. 'if' it's an actual app and not a web page with a smattering of interactivity
2. 'if' by 'take off' you mean becomes a moderately complex SPA
3. 'if' there's no alternative that is simpler and more maintainable (another excuse to plug intercooler.js here)
There aren't enough people saying "Are you sure you need a front-end framework?".
I've worked on several projects that had <insert framework> for no real reason other than the dev wanted to learn it. There is a threshold where it makes sense to use React or similar - but that threshold is being set way, way too low.
I guess I was also assuming that if the OP was considering using React in the first place, that they were doing more with jQuery than just minor interactivity improvements. But I suppose your concerns are valid if that assumption isn't true. I'm thinking app, not blog.
I saw a comment from someone a few weeks ago who knew angular but had never used jQuery. I was rather baffled how that had come to pass!
Angular was a huge step up in "you won't shoot your foot off-ness" and React is a step further. You still can, but you realize that you're loading the gun most of the time and can take a step back.
And that is really all this churn is about -- trying to make things easier and more foolproof. We've introduced other problems trying to solve the first couple batches of problems (accidentally using the development version of Reach on production is one I see a lot), but we'll get there.
The PHP ecosystem has had quite a bit of churn in the last 5 years too, but the yelling about it doesn't seem to be as loud since people aren't forced into it since there are alternate languages.
Having heard the same from other - "jQuery is OK, use React for new projects" - I'll focus on that then.
You don't need to know all the toolchains and crap if you just use create-react-app.
Is there a good tutorial out there for lapsed front-end devs?
So I threw out everything, and just started from HTML on Gitlab Pages. I've added on CSS, and just started adding in little JS functions. I can now (sort of) appreciate frameworks. React seems to be a popular choice.
Also, the site loads so much faster, esp. when HTTP/2 is not an option for you (because your hosting does not support it or whatever).
I won't argue, though, that a complex web app should be built on a proper framework.
The point of breakdown probably starts with Redux. There is no simple way of structuring multi-component pages in React. All is suddenly complicated.
When I think complicated, I think of code that's hard to understand, hard to modify, or hard to find things you're looking for in. In that example, everything is exactly where you'd expect it to be:
1) Where do I render / present my data? In the presentation components.
2) Where do I take data from the store and pass it to my presentation components? In the container components.
3) Where do I modify data in my stores? In the reducers.
4) Where are my reducers exposed to my container components? In the actions.
Maybe this kind of structure is overkill for a Todo list, but for a complex SPA, this kind of structure is useful and almost makes it _easier_, not harder, to find the things you're looking for. The app I work in is constantly growing and getting more complicated, esp. in regards to the quantity of features, yet I don't find it to be getting harder to go back and find or change things. I think this is due to the functional nature and design of React combined with the architecture we chose that makes this possible.
And in terms of LoC, that example doesn't seem to be much different from the Angular / Backbone implementations of TodoMVC.
I love the hand wavyness of this! Yes, you DO need to know the toolchain. Because if you don't, it is going to be murder on you if you need to track down why something isn't working.
Professional developers need to use professional tools and understand them deeply. There's no compromises here.
- I am a relatively experienced amateur programmer (with limited [nine months] professional experience)
- I can learn any new programming language, library, methodology, or whatever pretty easily
- I don't have any formal experience using anything of this newfangled stuff; like the author of the article, my frontend experience involves plain ol HTML/CSS/JS, with a little jQuery to make things easier
- nobody wants to hire me unless I have `n` years experience with newfangled language/framework/methodology `x`, `y`, and `z`
- I don't have a CS degree
Unless you're a massive operation like Facebook or something... just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it. If you're using stuff that I've never used before, I'll learn it.
I should be a more attractive hire than someone who has `n` years of experience only using `x`, `y`, or `z`, because the way I think about getting things done with computers isn't tied down to any one specific framework... but it seems that this isn't how hiring works in the industry right now... which is directly at odds with the rapidly-changing nature of web development!
As a result, I don't feel inclined to learn any of this new crap. What's the point? Apparently I should've learned it all `n` years ago, and it's too late now?
So they make up a bunch of gatekeeper requirements that allow them to filter out anyone that doesn't fit the mold early in the process. They're still likely to find someone who can do the work this way even if it means throwing out a decent percentage of other candidates.
It's messed up, but it's kind of where the lack of technical knowledge in HR, and the need to avoid any potential lawsuits have left us.
"Hi, so, your resume says you have nine months of experience?"
"Well yes, but I have countless personal projects under my belt, I designed and built game engines with teams of students..."
"Yes, but this position requires four years of professional experience."
"Well I still think I'd be a great fit for your company, I have experience with the specific technology stack you use, you can ask my previous employer..."
"Yes, but this position requires four years of experience, so, I'm sorry, but you don't meet the qualifications."
"Oh. Okay, thanks, bye."
I got a call about a job I'd applied to. The guy on the phone said I looked like a promising candidate, but my resume didn't list the start and end dates of my previous job (nine months total), as I'd accidentally sent an old version of my resume. I emailed the correct version of my resume, and nearly immediately got an email back, saying, and I quote:
"Needed 1+Years of Experience so if you can change the duration time"
After a few minutes of consideration, I edited my resume to change the end date of my previous job to be one year from the start date, saved it as a separate copy, attached it, and sent it back. The guy immediately replied asking me to verify that the 50k starting salary would work for me. (Before anyone says 50k is too low, rent is due and I'm desperate.) This was just last week and I haven't heard back since but this is the most promising opportunity I've been able to find after months of searching.
The thing is, I don't even want to do frontend web development. I want to work in game development, but apparently to get a start doing that professionally, I need professional programming experience on my resume to look good because those positions are so competitive. Okay, fine, I can do web development, front- or backend, I thought. That'll be great for padding out my resume, and, y'know, paying rent. But it turns out that landing one of these jobs is also really difficult!
What frustrates me about all of this is not so much my own position, but about the future of the industry. As time goes on, I think we're going to see more and more people take the path I took of learning stuff on their own instead of at college. Formal CS education is far from useless, but if this stuff's all available for free online, people are going to download it, play around with it, and learn how to use it... it just seems crazy to me that companies are hiring just-out-of-college CS graduates over people who have made a ton of stuff on their own over the years.
All of them were with no-technical-knowledge buzzwordy HR types who were very friendly and assured me that my resume and portfolio were great
I don't inherently agree that this is how it should be. I do understand that businesses want to minimize risks (don't hire bad employees for 6 months) while saving time (don't interview them in the first place). One of the easiest ways to achieve the latter is by having minimum requirements.
The rebuttal to that is always having a good interview process that measures the candidate on a personal level while also getting a feel for their technical prowess. This is another problem. Some people think all-day interviews are perfect for this. Others want to show up for an hour or two, white board something relevant, and call it a day. Some want take home project. Others demand that potential employers pay them if they're so keen on giving a take home project.
I don't think there is a silver bullet. I think there are objectively better ways than other when evaluating talent such as being flexible. For example, a new graduate will almost never have 2 years of professional experience. A new graduate may have an impressive GitHub profile filled with completed, demo-able projects alongside contributions to other people's projects. While not a direct substitute, this is a damn good indicator.
No one can seem to agree on the entire process though, so we're stuck with HR Henry and his checklist.
(Before anyone says 50k is too low, rent is due and I'm desperate.)
Depending on your location, $50k can be plenty, Where I live, $50k is great salary for a single person. Also, pay isn't the only thing that makes a job worthwhile. My starting salary was competitive, but definitely at the lower end. The work/life balance, however, came slightly before salary.
Find a way to speak directly to someone in engineering - preferably someone who is doing the hiring. If you can meet someone in person at a meetup that's best, but e-mail works otherwise. Offer to do a project for them to demonstrate your skills. Almost every company is going to have something that's not on the critical path that they could use help with. You should get paid for this - try to figure out what freelancers make in your market and price within it, but on the low end (don't try to undercut the entire market).
> [nine months] professional experience
> just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it.
I get why you think you can be productive. But a person with 9 months experience has no experience with long-term maintainability. Your definition of productive and mine are likely very different. And that you don't know that there's a difference means I can't trust you to write production code. You're in the "hazard" stage of expertise:
Novice programmers are great, and I've successfully hired them in the past. But that requires a context where they can work closely with experts who help them improve while keeping them away from doing things that feel productive but are long-term harmful. Left unsupervised, they can, with the best of intentions, be fountains of technical debt.
> the way I think about getting things done with computers isn't tied down to any one specific framework
This is a dangerous way to think. In software, everybody is bright. Everybody is a quick learner. If your operating theory is that you're just way smarter than those fools who have spent time learning something more deeply, you're going to keep yourself from advancing in your chosen work. To me, you come across like this:
> Apparently I should've learned it all `n` years ago, and it's too late now?
Find yourself a context where you can spend n years and dig in. Go make things. Go maintain things. Go find the edges of your knowledge and develop a little humility. Because without it, you're going to have a very hard time successfully asking people to give you a job where there going to have to give you a lot of help.
Professional experience matters. Plenty of people are amateur cooks, but that doesn't mean they can step into a restaurant and do well. My brother does furniture-making and carpentry for a living, and it's the same thing there. I imagine it's true for most professions. That you can't see a difference does not mean there is no difference.
If you really think you can handle the work, then I'd suggest you apply at places without "hiring departments". Find small companies, where the person you first deal with is the hiring manager. The more people involved in deciding to make an exception, the less likely it is to happen. But you'll have a much larger chance of getting that exception made if you can see yourself through their eyes, which is as a person who's probably going to need a lot of help.
2. Understand that rule 1 rules out 99% of tech companies.
3. (And I suck at this) Network. Network. Network. I truly wish I was better at this. I'm currently doing C#/Java/C++ (yes, it's that kind of project. It's been fun, but my interests are changing.) and want to transition to Python full time. I live in a mid size but rather secluded city with an absolute dearth of tech companies, so networking is extremely difficult here.
I have almost 2 years of professional experience but technically it's like '6 months 4 times' considering they were internships/contractual employment.
I've done projects with several frameworks and libraries on my own but not professionally. Regardless, recruiters/HR will tell me they're looking for people with "more experience" without being specific even though they're hiring for a junior level position.
In reality it seems more like they want to hire a senior-level developer and pay them at a junior-level rate.
I've actually heard a headhunter say that an open position they're looking for people to fill would like someone who knows and has worked with Polymer for 1-2 years. smh
I agree that the HR path is ridiculous. We can go another route because we are small. I don't know how you would balance the needs of large-scale hiring with the intricacies of tech at a big company.
Learning in the dev world consists of aimlessly screwing around with an undocumented, unsupported, glitchy web/server stack for many many hours unpaid after you've already spent 40 hours that week putting bread on the table.
The whining has less to do with the "learning" and more to do with the yak-shaving part of it torturing us endlessly in the off-hours. And, unlike in medicine and law, there is precious little professionally-written, detailed, helpful literature to help us along the way. There's just "quick install" and then a command/api reference. That is... not up to the level at which medicine and law have their industry practices & standards documented.
Not a valid argument, and won't ever be.
Plus don't forget our education isn't formal. Doctors and lawyers have it much, MUCH more standardized than ourselves. We the devs are pretty much do-it-alls that have to learn 95% of their skills on the go.
You won't ever hear me complaining about learning things on the go. I love it. What I hate however is putting up with the lame work of people who probably can't do much more in their lives beyond tying their shoes. That's what this thread is about -- partially anyway.
With Node, I can get quite far with just a couple of dependencies that install quickly. I don't need transpilation unless I want to use TypeScript or PureScript and I can target any version I want. I find it very fun to mess around with Node and a bunch of little modules.
I am slowly "transferring" back to server-rended pages using Node or Elixir. Probably not good for my employment (even in NYC most JS jobs are frontend), but whatever.
If I was learning JS right now and didn't care about employment I'd just learn Node (which just means learning JS really) and experiment with stuff.
It still feels to me like we're in the early days of node and the dev infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).
Be thankful, at least it's not 2013, the new-js-framework-on-the-front-page-of-HN-every-day era.
Seems quaint now.
The amount of time it takes to ramp-up on the technical knowledge isn't insurmountable. The main issue is bloat in both code size and dependency chain instability. On a slow connection, you might find yourself battling against your tool chain for half the day. In the case you actually hit a code problem with the underlying technologies, it's going to be hours if not days searching Github for the patched version of the module. If you actually are able to path the specific dependency, it will probably break something else.
I do have hope though. We are starting to see a lot of really cool Babel / React components and projects. I think with a bit more time, we'll get stability in the eco-system as there are less deltas to the underlaying code dependencies and the browser vendors catch up with ES7 features.
1 - I've never referred to myself as an "engineer" since I don't see myself as one, nor do I have an engineering degree. This includes the fact I do not have a four year CS degree either.
2 - Front end development has now split. Being a web "designer" means you know HTML5, CSS3 which includes LESS, SASS, PostCSS and other CSS pre-procssors
3 - Being a web "developer" means you're more likely to be a Javscript developer. Meaning you're familiar with Angular, Backbone (I know its soooo 2014 isn't it?), React and other JS frameworks. Every interview I've done in the past two years has almost exclusively focused on JS and how well I know standard JS. Closures, inheritance, debugging, etc. Nobody cares if you know much else other than that.
But this earlier spoof may well be based, intentionally or not, on the SOAP piece you linked -- which was a hit on HN 7 years ago (https://news.ycombinator.com/item?id=2079631).
Thus prompting the observation and related question: These three areas - front-end, deployment, RPC - seem to have engendered a churn in standard approaches, and a corresponding cultish devotion to certain toolkits -- leaving them open for satire. But yet, there is also a need for a guru to explain WTF to do, because a lot of practitioners need to get these jobs done.
So, what is the deeper parallel between the areas? E.g., a lot of corporate resources suddenly poured into these problems, and everyone is funded to come up with, and promote, their own solution?
No, wait. I made a webapp with React. While occasionally seeing Flux and friends mentioned, I was strong. I went with vanilla ReactJS.
I mean, those web stacks just get obsolete too soon. Your super tuned gulp setup will be obsolete in a year or two. What will you do then? Re-learn all new things?
It seems to me that there is a frontend development stack bubble coming. When I had to change bootstrap's base font size, I had to download and learn awful amounts of stuff. Which is on my machine. And I will never use it again.
Make REST work the way it was intended, supports CSS transitions, request indicators, etc.
Good little library that eliminates a lot of complexity for web apps that don't need all this junk (most of them.)
I've got a basic app with JSON end points already created. I was going to give VUE a go but after looking at intercooler I'm going to create an alternate set of /IC/* URLS and send out HTML instead. I'll soon see how it works for this task.
Aaaaaand...we've come full-circle now:
Intercooler depends on JQuery, version 1.10.0 or higher.
I don't have any real problems with jQuery being in the mix for intercooler. Even with that, jQuery appears to be an underlying library used for convenience rather than a library an intercooler coder would have to know and code against.
I do appreciate the irony when taken in context with the original article though.
I prefer "jQuery soup."
All that stuff is actually required to build something maintainable, especially modules. React is not a silver bullet, but nowadays SPA and components approach should be familiar for any front-end developer. I like Typescript was mentioned there.
Just start with this example and customize to what you want to do:
I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?
There's a vast difference between everything described in this article and using a framework.
If your fancy little table is part of a large app, or even a simple app, it is much easier to implement the entire app using a framework like Angular. The model view concepts really help to tie things together.
Even for trivial SPAs it's often easier to roll the basic functionality yourself. Flipping over to something like Angular introduces technical and cognitive overhead that often isn't worth the trouble for something simple.
The huge frontend frameworks have an upfront learning cost and tend to be unfortunately leaky abstractions, but they're still much easier to maintain than a jQuery/JS mess with a bunch of DOM-manipulation code and HTML strings living right next to the business logic. They at least force the code into an understandable architecture and separate the view from business concerns. Experienced developers know how to structure their frontend JS already, but novice ones--the same ones that would feel the pain of learning a framework/ecosystem on top of JS when they first try to pick it up for an SPA--almost certainly won't.
Remember, they don't know which part of the framework you are using or not, or which parts are important or not, so even if you are using it for one little thing, they probably have to learn most of it to understand how it interacts. Since so many frameworks overload standard functionality, it is impossible to know how a framework interacts with your code until you know all of these things.
Using 20 frameworks is about as efficient use of your time as having one you built yourself. The sweet spot for a medium-sized application is using 2-4 (maybe a few more if they are really standard or do really specialized functionality - i.e., a PDF library) for the most critical components, and still maintaining the remaining quirks yourself.
So, for example, Ruby-on-Rails + Bootstrap + JQuery goes a very long way, and doesn't put an undue burden on people trying to get to know your code.
If your application become sufficiently complex that it can't be easily grokked by a decent dev, that's when you know it's time to switch.
Until then it's just over engineering (which the JS community admittedly loves).
I estimate that every 20% that a codebase grows it needs some amount of refactoring. Definitely anything that moves from skunkworks to production will need some pretty heavy rewrites, and will probably need a framework that better meets its newer needs. The question is how much cost was sunk in getting there. The refactor will have to happen no matter what.
Guy A believes his custom design is simple enough to comprehend by anyone. Guy B doesn't agree.
It doesn't really matter at the end of the day. If you work in a team environment, the toolset will be pre-determined already. You don't have a choice.
Seriously now, I gave up front-end stuff when it began requiring me to use Node to bundle files together, and find it terrifying to see Yeoman used as a code generator for non-JS runtimes and frameworks... building software atop quicksand (be it frameworks or libraries) that shift every week is insane, and it feels like the modern day version of just-in-time job security.
I think whoever said this referred to the various IPC methods on Windows, but I do not remember for sure. Seems like some things never change.
The following is inspired by the article “It’s the future” from Circle CI.
You can read the original here (https://circleci.com/blog/its-the-future/).
JS, for the oversimplified thing it is, is just systematically overextended with the loads it has to carry now. No framework on earth will make that go away. And neither will ES6.
The syntax is stable, clojure is extremly well designed, the ecosystem a lot clearer and tools - well you have lein as the main one and that's about it. On top of clojure, you get google closure for free and can optimize the hell out of it with advanced mode compilation out of the box.
And that's the 'vanilla' experience! No separate library required! You can still interface with normal js and npm modules of course but you find yourself using npm install a lot less.
All major tools have cljs wrappers that are just a joy to use (looking at reagent (react), re-frame (redux), om (react+graphql)
Actually, not yet completely solved problems in terms of consensus how to do things stay here: delay loading (login form/admin panel/main app code or features separation), component assets dependencies, modular CSS, and, of course, frontend and server side architectures with CycleJS, Elm, SAM, Redux, Angular 2 as candidates but those yet have unsolved problems: either work slow (and making simple app's size more than 1 MB zipped) or you have to write some boilerplate of source code lines. And comparing side there, of course, ability to componentise infinitely and hierarchically. And for accessing data GraphQL emerges as hot modern technology. And a lot of other cool things to keep tracking every day... It never stops, growing larger and allowing to reuse all third-party dependencies (beside of components - every team mostly prefers writing their own, because those play better with their chosen software architecture) and constantly rewriting your own source code.
It is also a discipline that lowered its entry barrier a lot, and now coding camps are producing a deluge of graduates, all of them attracted by the promise of a 6 figure salary.
Even if pessimistically only 10% of them are good, they graduate every 14 weeks compared to 208 weeks for a CS graduate.
Here is the fundamental essence of the article that drives me nuts: the assertion that the reason someone would move to one of these new technologies is because "it's trendy" or "everyone is doing it", "or angular is so 2015", "it's for hipsters". This is the standard mantra of old people everywhere who are too old to learn new stuff.
If the guy would have taken the time to learn the purpose of these tools, their pros and cons, and why one would choose to use them or not use them, that would be interesting. But that would take a bit more time. And actually learning something new.
While I emphasize with old people who feel the world is moving too fast (I am one of them), I have no tolerance for the basic anti-logic of the article: the assumption that new technology only exists because of trendy hipsters who just like change for the sake of change. This logic only exists to soothe the mind of old people who don't want to learn new things.
What are the 2 or 3 top-priority things I should get started with, if I have experience with Django/HTML/JQuery, and want to expand into more advanced frontend programming?
One day perhaps React and Redux will be replaced by something else, but I think the strategy of a GUI functional layer consuming a stream of events is here to stay, and I wouldn't be surprised if it spread to native app design.
I mostly write desktop+native mobile apps, and without doubt my JS skill is very rusty :(
Any suggestions how to catch up with JS trend nowadays?
JS for web dev is pretty much unavoidable, right?
You don't _need_ react to build a cool site in 2016, but if you're dead set on that, then this piece is a good intro to the set of questions that arise!
What Not to Learn http://gedd.ski/post/what-not-to-learn/
Never learned browserify, barely grunt and bower, happily forgot thorough knowledge of gulp. Actively pushed out all of the awfulness of angular.
> Oh, like Angular!
IMHO if you know about those you pretty much most of the terminology the "js guy" is using, personally speaking i know Angular haven't used yet bower in any project.
jQuery had the DOM covered and is in fact now redundant itself and could be managed with a much, much lighter lib that spends a lot less time normalizing assuming you're dropping support for browsers even Microsoft no longer covers.
LESS and SASS were good for vars and should have stopped there. Standard browser support is finally in the works for that. But you certainly don't need both and for FFS you're just making an unmaintainable styling mess using all of the other features, especially (noob, please), nesting which needlessly adds to selector count like nobody's business.
We do NOT need to ASP/JSPify the DOM. Keeping content/structure code separated from the behavior code was the reason proper front end devs were running circles around Java/ASP.net devs. What the fucking fuck is the point of adding your own custom tags to HTML, which already had a perfectly serviceable approach to binding behavior to it? Or creating an XML-like syntax you mix/match directly with your JS?
Silicon valley noobs, please. I had lazy loading scrollable tables that could handle 50,000+ lines of data back when Google Docs was choking on 2,800. This shit is not hard. Stop wining and spend the time you apply to learning frameworks with next to no core technology understanding to actually learning the technology you have before you start adding pointless layers that solve nothing on top of what's already there and you'll be shocked at how not-hard it can really be.
Or let's not. Let's load a massive freaking ridiculous CSS and JS library by the Twitter devs, because, yes, surely they know through their work with a site that essentially boils down to a single text area, a great deal about handling complex layout and UI concerns.
AMD for a web app? Okay, I can see it, certainly for non-trivial SPAs , which NOT EVERY SITE NEEDS TO BE. But first, how complicated is this web app? If not-very, why were people struggling with linking scripts in the right order? Why did they need to link so many damn things to get the job done in the first place?
And FFS, it's just "data-binding." Calling it "Two-way" is redundant and makes you sound like a jackass who doesn't know what the fuck is actually happening. And it's just a pattern. And not a very hard one to implement.
Thanks a lot assholes.
I think the key takeaway here is: a) requirements suck always, b) figure out what the real problem is that needs to be solved, c) fashion your solution to the unique needs and culture of the team you are a part of.
Computers are hard.
I’ve been specializing in front end stuff for 4 years and it still took me a month to master the react ecosystem. It’s better than anything that came before it though by a landslide.
People whine a lot expecting everything to be easy. There is a laundry list of classic cognitive distortions present in these types of articles.
If this is literally your only requirement and no new features will ever be added: “create a page that displays the latest activity from the users, so I just need to get the data from the REST endpoint and display it in some sort of filterable table, and update it if anything changes in the server”.
Which I highly doubt, but let’s go with that premise.
What you’d really want is to be step back and look at the needs of the app. The real needs are websockets for real time, and a way to tail the oplog of the database you are using to get the latest data pushed without needing to have the websocket proxy you’ll setup poll on the server side.
The front end implementation is fairly irrelevant here, IF nothing ever changes ( yeah right ).
If that is truly the case ( it’s not, believe me ), then just use a jquery datatable plugin which updates it’s data when new websocket data comes in. That’s like 100 lines of code, done.
If you’re using mongo it’s not too hard server side because you tail the oplog, the way meteor does. If you’re using something else you might have to poll server side to get the new data, which is honestly the hardest part of this problem. The front end of this is not the issue frankly based on the requirements presented.
This is IF this is all a one off project that never changes and will never need new features or bugfixes.
If it ever needs to be changed, you do benefit a lot from using more modern technologies so instead of a lump of jquery spaghetti you have clean component api boundaries which can be easily unit tested and modified in isolation without breaking other areas of the app.
Every situation is different.
As presented, this is more of a server side problem than a front end problem. What data stores are you using, how are you going to get that data in real time, how are you going to set up a web socket server, how are you going to scale said web socket server etc.
I think that blog post comes off as attacking the wrong problem and complaining that computers are hard. It doesn’t appear the requirements were clearly understood and evaluated. Picking the right tool for the job is really a thing. Dogma is dangerous in software for sure. On that point, I agree.