I made a pretty sophisticated Angular app a few years ago which is still selling and being maintained by other devs on my team. I started helping my friend with a new app and realized I'm already obsolete. Screw frontend development, I'll come back when things settle down.
My previous job was on a product that used CoffeeScript and Backbone. As a stereotypical front end hipster, I was worried at first. I thought: "This is really old stuff in JS time. There are shiny new things out there". But I soon saw that while it would be more fun to use a new framework/language, the old ones are _totally fine_.
CoffeeScript was last updated a week ago. Backbone was updated several times last year and 1.4 is expected some time soon. There are online communities, there is documentation, there are answered questions on stackoverflow. Yeah, everything feels a bit old, but there won't be breaking changes to the API every few months and that blog post from 2015 that solves your exact problem is still useful!
Try looking at it like Angular is a language, not a framework. Sure, there are fancier ones coming out all the time, but that doesn't mean you have to switch every time that happens. The one you know has a bunch of apps built in it, you can still learn about its intricacies and there will be jobs for you for quite some time.
People are less and less understanding of the fact that nobody lives in a vacuum and all our actions affect other people. They're stressing individual liberties, which you see in the mainstream political opinion of "if it doesn't directly affect me then why should I care?", and that same guiding principle is also pushing developers to make gigantic changes without any regard to the waves, splashes, or ripples they make.
I work for a company with a couple of heavy Angular-based apps.
They are pretty easy to support/extend for anyone with a decent level of JS knowledge.
The backend API they are talking to and some of the business logic in the apps is kinda tricky but that's not angular's fault per se.
The downside is for candidates looking to add a hot shot tech to their resume, Angular isn't all that sexy, but for anyone with JS knowledge willing to spend a couple of days getting up to speed with the app itself (the "tool stack" is minimal - npm, grunt, bower, browserify and since it's an existing app they are learning by example) - this is almost a no-brainer.
> JavaScript will settle, and hopefully, CSS will erupt and everyone will cry fatigue until it settles.
Sounds pretty accurate. My perception is that a large part of the JS community has started to settle on React with Redux/MobX for state management.. Facebook also really lowered the barrier to entry for React with create-react-app. CSS is still up in the air a little bit, with many different solutions still being used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components (which is very promising, but lacks features like universal rendering out of the box).
Toolsets change but the core principles are pretty stable. I've been around for all the paradigm shifts. When browsers first had DOM APIs and CSS. That was when FE dev first became a dedicated job. Since then we've just been layering more and more abstraction on the same stuff.
I'd argue that front end development tools are complex and varied because the craft itself is complex and varied. Try to strike the optimal balance between usability and fine control. It's not easy. How to welcome newbie developers with intuitive tools while not frustrating experienced ones with blunt instruments. Imagine all the schools of thought for how to best achieve this delicate balance. Not to mention beauty and elegance in design.
Front-end is not fundamentally complex at all, the only complexity comes from ever changing tools and techniques. I occasionally create websites (approx. one or two per year) for my own or family/friends use and every time I have to learn everything anew, because the tools I used a year or even several months back are no longer around or have changed beyond recognition.
Just take information there with a grain of salt. The what to expect in 2017 section says that web components will never gain traction where in fact one of the biggest enterprises in their industries adopted them already: Github, Slack, Comcast, USAToday (Ganett), ING, Coca-Cola, Electronic Arts, General Electric, Google, Youtube and others.
The current growth and adoption looks very bright, chrome, opera and safari already shipped 1.0 versions of most of the spec (so no polyfills are needed), firefox is close behind and edge is implementing right now.
If this is not traction then I'm not sure what is. I'm not even accounting for other libraries/frameworks like x-tags, bosonic, svelte and others.
Have you used Web Components as part of a large project? What has your experience been?
I'd love to start pushing them to my clients, especially non-tech companies who can't afford to rewrite all their code every time a new framework becomes the fad, but I'm still kinda unconvinced. I'd love to read some real-world case studies.
I find this surprising because all I hear about are React/Angular/Vue.
At this point, I am likely to stick to React because of the support and community. But I could see myself using web components if it reaches critical mass.
There is mention of mobile devices as early as page 8. There are 31 uses of the word "mobile" in the document. The document does not tell you how to build a website, it tells you about the tools you can use to do so reading as a series of lists linking to those technologies and a series of graphs. If you want to know about media queries for example, you have to follow the links. It's not meant as a PDF version MDN or W3schools.
edit: not usually one to complain about downvotes, but the document is literally what I described it to be. So, why?
I did LAMP+HTML+JS+CSS stuff back in the day, but most of my work and hobbies over the past six years has not involved front-end. I only recently got back into the scene. I've dabbled with React and crew in quite a few hobby projects now and, at this point, I just find the whole modern front-end development stack completely wacky.
I always liked Javascript as a language, but like everyone else had the scars to show for its thorny bits. Looking at the modern stack from afar left me fantasizing about all the painful points in Javascript being fixed. ES20XX, Babel, webpack, npm. Wow!
To be honest, a lot of the modern stack _is_ nice. But for every step forward these tools take, they take two steps back.
We have a nice package manager, npm, yay, but what happens when I `npm install -S bootstrap`? Nothing. Oh sure, it installs it, but how do I _use_ it? It's tossed in node_modules, where there's no sane way to reference it. I ran into this problem immediately, on my very first hobby project. It's now two years later, 2017, and it's still a problem that requires googling around, sifting through old answers, and finding the hack that I find least painful.
Breaking up libraries into manageable sub-packages. Sounds great. It's fundamental to strong development. But usually you have a master application/library that references all the pieces, if the pieces were meant to be part of a coherent whole. But front-end devs? shrugs You just have to include everything by hand. Has seriously no one looked at their package.json in a simple TODO app and said "Something is wrong here"? How is a 20-30 line list of dependencies normal for the most basic of applications? It isn't. It's isn't maintainable. No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago.
Fancy new JS language features are nice. `for of`, `for in`, filter, map, etc. But seriously I can't use `<SomeThing onClick={this.handleClick}/>`? I have to use binding magic, special function definitions, etc? Because _nobody_ has to register event handlers, right? Geez. And why did they spec a standard for classes, finally, but not static methods and types!? That had to come in another version later, leaving yet another legacy of out-dated documentation?
Webpack, like everything else, is an improvement by the numbers. Writing modular javascript and getting it packed into a bundle is nice. Almost like a real programming language! But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done. Break that one tool into sub-libraries/sub-tools underneath, I don't care, but when I'm building fancy Uber-for-breastmilk Web 2.0 SPA, I'd rather focus on UX than spending my evening configuring compilers to what should be their defaults.
The most frustrating thing, and a common theme, is the amount of times I need to Google things while developing with the modern stack. "Oh, ummm ... how do I export/import?" "How did I configure webpack last time?" "Errr ... how do you include a bootstrap theme?" "Was it `in` or `of` to iterate over values...?" "How do you filter in place? Oh, you can't ... okay..." A lot of that sounds like basic stuff, like "How do I export/import", but ya know what? The way it's implemented in modern JS is just not intuitive. Call me dumb if you want, but I've dealt with a _lot_ of languages in my time, and JS is the one where I cannot possibly remember the exact magical incantations for specific kinds of exporting and importing. And really, that's how everything is. It's just cryptic and non-intuitive. The underlying concepts of any of these major tools or systems is sound. The implementations are gibberish.
As much as I'd like to say "sorry for the rant", I'm not. Something is horribly wrong with developer culture if this abomination is what we've created. There's no excuse for it. I've heard people argue that all of this is just a result of front-end being in-between stages of its life, and that things will eventually settle down and be stable and usable in a few years. But you know what? Rust, a completely new and modern programming language, went from nothing to a thriving ecosystem in just a matter of years. It was driven by Mozilla, hardly the largest company. Meanwhile MASSIVE companies like Facebook, Google, Amazon, etc have given us the "modern front-end". There's no excuse for the ecosystem to be in this state.
"But you don't have to use all those libraries and tools!" Of course not. I could just LAMP+HTML+JS+CSS it up like the good ole days. It worked then, it works now. But it frustrates me that there exists tools that _should_ be better. npm _should_ make life easier. ES2017 _should_ make Javascript a better language. I tried out these tools for a reason. Old school development was painful. Javascript with modules and packages, reactive UI, state management, etc. It's all awesome! I'm not messing about with the tools for no reason.
Imagine if I sold you an automated potato peeler. "It'll peel the potatoes for you in seconds!" And it does! But turns out you spend more time cleaning it than you spent just peeling potatoes the old fashioned way. That's what the modern front-end tools are like. They take the painful parts of old-school front-end and make them easier, but they add tons of busy-work elsewhere that ends up making things a net negative.
> But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?
Give a try to Vue.js, you can do exactly this. This framework reconciled me with frontend development after I discovered it on HN. Let's say you want to build a custom button with a special functionality and reuse it, like a button that logs when it has been clicked. Simply create a component like this (it's almost self-explanatory):
There are 3 sections in the file, one for the HTML template, one for Javascript code, one for CSS style. All this belongs to the same components, so the methods you defined in the javascript code can be called directly from the html template as you wanted.
Once your component is ready, you can use it in other files, and in a damn simple way:
There should just be one tool, one command. "modernjs build". Done.
You seem to be building an argument based on the idea that there's "one true way" to write web applications. There isn't. People have very different ideas about what's best. While ostensibly different tools do the same job, they take quite different approaches. For example, take "gulp vs grunt vs make vs npm" for the build process. gulp uses "JS with a framework" for config. grunt uses json. make uses unix-y scripting. npm uses JS but plain node.js without a framework. Those are opinions, and there isn't a "right" one.
Suggesting there should be one tool for compiling web apps is a bit like suggesting there should be one C compiler for compiling C programmes. There can only really be one tool if there's only one way to do things, and that's simply not the case. With different approaches comes different tools.
But, all that said, it doesn't matter to an individual developer. Choose the tools that suit you, learn them, and be happy. Whatever approach you take to development is far less important than writing software that works for your users.
That was similar to my failed attempt to make an app with Meteor. Not having much free time I seem to have started at the wrong time so that halfway into learning the framework and applying it to my own project, Meteor got an update. Being still in the learning phase I updated to be working with the latest stable version, something which broke the app, so I spent time fixing that, then the free hosting tier was dropped and for a hobbyist who was making an app that was guaranteed to never generate revenue ever ever, it became too expensive to host in comparison to a traditional $10 host with a mySql DB. And what was I doing anyways? Meteor Blaze? Was that the correct choice? Or was Meteor & Angular a better choice? Or was Meteor React the way to go? Or if I'm using Angular or React why am I using Meteor? Ended up with so many questions about whether or not I was using the right stack for me, and as I said, not much time to work on it so looking for something that wasn't going to be abandoned in 6 months time, in the end I just gave up on that project.
It doesn't help either that these js communities are splintered around every tiny issue and forked every other week (mean.js! is where I started the whole process). The feeling that there is zero permanence one week into a project does not inspire confidence either in my own project or the tools I have chosen.
DHH recently posted a comment on Quora about why it's still valuable to learn Rails in 2017 [0]. I don't agree with everything he says, but he is right that the Rails ideology was a big thing for web development in the '00s. Yes both Rails and Ruby have their issues, but if you look at what was around before it was a breath of fresh air.
I keep hoping the JavaScript community will have the same epiphany, but so far I'm still dreaming. Yes there are boilerplates that give you something working out-of-the-box, but still you need to keep up with which boilerplate is the latest and greatest. I'd argue Rails being so opinionated was one of the reasons for it's success.
> No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago.
If it hurts, don't do that then - put all your build stuff and devDependencies in a separate module and install it into your next project like any other development dependency, adding new capabilities as you need them and bumping the version number when you need to like any other tool. You can start doing it yourself [1] or use one someone else made earlier [2] - there are an increasing number of these toolkits about.
> But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?
You can do exactly that if you're using React or one of the many libraries which use React-like conventions (Preact, Inferno, Mithril.js etc.), so just use one of them.
> But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done.
You don't have to, and there are lots of tools which will take care of this for you (see [2] again). That's the exact same workflow I wanted, so I created it for the types of projects I'm working on [3] - it doesn't take much extra effort to turn your own preferred build setup into a command.
As a junior dev, that list almost makes me want to run to the hills...where I will presumably stumble upon another similarly monster-like list telling me all the things I need to learn to become [insert job role here].
Hint: Move to the backend. Building the APIs that crunch SQL into JSON for the react/angular/fad of the week folks to consume is much easier, and the half-life of your framework and language knowledge can be measured in years, not months.
It's a nice little book. Normally these things can be a bit hit and miss with the way the authors opinion of code structure seeps into them. You often end up with a bit of a 'this is wrong' mentality when in fact there is nothing wrong at all - thankfully they seem to of avoided that with this one.
Back in the JSP/ASP/PHP days, everyone was basically a full-stack dev. Because of server side rendering and direct DB access etc. I'd guess people who have more than 5 years of experience come from that direction.
So they aren't that rare.
But doing just one thing is easier.
When I do back end stuff, I have to think about scalability and API design, which is hard enough in it self.
When I do front end stuff, I have to think about information architecture and perceived performance.
I can do both, but I don't have infinite time, so I focus on the things I like the most, which is the front end :)
No I think all devs has to be more or less full-stack today.. When I think about a "full-stack dev" I think about someone with T-shaped skills. Aka specialist in one area (web/backend/devops), but knows a little bit about everything. Not an expert but knows enough (or takes the time to learn) about e.g. data structures, time-complexity or even css quirks to make educated decisions and participate in engineering discussions.
Quality full stack developers are rare. People who understand nuances of React / Angular / Vue who also understand nuances of MongoDB / PostgreSQL who also understand nuances of AWS / Azure / Google Cloud are rare.
Generally they will be storng in one and weak in another.
I see people everywhere complaining about how frontend development is moving too fast, and stories like mrits.
In 2011 I was sales manager in Mexico, doing WordPress sites for free on the side just for fun. In 2012 I migrated to the US with my family (legally). Then I worked in maintenance for 6 months until they fired me because I couldn't talk English.
After that I decided to try to live from building websites. I started to learn JavaScript and CSS, because already knew some HTML.
So I landed some clients as freelancer doing fixes on old sites, updating WordPress. When I landed my first WordPress site from scratch I didn't know how to do it, so I bought a book on the topic and used the gig as practice while reading the book.
I was able to maintain my family doing responsive WordPress sites. Then I started to get issues with all the grid frameworks and stuff, it was too complicated to make a simple website responsive.
So I started to do what everyone tells you not to do: "don't reinvent the wheel". I got myself to build my own grid, I did it, and I still use it Today. The process was painful because I didn't knew any real CSS so forced myself to learn it, when I got it done I was very confident I could do any layout in CSS.
One freelance gig I got was a SEO tool to count the amount of words, paragraphs, syllables, etc. of a given text, it was really exiting, because I knew I had to learn JavaScript to do it. At that time Backbone was really complicated for me, so I did it but really mostly copy/pasting stuff, I was happy with the result but not with the methodology. One thing I really learned from this project, is how to setup my development environment with Grunt.
So at this point I knew enough CSS and how to setup task runners.
From 2013 to 2015 I did only freelance work, then I got a full-time job at a small advertising agency, doing WordPress sites.
I was able to get my paycheck doing stuff that wasn't complicated for me, get a PSD, make it a responsive WordPress site (with the grid I did) and done. So I was able to learn JavaScript on my free time, so I did what worked for me in CSS again, go a reinvent the wheel.
I did my own "Backbone"-like framework, and was able to learn about Object-oriented programming and how to do it in JavaScript using prototype inheritance. Then I found out about React, and started using it too, learned about functional programming, pure functions, immutable data, declarative syntax.
At this point I was using Gulp, Sass, Babel, NPM, learned how to use the command line too, Vim, Tmux, was using Linux as my primary OS, and other very cool tools.
So in 2016 I landed an interview for a company where the job title was frontend developer, so for me was like no more "make my logo bigger" website clients. I got the job, Today I do only JavaScript using React/Redux/React-Router, I learned Vue.js on the side and learned Python too, so now I can do my own backend using Bottle/Flask on my freetime, learned about MongoDB, Postres, SQLite.
And these days I'm building my own virtual dom implementation to understand better how it works. And yes, a new JavaScript framework gets released everyday, and yet I try to use as many as I can, spend a couple hours building a todo app, reading the source code to see what I can learn from it, etc.
- frontend development moves fast, get with it. Don't expect to learn something and keep using the same shit for ever.
- learn JavaScript, not frameworks. If you understand the language you are going to be able to understand any framework better
- if you want to learn, reinvent the wheel
- avoid the hype
- if you are freelance and need to make a simple app and you are comfortable with jQuery, go fucking do it in jQuery and don't mind about the new cool stuff yet.
- Backbone, Angular, Ember, React, Vue, or Preact? Whatever, when I open the source code of a project built on any of those frameworks I only see JavaScript patterns, that's it.
If you get a job and they are using something you don't like or something you don't know, read the documentation, learn the basic idioms and try it. Again, at the end, it's just JavaScript.
I mean, I was 29 when I started my journey, no English, no CSS, no JavaScript, no knowledge about software development good practices. Now I'm 33 and very happy with my job as frontend lead developer.
The current front-end web stack today is not the answer, I think that is not so controversial except to the most die-hard fanboys. Most of the contents in this handbook are going to be worthless in a year.
Most front-end work is repetitive, with some minor variations. Rather than a framework, I think that perhaps an expert system for making web apps that is basically an interface for metaprogramming, would be a vast improvement over the current tech.
[+] [-] mrits|9 years ago|reply
[+] [-] MatekCopatek|9 years ago|reply
My previous job was on a product that used CoffeeScript and Backbone. As a stereotypical front end hipster, I was worried at first. I thought: "This is really old stuff in JS time. There are shiny new things out there". But I soon saw that while it would be more fun to use a new framework/language, the old ones are _totally fine_.
CoffeeScript was last updated a week ago. Backbone was updated several times last year and 1.4 is expected some time soon. There are online communities, there is documentation, there are answered questions on stackoverflow. Yeah, everything feels a bit old, but there won't be breaking changes to the API every few months and that blog post from 2015 that solves your exact problem is still useful!
Try looking at it like Angular is a language, not a framework. Sure, there are fancier ones coming out all the time, but that doesn't mean you have to switch every time that happens. The one you know has a bunch of apps built in it, you can still learn about its intricacies and there will be jobs for you for quite some time.
[+] [-] ChristianGeek|9 years ago|reply
If you want to base your future on something you already know, you're in the wrong profession.
[+] [-] k__|9 years ago|reply
I met many people who bet on it, but most of them, even the 'fanboys' didn't seem to be 100% convinced of it.
"We panicked multiple times, bit it always turned out we were wrong and just didn't do things the Angular-Way"
Ember, for example, is kicking it for a much longer time, even with fewer ppl using it.
[+] [-] sdegutis|9 years ago|reply
[+] [-] ChemicalWarfare|9 years ago|reply
The downside is for candidates looking to add a hot shot tech to their resume, Angular isn't all that sexy, but for anyone with JS knowledge willing to spend a couple of days getting up to speed with the app itself (the "tool stack" is minimal - npm, grunt, bower, browserify and since it's an existing app they are learning by example) - this is almost a no-brainer.
[+] [-] iagooar|9 years ago|reply
Now seriously, how's the front-end progressing currently? Has the pace become a bit more humane?
[+] [-] hakanito|9 years ago|reply
Sounds pretty accurate. My perception is that a large part of the JS community has started to settle on React with Redux/MobX for state management.. Facebook also really lowered the barrier to entry for React with create-react-app. CSS is still up in the air a little bit, with many different solutions still being used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components (which is very promising, but lacks features like universal rendering out of the box).
[+] [-] tootie|9 years ago|reply
[+] [-] rpcorb|9 years ago|reply
[+] [-] kbart|9 years ago|reply
[+] [-] romaniv|9 years ago|reply
[+] [-] ergo14|9 years ago|reply
Just https://www.webcomponents.org/ reached over 500 reusable elements, just polymer slack channel is now 6,5k users.
The current growth and adoption looks very bright, chrome, opera and safari already shipped 1.0 versions of most of the spec (so no polyfills are needed), firefox is close behind and edge is implementing right now.
If this is not traction then I'm not sure what is. I'm not even accounting for other libraries/frameworks like x-tags, bosonic, svelte and others.
[+] [-] GeneralMaximus|9 years ago|reply
I'd love to start pushing them to my clients, especially non-tech companies who can't afford to rewrite all their code every time a new framework becomes the fad, but I'm still kinda unconvinced. I'd love to read some real-world case studies.
[+] [-] arvinsim|9 years ago|reply
At this point, I am likely to stick to React because of the support and community. But I could see myself using web components if it reaches critical mass.
[+] [-] sjcrank|9 years ago|reply
[+] [-] Nimsical|9 years ago|reply
Doesn't inspire confidence.
[+] [-] kagamine|9 years ago|reply
edit: not usually one to complain about downvotes, but the document is literally what I described it to be. So, why?
[+] [-] fpgaminer|9 years ago|reply
I always liked Javascript as a language, but like everyone else had the scars to show for its thorny bits. Looking at the modern stack from afar left me fantasizing about all the painful points in Javascript being fixed. ES20XX, Babel, webpack, npm. Wow!
To be honest, a lot of the modern stack _is_ nice. But for every step forward these tools take, they take two steps back.
We have a nice package manager, npm, yay, but what happens when I `npm install -S bootstrap`? Nothing. Oh sure, it installs it, but how do I _use_ it? It's tossed in node_modules, where there's no sane way to reference it. I ran into this problem immediately, on my very first hobby project. It's now two years later, 2017, and it's still a problem that requires googling around, sifting through old answers, and finding the hack that I find least painful.
Breaking up libraries into manageable sub-packages. Sounds great. It's fundamental to strong development. But usually you have a master application/library that references all the pieces, if the pieces were meant to be part of a coherent whole. But front-end devs? shrugs You just have to include everything by hand. Has seriously no one looked at their package.json in a simple TODO app and said "Something is wrong here"? How is a 20-30 line list of dependencies normal for the most basic of applications? It isn't. It's isn't maintainable. No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago.
Fancy new JS language features are nice. `for of`, `for in`, filter, map, etc. But seriously I can't use `<SomeThing onClick={this.handleClick}/>`? I have to use binding magic, special function definitions, etc? Because _nobody_ has to register event handlers, right? Geez. And why did they spec a standard for classes, finally, but not static methods and types!? That had to come in another version later, leaving yet another legacy of out-dated documentation?
Webpack, like everything else, is an improvement by the numbers. Writing modular javascript and getting it packed into a bundle is nice. Almost like a real programming language! But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done. Break that one tool into sub-libraries/sub-tools underneath, I don't care, but when I'm building fancy Uber-for-breastmilk Web 2.0 SPA, I'd rather focus on UX than spending my evening configuring compilers to what should be their defaults.
The most frustrating thing, and a common theme, is the amount of times I need to Google things while developing with the modern stack. "Oh, ummm ... how do I export/import?" "How did I configure webpack last time?" "Errr ... how do you include a bootstrap theme?" "Was it `in` or `of` to iterate over values...?" "How do you filter in place? Oh, you can't ... okay..." A lot of that sounds like basic stuff, like "How do I export/import", but ya know what? The way it's implemented in modern JS is just not intuitive. Call me dumb if you want, but I've dealt with a _lot_ of languages in my time, and JS is the one where I cannot possibly remember the exact magical incantations for specific kinds of exporting and importing. And really, that's how everything is. It's just cryptic and non-intuitive. The underlying concepts of any of these major tools or systems is sound. The implementations are gibberish.
As much as I'd like to say "sorry for the rant", I'm not. Something is horribly wrong with developer culture if this abomination is what we've created. There's no excuse for it. I've heard people argue that all of this is just a result of front-end being in-between stages of its life, and that things will eventually settle down and be stable and usable in a few years. But you know what? Rust, a completely new and modern programming language, went from nothing to a thriving ecosystem in just a matter of years. It was driven by Mozilla, hardly the largest company. Meanwhile MASSIVE companies like Facebook, Google, Amazon, etc have given us the "modern front-end". There's no excuse for the ecosystem to be in this state.
"But you don't have to use all those libraries and tools!" Of course not. I could just LAMP+HTML+JS+CSS it up like the good ole days. It worked then, it works now. But it frustrates me that there exists tools that _should_ be better. npm _should_ make life easier. ES2017 _should_ make Javascript a better language. I tried out these tools for a reason. Old school development was painful. Javascript with modules and packages, reactive UI, state management, etc. It's all awesome! I'm not messing about with the tools for no reason.
Imagine if I sold you an automated potato peeler. "It'll peel the potatoes for you in seconds!" And it does! But turns out you spend more time cleaning it than you spent just peeling potatoes the old fashioned way. That's what the modern front-end tools are like. They take the painful parts of old-school front-end and make them easier, but they add tons of busy-work elsewhere that ends up making things a net negative.
[+] [-] StreakyCobra|9 years ago|reply
Give a try to Vue.js, you can do exactly this. This framework reconciled me with frontend development after I discovered it on HN. Let's say you want to build a custom button with a special functionality and reuse it, like a button that logs when it has been clicked. Simply create a component like this (it's almost self-explanatory):
There are 3 sections in the file, one for the HTML template, one for Javascript code, one for CSS style. All this belongs to the same components, so the methods you defined in the javascript code can be called directly from the html template as you wanted.Once your component is ready, you can use it in other files, and in a damn simple way:
[+] [-] onion2k|9 years ago|reply
You seem to be building an argument based on the idea that there's "one true way" to write web applications. There isn't. People have very different ideas about what's best. While ostensibly different tools do the same job, they take quite different approaches. For example, take "gulp vs grunt vs make vs npm" for the build process. gulp uses "JS with a framework" for config. grunt uses json. make uses unix-y scripting. npm uses JS but plain node.js without a framework. Those are opinions, and there isn't a "right" one.
Suggesting there should be one tool for compiling web apps is a bit like suggesting there should be one C compiler for compiling C programmes. There can only really be one tool if there's only one way to do things, and that's simply not the case. With different approaches comes different tools.
But, all that said, it doesn't matter to an individual developer. Choose the tools that suit you, learn them, and be happy. Whatever approach you take to development is far less important than writing software that works for your users.
[+] [-] kagamine|9 years ago|reply
It doesn't help either that these js communities are splintered around every tiny issue and forked every other week (mean.js! is where I started the whole process). The feeling that there is zero permanence one week into a project does not inspire confidence either in my own project or the tools I have chosen.
[+] [-] lucaspiller|9 years ago|reply
I keep hoping the JavaScript community will have the same epiphany, but so far I'm still dreaming. Yes there are boilerplates that give you something working out-of-the-box, but still you need to keep up with which boilerplate is the latest and greatest. I'd argue Rails being so opinionated was one of the reasons for it's success.
[0] - https://www.quora.com/What-makes-Rails-a-framework-worth-lea...
[+] [-] z3t4|9 years ago|reply
That's what you get by shoehorning XML. Here's how you do it:
HTML is a fun an powerful language, but it should only be used for static web pages or old school server rendering.[+] [-] insin|9 years ago|reply
If it hurts, don't do that then - put all your build stuff and devDependencies in a separate module and install it into your next project like any other development dependency, adding new capabilities as you need them and bumping the version number when you need to like any other tool. You can start doing it yourself [1] or use one someone else made earlier [2] - there are an increasing number of these toolkits about.
> But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?
You can do exactly that if you're using React or one of the many libraries which use React-like conventions (Preact, Inferno, Mithril.js etc.), so just use one of them.
> But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done.
You don't have to, and there are lots of tools which will take care of this for you (see [2] again). That's the exact same workflow I wanted, so I created it for the types of projects I'm working on [3] - it doesn't take much extra effort to turn your own preferred build setup into a command.
[1] https://github.com/insin/ad-hoc-reckons/blob/master/Creating...
[2] https://github.com/facebookincubator/create-react-app#altern...
[3] https://medium.com/@jbscript/quick-development-with-nwb-35f3...
[+] [-] AtheistOfFail|9 years ago|reply
"bundle install" in the command line.
That's my approach to dealing with frontend libraries but I tend to cheat by using Rails or RailsComposer to setup my project.
[+] [-] carlmungz|9 years ago|reply
[+] [-] douche|9 years ago|reply
[+] [-] Shinchy|9 years ago|reply
[+] [-] prav|9 years ago|reply
[+] [-] ktRolster|9 years ago|reply
[+] [-] k__|9 years ago|reply
So they aren't that rare.
But doing just one thing is easier.
When I do back end stuff, I have to think about scalability and API design, which is hard enough in it self.
When I do front end stuff, I have to think about information architecture and perceived performance.
I can do both, but I don't have infinite time, so I focus on the things I like the most, which is the front end :)
[+] [-] hakanito|9 years ago|reply
[+] [-] flukus|9 years ago|reply
[+] [-] pritambarhate|9 years ago|reply
Generally they will be storng in one and weak in another.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] thinkxl|9 years ago|reply
In 2011 I was sales manager in Mexico, doing WordPress sites for free on the side just for fun. In 2012 I migrated to the US with my family (legally). Then I worked in maintenance for 6 months until they fired me because I couldn't talk English.
After that I decided to try to live from building websites. I started to learn JavaScript and CSS, because already knew some HTML.
So I landed some clients as freelancer doing fixes on old sites, updating WordPress. When I landed my first WordPress site from scratch I didn't know how to do it, so I bought a book on the topic and used the gig as practice while reading the book.
I was able to maintain my family doing responsive WordPress sites. Then I started to get issues with all the grid frameworks and stuff, it was too complicated to make a simple website responsive.
So I started to do what everyone tells you not to do: "don't reinvent the wheel". I got myself to build my own grid, I did it, and I still use it Today. The process was painful because I didn't knew any real CSS so forced myself to learn it, when I got it done I was very confident I could do any layout in CSS.
One freelance gig I got was a SEO tool to count the amount of words, paragraphs, syllables, etc. of a given text, it was really exiting, because I knew I had to learn JavaScript to do it. At that time Backbone was really complicated for me, so I did it but really mostly copy/pasting stuff, I was happy with the result but not with the methodology. One thing I really learned from this project, is how to setup my development environment with Grunt.
So at this point I knew enough CSS and how to setup task runners.
From 2013 to 2015 I did only freelance work, then I got a full-time job at a small advertising agency, doing WordPress sites.
I was able to get my paycheck doing stuff that wasn't complicated for me, get a PSD, make it a responsive WordPress site (with the grid I did) and done. So I was able to learn JavaScript on my free time, so I did what worked for me in CSS again, go a reinvent the wheel.
I did my own "Backbone"-like framework, and was able to learn about Object-oriented programming and how to do it in JavaScript using prototype inheritance. Then I found out about React, and started using it too, learned about functional programming, pure functions, immutable data, declarative syntax.
At this point I was using Gulp, Sass, Babel, NPM, learned how to use the command line too, Vim, Tmux, was using Linux as my primary OS, and other very cool tools.
So in 2016 I landed an interview for a company where the job title was frontend developer, so for me was like no more "make my logo bigger" website clients. I got the job, Today I do only JavaScript using React/Redux/React-Router, I learned Vue.js on the side and learned Python too, so now I can do my own backend using Bottle/Flask on my freetime, learned about MongoDB, Postres, SQLite.
And these days I'm building my own virtual dom implementation to understand better how it works. And yes, a new JavaScript framework gets released everyday, and yet I try to use as many as I can, spend a couple hours building a todo app, reading the source code to see what I can learn from it, etc.
Right now I'm loving preact, and couple days ago found out https://github.com/hyperapp/hyperapp which is really cool.
The point of my boring story is:
- frontend development moves fast, get with it. Don't expect to learn something and keep using the same shit for ever.
- learn JavaScript, not frameworks. If you understand the language you are going to be able to understand any framework better
- if you want to learn, reinvent the wheel
- avoid the hype
- if you are freelance and need to make a simple app and you are comfortable with jQuery, go fucking do it in jQuery and don't mind about the new cool stuff yet.
- Backbone, Angular, Ember, React, Vue, or Preact? Whatever, when I open the source code of a project built on any of those frameworks I only see JavaScript patterns, that's it.
If you get a job and they are using something you don't like or something you don't know, read the documentation, learn the basic idioms and try it. Again, at the end, it's just JavaScript.
I mean, I was 29 when I started my journey, no English, no CSS, no JavaScript, no knowledge about software development good practices. Now I'm 33 and very happy with my job as frontend lead developer.
[+] [-] wts200|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] sapeien|9 years ago|reply
Most front-end work is repetitive, with some minor variations. Rather than a framework, I think that perhaps an expert system for making web apps that is basically an interface for metaprogramming, would be a vast improvement over the current tech.
[+] [-] chrshawkes|9 years ago|reply
[deleted]