181–190 of 198 posts
Never learned browserify, barely grunt and bower, happily forgot thorough knowledge of gulp. Actively pushed out all of the awfulness of angular.
Earlier quoted context omitted.
React is simple, right until the point it isn't anymore. The point of breakdown probably starts with Redux. There is no simple way of structuring multi-component pages in React. All is suddenly complicated.
I'm confused what you mean by "multi-component pages". I work with a mildly complex React SPA using a library like Redux and we haven't really had issues with things becoming too complicated.
Earlier quoted context omitted.
Yes, you can. No, there's no 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 compl…
This a great comment. Yes you can still use jQuery and yes it's still very powerful, but it lets you shoot your own foot off too much -- and your whole team's feet are in danger too. 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 ab…
Earlier quoted context omitted.
React is really very simple. It only takes a short amount of time to learn it, and then when you do you won't get headaches all the time trying to keep track of state. You don't need to know all the toolchains and crap if you just use create-react-app.
Good to know. Just trying to find a thread (in front-end dev) to latch on to was challenging. 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.
Earlier quoted context omitted.
Hi! Person who hires other people here. I too am self-taught, so I'm sympathetic. But these two things in combination scare me: > [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…
Nine months professional experience, over a decade of making websites, web apps, games, and game engines, in a wide variety of languages, frameworks, etc.... but all at an "amateur" level, which is not what hiring departments are looking for right now. I've been making websites since HTML4. In high school (graduated '09), I had a thumbdrive with Portable Notepad++, Firefox, and XAMPP, and I'd work on stuff in the lib…
Earlier quoted context omitted.
Good to know. Just trying to find a thread (in front-end dev) to latch on to was challenging. 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.
I also like Vue.js and am surprised it's not getting mentioned much. But it's nice for starting out, in my opinion, since you can pretty much decide if you go all-in. It's quite possible to just use it to sprinkle some JS here and there, but also possible to build SPAs with it.
Earlier quoted context omitted.
It doesn't have to be this way. Unfortunately, we live in a world where younger developers "show their skill" by making things overcomplicated in order to create unnecessary barriers to entry to our proto-profession. My usual response is to refuse to work on such a project if I don't have the authority to change how things are done to make them more sane.
> in order to create unnecessary barriers to entry to our proto-profession. I wouldn't say it's malice. I think they simply don't know better.
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.
If you are sick of javascript on the front end, but don't want to give up the fancy-pants UI, you could do worse than my library, intercooler, which lets you add AJAX to your app with a few HTML attributes. http://intercoolerjs.org 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 jun…
Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. 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.
:-)
Earlier quoted context omitted.
Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. 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.
Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. 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.