I would like to point out a middle ground, where I currently reside.
Back-end in whatever you want (Perl + Mojolicious for me), and a front end using one of the major frameworks (Vue for me), but without even the need to managing it all with node and NPM (you can still just use script tags, it's not that hard if you don't go crazy with inclusions). Serve pages as simple templates, with maybe some embedded JSON to cut out the initial AJAX request, and now you're playing to the strengths of each part of the stack.
You have a back-end that you're comfortable with and possibly have your own library of utilities for, you have a front-end that leverages all the power the browser brings to the table, and you aren't mixing front-end jQuery style actions with back-end templating and the pain that eventually results in.
Well, if you're asking the endpoint for an HTML representation of something, and it responds with template portions and rules for combining them based on data (React,Vue), doesn't it make sense to respond with all the date needed to actually build it right then and there?
If someone requests /users.json I return JSON. If someone requests /users.html I return a document with rules in JS for how to build the HTML based on the data (Vue) and the JSON to build it with. In both cases the JSON is the important part, the Vue stuff included in the HTML version is just a transform on that data to be applied by the client. In that respect, I think not including the desired JSON would by hacky, requiring a separate request for the actual data you requested initially.
> a front end using one of the major frameworks (Vue for me), but without even the need to managing it all with node and NPM
This sounds like such an arbitrarily painful limitation I couldn't resist asking: why? As far as I heard, package managers have been regarded by every language as a blessing. Ruby has its Bundler; Python has its pip; PHP has its Composer (and I heard PHP programmers joke that they feel like grown-ups now, when they have modern tools). Why would you deliberately exclude Node, NPM, and the whole ecosystem that it brings to the table?
Because I'm literally using Vue, Axios, a polyfill, and Bootstrap-Vue. Two CSS link tags, and four script tags. Currently for external resources, but trivially brought locally. It's an internal web-app, so it's not like minification is even required, much less bundling.
No Javascript is used on the back-end currently. To use NPM/yarn/etc, I would have to first install Node, and then configure it to build my stack. At some point if I pull in a bunch of requirements, maybe that's worthwhile, but right now, it's actually a fair amount of work for dubious return given my current needs.
Well, in this case development is done through Vim on the remote server, first in a dev environment branch, and then pulled from production. It would require installing the tool chain on the server, which is an artifact of my development process, but nevertheless should require consideration in my case.
But yeah, I'm just describing my setup, and the ease of which it allows getting started and productive. I'm wasn't really advocating for or against using a build process for the front end in general, just noting my current process. I imagine if I was using a lot of modules in my front-end, I would see the benefit of putting more tooling in place to maintain and manage it fairly quickly.
That's a lovely stack you got there. I'm a Perl guy (sometimes) myself, and I hated all the bloat of the JavaScript tooling. I recently found Vue and I fell in love with how light-weight it is.
Whatever works but a lot of these modern tools were designed with good reasons and good intentions. Build your mvp with PHP + Ajax, if it's successful tho might not be long till you're hitting a wall and looking for more robust solutions
Use what you're best at, and if you're paid to use something, use it. If you don't like what you're using at work, take your time to find a new job opportunity. I feel like SPA's are overrated they take away performance and stability from standard HTML websites with some AJAX capabilities thrown in. When I first heard of a SPA it sounded perfect: you download all the HTML you'll ever need once, and load content to the appropriate DIVs accordingly, but now you gotta take a hike and basically do more work to show a button, or a text box, or whatever. I mean no disrespect to people who love SPA web dev, all power to you, but unless I'm paid a lot more, or I'm working on some multimedia / social media type of site, I don't see the point. Sometimes SPA's I see are done poorly which is another pet peeve.
I'm not totally sure about the context for the OP, but just recently there are a lot of folks doing low-end PHP dev work for WordPress, and many of them are now having to learn React because WordPress has changed its backend editor to a system that is based around React.
Personally, I think that this is a good choice-- the editor system in that CMS is a very good use case for complex JS technologies.
But at the same time, there are a whole lot of of folks who have been doing a lot of work with PHP who didn't want to learn that toolchain.
In that context, it's a little complex: we have a whole ecosystem of businesses and developers and software tooling that is being pushed over by some core changes. I'd bet that there are going to be a lot of frustrated low-end PHP devs dragged into learning modern-ish JS tooling.
Interesting, I knew they had a new editor, since I have a few WordPress blogs, but I only use them, I don't code anything with them, so I hadn't considered how they're rewritten. I don't mind when SPA is used properly, and in this case it only affects one specific use case which makes a lot of sense.
This need a lot more scary quotes around modern and tooling.
The JS "ecosystem" is a cancer: nowadays when you want to do some front-end work with some CSS you usually end with an install of node and npm/webpack/the-shit-du-jour, half of them crying about incompatibilities and how you should use the shit-du-lendemain instead to compile you don't really don't know what, it still takes 20mn to see the result. All you wanted was to edit some CSS. And surprise: now half of your other projects won't build anymore because you had to install npm-1.911-HELP-ME-DAD and the option to not install globally changed from -not-everywhere to --just-a-local-beer.
npm only installs globally when you tell it to, it's not like pip or ruby gems. And you don't need to install project dependencies globally to run scripts from packages, npm puts all that stuff in node_modules/.bin so you can just add that to your $PATH and you're set.
Yikes. There's nothing stopping someone from creating a CSS and HTML file and being done. The trap is following standards and common practices for enterprise-level front end development when they don't suit the requirements. Simply editing a CSS file requires none of the things you are complaining about. It certainly doesn't require globally installing npm packages.
Yeah, if you want to use the tools you need to use the tool chain.
On the other hand, I work with a whole lot of other peoples' WordPress projects. A lot of folks just crap some CSS wherever they can find a spot and call it done.
FWIW, I'd rather troubleshoot someone's gulpfile than dick around with a 4K line CSS file. But that's my choice and I know plenty of folks who pay their bills and would rather grep (well, they don't use grep because they don't know the CLI) and who love a monolithic CSS file.
I like the tools, some folks don't. But they aren't inherently bad tools, they are just not right for everything.
If someone has hitched their entire career to one particular software then it's their responsibility to stay abreast of the changes that the developers of that software introduce.
> a whole lot of of folks who have been doing a lot of work with PHP who didn't want to learn that toolchain.
Those people are not entitled to learn one thing and then be able to get work forever, the wordpress technical leadership (i.e. the ones who actually work on the core software day to day and make the technical decisions) are making changes that they feel enhance the product or make it easier to maintain, if a particular wordpress developer has a problem with that then they can either choose to support only the old versions or just learn something new. The other option is to work on some other PHP software that isn't making changes.
Well, I develop SPA and never did something like that. More work to show button? Oh, it must be React or Vue. I find them very prehistoric. The way I write a button in ExtJS for example is
Getting a button to appear in ExtJS ain't the problem. Getting it to appear where you like often is. Comapared to nested panels with umpteen different layout managers, flexbox ain't that hard (nevermind subtle cross-browser bugs that aren't priorities in Russia when compared to spurious pivot table features).
And let's not even get into customizing. Attaching CSS rules to four different generated nested divs, inline style declarations to both the object and its underlying element, custom XTemplates... Abstractions get leaky rather fast, if you're not doing the "3270 terminal forms meet Excel 2003" enterprise UI.
> If you don't like what you're using at work, take your time to find a new job opportunity.
Or gain enough seniority / technical respect to convince your team or company to use a different technology for some aspect of the business, and transform where you are working into where you want to be working.
In JavaScript i also want to see JS being used as vmcode and a higher level language similar to Go with ADTs/pattern matching compiling down to JS and everyone using it.
The same php+jquery+ajax+plain css stack that used to work 7 years ago, would likely still work today.
Thats a great departure from famous, glamorous new orchestration/styling/components/web standards that are adopted before they are ready and are obsolete in 18 months after deployment.
This is a common theme on HN but it's actually quite simple:
1. If you want to get hired, you need to know the tools in fashion now. It's always been like that but recently these proliferated so much it's quite difficult to catch up even in the market you specialize in.
2. If you want to build a successful product, you need to be smart and use what you know in the best way, and only spent your time to learn something new if it's really necessary. That's why some of the biggest sites in the world were written in PHP, Photoshop was originally written in Pascal, Minecraft in Java etc.
There is much more to say about it but the essence is that.
> If you want to get hired, you need to know the tools in fashion now.
I think it's an unfair over-generalization. There are quite a few places that started building their tech a fair number of years ago, and have accumulated quite a legacy that needs to be maintained. They would probably want someone with decent knowledge of those dated technologies. The question is, given the choice, would you, personally, want to work on a legacy system, or would you rather prefer to work with something new and shiny. I think the answer will overwhelmingly be the latter. I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies.
> I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies.
I prefer not to be on the bleeding edge of stuff, especially not in the JS world - got bitten too often by incomplete, missing or flat out wrong official documentation, horrenduous bugs, incompatibilities and sudden breaking changes all over the place.
Side note to all shiny tool vendors out there, if you want people to try out your stuff, provide usable documentation and don't force your users to copy-and-paste from StackOverflow...
I am struggling to think of something that would be both hyped (therefore, popular, and widely used), and at the same time poorly documented. React has a fantastic documentation, but React is hardly bleeding edge anymore. Webpack used to be bad with documentation, but has dramatically improved in the recent couple of years. Vue is said to have documentation that is on par with React’s. Perhaps for RxJS documentation is still a pain point, but other than that... can't really say I have been burnt by documentation.
1. Not necessarily. It would probably be more accurate to say 'if you want to get hired in Silicon Valley/some startup/tech company using the latest tech, then you need to know the tools in fashion'. If you don't mind not getting $100,000+ a year or not working in Silicon Valley, there are many thousands of companies hiring developers who don't need knowledge of whatever's popular at the moment, either because they've got an old system and need someone to maintain it or because they just work with older technology for many/all their projects.
You could also easily get into contracting or freelance development too, since many companies don't really care what tech a developer/team uses so long as the work gets done.
2. But this is definitely true. Additionally, your average Joe doesn't care about the tech you use. They care about what the product actually does, and if works well...they won't care if it's React or jQuery (or whatever).
you forgot #3) If you want to learn how to sell you can get your own clients and make great money and not have to get caught up in the hype.
I make a very comfortable living, wife stays home, we have no debt and I work around 20 hours a week most weeks. Most of my clients are on retainer and I do good work for them. We rarely talk about what "stack" we're using but we always talk about the problems they're trying to solve.
Most of these arguments are about ego, someone being right and wrong and what tools are the best. From an old fart I can tell you this... tools are only as good as the person using them. If you are a shit developer, nothing is going to save you from yourself.
It really seems to me like a huge issue these days is that people can't even stick with a framework or language long enough to ever be decently good at it. This seems to be due in part to your #1 - learning what is needed to get a job and #2 - fear of building a product on the "wrong" stack when they scale to billions of users in 2 weeks (hint: this doesn't happen).
The biggest lesson I've learned from building a product is that no matter what tool you are using, you cannot engineer your way out of a marketing problem. No marketing = no success. There is a lot of horribly coded garbage out there making people tons of money because of marketing.
The two most profitable companies I worked for used PHP. And nowhere close to the newest versions. The two least profitable both used C++.
Even with those experiences I would never say there's a correlation between chosen language and success, because in all those cases it was the core business idea that was the driver of success or failure.
I do still try to choose the right tool for the job based on some kind of instinct and experience anyway.
Also, congrats on your gig. From where I'm standing (an old fart still grinding it out at startup #7) that sounds totally awesome. This is going to be my last startup though, I was going to accept my fate and go work for some BigCo before it's too late otherwise I'll have no retirement at all. But if I could find a nice niche like that, I'd happily work part time forever.
Thanks! Feel free to shoot me an email (address in profile) if you have any questions. In terms of retirement, I have been able to fund my wife's and my retirement accounts each year. I think the biggest challenge of being solo is that you really have to stick with it for a good 2 years to understand the ebb and flow of the business. Sometimes it looks like you make a lot less money but when you factor in all of the benefits of being a business, it all pans out.
I will also add that I am mostly a PHP dev and I do not work with WordPress at all. There is a LOT of work out there, though.
The beauty of front-end development is that you can USE WHATEVER YOU WANT. The end-user really doesn't care. As long as the UI is good. The browser really won't care either. It will interpret that JavaScript whatever framework or library you've used.
When it comes to collaborating with fellow developers, its another story. We switched to React at Amilia because its easier to hire developers.
For personal projects jQuery, Bootstrap and Backbone are still my tools of choice.
Exactly! I don't understand all the complaining about the complexity of the front-end; if you don't like modern front-end tools you're not obligated to use them, all the old tools work just fine. Just because someone releases their own work for free on the internet doesn't mean you're obligated to use it. If you don't understand what problems a particular tool solves, you definitely shouldn't be using it. Stick to what you know or deal with the learning curve. It's literally a software engineer's job to figure out the best tools to solve the problem at the lowest cost, if you're just picking the most popular tools because they're popular then you are to blame.
I don't buy the employment gripe either. If you don't like working with the tools that are popular in front-end development then it's time to pick a different job. There's plenty of work in java, ruby, c#, swift, go, kotlin, cpp etc, and a bunch of legacy PHP/JS systems that function in completely different paradigms and ecosystems. If you're fresh out of school and JS is the only language you know and you're frustrated by all the complexity, that's not anyone's fault except your own lack of experience. Stop expecting everyone to stop working on free tools because they confuse you.
It's not that simple. If you don't like them, you have no choice. Every company from large to small has jumped on the bandwagon. Maybe I'm wrong, but companies want frontend dev with angular and react, but the complexity is at a point where you need a back-end who understands data types and CS. So, you're essentially taking a discounted rate or front-end pay while providing back-end. A "Full stack" dev or worse, a Graphic Designer who is expected to do front-end.
> It's not that simple. If you don't like them, you have no choice.
I already addressed that. If you don't like the contemporary front-end tools there are plenty of other programming domains to work in that use other languages and tools. There are also many huge legacy JS systems (especially in the corporate world) that need traditional JS skillsets.
> but the complexity is at a point where you need a back-end who understands data types and CS
I would argue that front-end developers should already be expected to understand "data types and CS" otherwise they should be earning a designer salary instead of an engineer salary (no disrespect to designers, what they do is also complex, but engineers are paid more on average).
> A "Full stack" dev.
I disagree. A full stack dev, in addition to front-end, would be expected to also understand how to wire-up back-end services and databases and create abstractions that make this data available for the front-end or other back-end consumers. There aren't really any positions with the exclusive front-end title that also expects any of that. Being able to configure webpack or babel is not "back end" or "full stack", webpack is just a pre-processing tool, not unlike any of the other myriad front-end tools that have existed for years (e.g. sass, less, haml, compass etc)
Its pretty much impossible to do frontend dev without bringing on the whole modern js bundle. As soon as you want to use any js library you have to set up npm, yarn and webpack before you can even get it working.
I did look at these from time to time, I find Vue as useful to simplify UI logic without bringing a huge complexity or learning curve. It is just a personal opinion, but I tend to see these as options you have, not mandatory to use if you don't have a need for it.
Having more options can be better, the huge downside is the fragmentation. The classic problem is: do you prefer a single programming language, a dozen or a thousand? I would go for a dozen, one is not flexible enough, a thousand is too fragmented for most to be worth considering.
Take serverless, for example. It’s just CGI that scales better. People will see this simple, but powerful approach, and will hopefully return to a transactional webpage programming style (as the Web was intended to be). All the monoliths will be out of fashion again.
I love to joke that cloud functions are just PHP shared hosts that support node, go, etc as opposed to PHP, Perl etc. It is a bit of an exaggeration, of course, but fun to joke about.
I agree completely. The tranactional nature of that shared hosting era made hosting an application or website orders of magnitude cheaper and easier and led to an absolute boom of open source solutions like Wordpress. I hope to see some standardization across the serverless ecosystem to allow a similar situation as opposed to the lock-in approach taken by AWS and other cloud platforms.
I run a small SaaS business in a niche market. The whole company is two engineers; our UI is a SPA built with react and material design.
We have one direct competitor, who launched around the same time we did. They have at least 6 engineers (plus support staff); they built a traditional webapp with some jquery.
We get a fair number of their users. They all gush about how easy our system is to use and how much better the UX is. Some of this is the different conceptual approach we took to the problem, but we couldn't have pulled that off without the interactivity that a SPA gave us.
Modern web dev tools significantly raise the bar for customer experience. Sure, you can build a PHP app with some jquery and form posts. If you have no competition, you may do alright. But customers notice UX, and you should be afraid of upstarts who do chase the "modern ecosystem".
This isn't a fair comparison because the 'base' underlying HTML/CSS/JS language is much more standardized and feature rich - tooling + ecosystem on top of that is just that.
i'm personally a pragmatist who likes systems thinking - a hand coded form + CGI still works just as well as a full featured SPA to 'correctly fulfill' requirements, the variable in question is the requirements.
>Let’s use whatever we’re productive with. I have no idea how containers work and don’t care to find out until I feel the need. Somebody might feel that way about React or webpack and that’s totally healthy too.
I really dont mind this opinion as a hobbyist but as a professional its lazy and arrogant. I get the tech fatiguee of learning the 5th MVC or frontend framework. But that what differentiates you from a good and great professional.
Also learning new styles and tools gives you a robust view of how software is created. Its just a good practice that a profession engineer,one that cares about being productive will not shun.
Dont be lazy or enjoy being stuck in "your way".
I think this keeps people from being hired not because of the actually lack of skill breadth but because of the attitude behind it.
Not a developer, but a low level IT manager in a top 50 Fortune 500 company: for my area I chose to use almost plain PHP and jQuery and a few tools for our internal use apps, not the latest, shiniest tech available for 3 days.
Finding developers with real expertise, being able to support the applications 5 or more years, having stuff that simply works is much more important than using the obscure or temporary in fashion technology of the day. Yes, there are so many options and there are so few that meet the criteria...
I’m sorry, but you’re 5 to 10 years behind the times, and I say that as a non-bandwagon-jumping old guy. Plain PHP these days is almost always a mistake, there are new (and proven, stable) tools that provide significant benefits without any real downsides.
Can you please provide a few examples? Just curious how it can be simpler and cheaper to build and maintain when performance is more than enough, usability is great and the end results are exceeding all expectations. Other than being out of fashion, what is wrong with things that simply work?
I think plain PHP may have been taken to mean you're using an in house framework without using a package manager such as composer. In this case it's definitely more expensive to roll your own solution, especially when it comes to maintenance and onboarding.
Composer is included in the "tools" category, of course. There are other tools used (ex: webpack, grunt, git and more), but I am looking at the stack (PHP + SQL) as the primary components on topic for this discussion. What I am not including are niche or fancy components that bring little or no value, add complexity or limits the availability of developers or long time support. We are also not writing code in Notepad (Windows shop by other people's choice, no comment), so it's not stone age.
We used in the past libraries that were abandoned, technologies that were big hypes for a year or two and disappeared, etc. In the corporate world you don't have one product with millions of users, you have tens of small apps that have thousands of users. Some are so simple I can write myself using existing (internal library of) components in a few days using basic stuff like Bootstrap (good enough), jQuery, Vue (nice one) and very carefully written SQL code (that is where volume and complexity exists).
Again, I am no developer myself, but I can write code when needed at least as good as the developers that I have from multiple suppliers.
In the end is cost versus benefits. We are very good at calculating both and in many cases the bean counting tells me to continue doing what we do.
Sure. This is assuming you are starting a new project, for existing projects the cost-benefit analysis is different. When you're starting a new project in PHP, there's almost no reason to start from anything else than Laravel or Symfony. These are powerful, well-written, performative frameworks that give you a lot of the plumbing (routing, caching, database, ...) of your app for free, and that allow you to focus on just implementing what you need to implement.
Additionally, you will find that other people (third parties) have written code that integrates with these frameworks, and this allows you to re-use their code instead of writing your own.
Finally, in terms of maintenance, it will be easier to hand over the application to new developers, because they might be familiar with either Laravel or Symfony.
Because it’s not about the end product. It’s about developers. It’s resume driven development. Sadly, devs have to do this otherwise other dev managers won’t hire them for being out of date.
It just sounds like you are justifying your lack of knowledge about the last 15 years of improvements in your chosen profession with a bunch of "these-damn-kids-on-my-lawn" style hyperbole.
Sure PHP+Ajax still works, knock yourself out using that approach if you want. I won’t want to maintain your code, but feel free.
While I don’t disagree with the general notion that old stuff still works and new stuff is not necessarily better, this notion is incredibly well-worn around these parts. It really would be nice if people stopped driving it into the ground pretending it’s an interesting or original or contrarian point.
What I do find interesting is one of the replies by someone saying they quit webdev back in the PHP+ajax days, precisely because they found that approach so much less simple than it is often claimed to be. That’s an actual interesting point! But we don’t want to talk about that, we want to talk about “JS devs love everything shiny that came out 3 days ago.”
81 comments
[ 3.2 ms ] story [ 118 ms ] thread... Yeah.
Source:
https://twitter.com/dan_abramov/status/1078388060696576001
Back-end in whatever you want (Perl + Mojolicious for me), and a front end using one of the major frameworks (Vue for me), but without even the need to managing it all with node and NPM (you can still just use script tags, it's not that hard if you don't go crazy with inclusions). Serve pages as simple templates, with maybe some embedded JSON to cut out the initial AJAX request, and now you're playing to the strengths of each part of the stack.
You have a back-end that you're comfortable with and possibly have your own library of utilities for, you have a front-end that leverages all the power the browser brings to the table, and you aren't mixing front-end jQuery style actions with back-end templating and the pain that eventually results in.
That's the only hackish portion out of there, otherwise I'd agree. I rather get back what I expect from an endpoint not some mixture of things.
If someone requests /users.json I return JSON. If someone requests /users.html I return a document with rules in JS for how to build the HTML based on the data (Vue) and the JSON to build it with. In both cases the JSON is the important part, the Vue stuff included in the HTML version is just a transform on that data to be applied by the client. In that respect, I think not including the desired JSON would by hacky, requiring a separate request for the actual data you requested initially.
This sounds like such an arbitrarily painful limitation I couldn't resist asking: why? As far as I heard, package managers have been regarded by every language as a blessing. Ruby has its Bundler; Python has its pip; PHP has its Composer (and I heard PHP programmers joke that they feel like grown-ups now, when they have modern tools). Why would you deliberately exclude Node, NPM, and the whole ecosystem that it brings to the table?
No Javascript is used on the back-end currently. To use NPM/yarn/etc, I would have to first install Node, and then configure it to build my stack. At some point if I pull in a bunch of requirements, maybe that's worthwhile, but right now, it's actually a fair amount of work for dubious return given my current needs.
You mean, locally, on your machine? But it's not a big deal. Not even a small deal. It's, like, not a deal at all.
But I get your point. I thought you were advocating a general approach, but instead you were describing your specific setup.
Well, in this case development is done through Vim on the remote server, first in a dev environment branch, and then pulled from production. It would require installing the tool chain on the server, which is an artifact of my development process, but nevertheless should require consideration in my case.
But yeah, I'm just describing my setup, and the ease of which it allows getting started and productive. I'm wasn't really advocating for or against using a build process for the front end in general, just noting my current process. I imagine if I was using a lot of modules in my front-end, I would see the benefit of putting more tooling in place to maintain and manage it fairly quickly.
I can't help but feel that the road to maintenance hell is scaled with tiny tiny things.
That's a lovely stack you got there. I'm a Perl guy (sometimes) myself, and I hated all the bloat of the JavaScript tooling. I recently found Vue and I fell in love with how light-weight it is.
If you have a small website plain php/jquery will be faster and simplier to work with.
Personally, I think that this is a good choice-- the editor system in that CMS is a very good use case for complex JS technologies.
But at the same time, there are a whole lot of of folks who have been doing a lot of work with PHP who didn't want to learn that toolchain.
In that context, it's a little complex: we have a whole ecosystem of businesses and developers and software tooling that is being pushed over by some core changes. I'd bet that there are going to be a lot of frustrated low-end PHP devs dragged into learning modern-ish JS tooling.
This need a lot more scary quotes around modern and tooling.
The JS "ecosystem" is a cancer: nowadays when you want to do some front-end work with some CSS you usually end with an install of node and npm/webpack/the-shit-du-jour, half of them crying about incompatibilities and how you should use the shit-du-lendemain instead to compile you don't really don't know what, it still takes 20mn to see the result. All you wanted was to edit some CSS. And surprise: now half of your other projects won't build anymore because you had to install npm-1.911-HELP-ME-DAD and the option to not install globally changed from -not-everywhere to --just-a-local-beer.
On the other hand, I work with a whole lot of other peoples' WordPress projects. A lot of folks just crap some CSS wherever they can find a spot and call it done.
FWIW, I'd rather troubleshoot someone's gulpfile than dick around with a 4K line CSS file. But that's my choice and I know plenty of folks who pay their bills and would rather grep (well, they don't use grep because they don't know the CLI) and who love a monolithic CSS file.
I like the tools, some folks don't. But they aren't inherently bad tools, they are just not right for everything.
> a whole lot of of folks who have been doing a lot of work with PHP who didn't want to learn that toolchain.
Those people are not entitled to learn one thing and then be able to get work forever, the wordpress technical leadership (i.e. the ones who actually work on the core software day to day and make the technical decisions) are making changes that they feel enhance the product or make it easier to maintain, if a particular wordpress developer has a problem with that then they can either choose to support only the old versions or just learn something new. The other option is to work on some other PHP software that isn't making changes.
But the WordPress "Community" has a lot of peculiarities that are unique to that system.
Well, I develop SPA and never did something like that. More work to show button? Oh, it must be React or Vue. I find them very prehistoric. The way I write a button in ExtJS for example is
{ xtype: "button", text: "OK" }
That's it, no CSS, no HTML.
> Oh, it must be React or Vue. I find them very prehistoric.
Modern JS development in a nutshell.
And let's not even get into customizing. Attaching CSS rules to four different generated nested divs, inline style declarations to both the object and its underlying element, custom XTemplates... Abstractions get leaky rather fast, if you're not doing the "3270 terminal forms meet Excel 2003" enterprise UI.
Or gain enough seniority / technical respect to convince your team or company to use a different technology for some aspect of the business, and transform where you are working into where you want to be working.
I need Go with ADT and pattern matching.
In JavaScript i also want to see JS being used as vmcode and a higher level language similar to Go with ADTs/pattern matching compiling down to JS and everyone using it.
Thats a great departure from famous, glamorous new orchestration/styling/components/web standards that are adopted before they are ready and are obsolete in 18 months after deployment.
1. If you want to get hired, you need to know the tools in fashion now. It's always been like that but recently these proliferated so much it's quite difficult to catch up even in the market you specialize in.
2. If you want to build a successful product, you need to be smart and use what you know in the best way, and only spent your time to learn something new if it's really necessary. That's why some of the biggest sites in the world were written in PHP, Photoshop was originally written in Pascal, Minecraft in Java etc.
There is much more to say about it but the essence is that.
I think it's an unfair over-generalization. There are quite a few places that started building their tech a fair number of years ago, and have accumulated quite a legacy that needs to be maintained. They would probably want someone with decent knowledge of those dated technologies. The question is, given the choice, would you, personally, want to work on a legacy system, or would you rather prefer to work with something new and shiny. I think the answer will overwhelmingly be the latter. I personally am sure I would pick new and shiny, because it is generally much more pleasant and satisfying to work with than old technologies.
I prefer not to be on the bleeding edge of stuff, especially not in the JS world - got bitten too often by incomplete, missing or flat out wrong official documentation, horrenduous bugs, incompatibilities and sudden breaking changes all over the place.
Side note to all shiny tool vendors out there, if you want people to try out your stuff, provide usable documentation and don't force your users to copy-and-paste from StackOverflow...
Yeah, webpack was definitely the worst offender I remember. How many days were lost in trying to get it to behave... sigh.
You could also easily get into contracting or freelance development too, since many companies don't really care what tech a developer/team uses so long as the work gets done.
2. But this is definitely true. Additionally, your average Joe doesn't care about the tech you use. They care about what the product actually does, and if works well...they won't care if it's React or jQuery (or whatever).
I make a very comfortable living, wife stays home, we have no debt and I work around 20 hours a week most weeks. Most of my clients are on retainer and I do good work for them. We rarely talk about what "stack" we're using but we always talk about the problems they're trying to solve.
Most of these arguments are about ego, someone being right and wrong and what tools are the best. From an old fart I can tell you this... tools are only as good as the person using them. If you are a shit developer, nothing is going to save you from yourself.
It really seems to me like a huge issue these days is that people can't even stick with a framework or language long enough to ever be decently good at it. This seems to be due in part to your #1 - learning what is needed to get a job and #2 - fear of building a product on the "wrong" stack when they scale to billions of users in 2 weeks (hint: this doesn't happen).
The biggest lesson I've learned from building a product is that no matter what tool you are using, you cannot engineer your way out of a marketing problem. No marketing = no success. There is a lot of horribly coded garbage out there making people tons of money because of marketing.
Even with those experiences I would never say there's a correlation between chosen language and success, because in all those cases it was the core business idea that was the driver of success or failure.
I do still try to choose the right tool for the job based on some kind of instinct and experience anyway.
Also, congrats on your gig. From where I'm standing (an old fart still grinding it out at startup #7) that sounds totally awesome. This is going to be my last startup though, I was going to accept my fate and go work for some BigCo before it's too late otherwise I'll have no retirement at all. But if I could find a nice niche like that, I'd happily work part time forever.
I will also add that I am mostly a PHP dev and I do not work with WordPress at all. There is a LOT of work out there, though.
When it comes to collaborating with fellow developers, its another story. We switched to React at Amilia because its easier to hire developers.
For personal projects jQuery, Bootstrap and Backbone are still my tools of choice.
I don't buy the employment gripe either. If you don't like working with the tools that are popular in front-end development then it's time to pick a different job. There's plenty of work in java, ruby, c#, swift, go, kotlin, cpp etc, and a bunch of legacy PHP/JS systems that function in completely different paradigms and ecosystems. If you're fresh out of school and JS is the only language you know and you're frustrated by all the complexity, that's not anyone's fault except your own lack of experience. Stop expecting everyone to stop working on free tools because they confuse you.
/rant off
I already addressed that. If you don't like the contemporary front-end tools there are plenty of other programming domains to work in that use other languages and tools. There are also many huge legacy JS systems (especially in the corporate world) that need traditional JS skillsets.
> but the complexity is at a point where you need a back-end who understands data types and CS
I would argue that front-end developers should already be expected to understand "data types and CS" otherwise they should be earning a designer salary instead of an engineer salary (no disrespect to designers, what they do is also complex, but engineers are paid more on average).
> A "Full stack" dev.
I disagree. A full stack dev, in addition to front-end, would be expected to also understand how to wire-up back-end services and databases and create abstractions that make this data available for the front-end or other back-end consumers. There aren't really any positions with the exclusive front-end title that also expects any of that. Being able to configure webpack or babel is not "back end" or "full stack", webpack is just a pre-processing tool, not unlike any of the other myriad front-end tools that have existed for years (e.g. sass, less, haml, compass etc)
I really tried to find a reason to use Backbone, Angular, React over the years. Vue is the only one that seems appealing but still, not terribly so.
editing PHP with Vim in production via a tmux session
Replace production with development instance and you’re good to go.
Having more options can be better, the huge downside is the fragmentation. The classic problem is: do you prefer a single programming language, a dozen or a thousand? I would go for a dozen, one is not flexible enough, a thousand is too fragmented for most to be worth considering.
I agree completely. The tranactional nature of that shared hosting era made hosting an application or website orders of magnitude cheaper and easier and led to an absolute boom of open source solutions like Wordpress. I hope to see some standardization across the serverless ecosystem to allow a similar situation as opposed to the lock-in approach taken by AWS and other cloud platforms.
Considering serverless lambda i isolation isn't a worthy comparison.
We have one direct competitor, who launched around the same time we did. They have at least 6 engineers (plus support staff); they built a traditional webapp with some jquery.
We get a fair number of their users. They all gush about how easy our system is to use and how much better the UX is. Some of this is the different conceptual approach we took to the problem, but we couldn't have pulled that off without the interactivity that a SPA gave us.
Modern web dev tools significantly raise the bar for customer experience. Sure, you can build a PHP app with some jquery and form posts. If you have no competition, you may do alright. But customers notice UX, and you should be afraid of upstarts who do chase the "modern ecosystem".
i'm personally a pragmatist who likes systems thinking - a hand coded form + CGI still works just as well as a full featured SPA to 'correctly fulfill' requirements, the variable in question is the requirements.
I really dont mind this opinion as a hobbyist but as a professional its lazy and arrogant. I get the tech fatiguee of learning the 5th MVC or frontend framework. But that what differentiates you from a good and great professional.
Also learning new styles and tools gives you a robust view of how software is created. Its just a good practice that a profession engineer,one that cares about being productive will not shun.
Dont be lazy or enjoy being stuck in "your way".
I think this keeps people from being hired not because of the actually lack of skill breadth but because of the attitude behind it.
Php still runs a majority of the web.
Finding developers with real expertise, being able to support the applications 5 or more years, having stuff that simply works is much more important than using the obscure or temporary in fashion technology of the day. Yes, there are so many options and there are so few that meet the criteria...
We used in the past libraries that were abandoned, technologies that were big hypes for a year or two and disappeared, etc. In the corporate world you don't have one product with millions of users, you have tens of small apps that have thousands of users. Some are so simple I can write myself using existing (internal library of) components in a few days using basic stuff like Bootstrap (good enough), jQuery, Vue (nice one) and very carefully written SQL code (that is where volume and complexity exists).
Again, I am no developer myself, but I can write code when needed at least as good as the developers that I have from multiple suppliers. In the end is cost versus benefits. We are very good at calculating both and in many cases the bean counting tells me to continue doing what we do.
Additionally, you will find that other people (third parties) have written code that integrates with these frameworks, and this allows you to re-use their code instead of writing your own.
Finally, in terms of maintenance, it will be easier to hand over the application to new developers, because they might be familiar with either Laravel or Symfony.
It’s a vicious, pathetic cycle.
More fool you (and your employer) I guess.
While I don’t disagree with the general notion that old stuff still works and new stuff is not necessarily better, this notion is incredibly well-worn around these parts. It really would be nice if people stopped driving it into the ground pretending it’s an interesting or original or contrarian point.
What I do find interesting is one of the replies by someone saying they quit webdev back in the PHP+ajax days, precisely because they found that approach so much less simple than it is often claimed to be. That’s an actual interesting point! But we don’t want to talk about that, we want to talk about “JS devs love everything shiny that came out 3 days ago.”