Hacker News Reader

Even for a simple app that it'd take me 20 - 30 hours

If your entire job is doing small apps that take a week of work, these tools are not much better than the previous generation (personally I'd use Rails but that's just one generation on from PHP/MySQL). Especially when you add in the cost of non uniformity if you let everyone choose their own slightly different flavour of the innumerable javascript tools available.

But as part of a team that has migrated a 5 year old codebase from Rails to React in the last year, whilst I was skeptical at first, React has been an absolute godsend. Everything we build now is so much more modular and much closer to how non tech people view our website (and so how they ask for features), which makes it easier to develop. React isn't designed to help "I need to build this 20 hour website quicker".

I think the problem is mostly cargo culting. Smart and outspoken developers use these tools, but they're also the ones dealing with complex problems at their jobs, not everybody needs to solve the problems they are solving. And "Honestly Rails is good enough for this app" doesn't make for a very sexy meetup presentation.

Sorry, I'm confused: what do you mean by "migrated a 5 year old codebase from Rails to React"? What are you using as your backend?

Just one of the many ways that modern Javascript baffles me - people pretend the client and server are equivalent.

You can still render placeholders from the server and fill these in with React

The more technical details you include the more people pick up and discuss minute technical details instead of the point of what I was trying to say, which is that my experience with a large codebase was these modern javascript tools have solved a lot of problems we had.

If you want all the gory details here they are: it was a Rails 3 app using Postgres and Elasticsearch that we migrated to React + node.js + webpack + babel, elastic search as the data store and using Keystone.js for backend data manipulation (which uses mongodb). Rails was indexing its data in Elasticsearch already so we could start serving data through node.js immediately without having to migrate all the data backend, which is being slowly moved to keystone.js.

Maybe they hardcoded the data in the views. Might be the cool way to do it soon enough.

Sorry I should have clarified. React + node.js. We need the option of HTML being sent to clients so React + Rails wasn't an option

> migrated a 5 year old codebase from Rails to React

This statement doesn't make sense to me, and is one of the points of the article. React is a view layer. That's it. So you wouldn't migrate from Rails to React. You'd migrate Rails to React + Relay + Webpack + etc. On top of all of that you then have to decide if you're sticking with Rails for your API or if you're switching over your entire back end as well. The decision debt is just insane, and given how often these things change, that debt never goes away.

It makes sense to me. The previous generations had pages that had more rendering on the server and "forms." Now, it's single page applications hitting REST end points.

So before, you had complex models, tightly bound back-end controllers, sending data to a view.

Now, you have simpler APIs on the server, you arrange and manage the data in the browser, getting more data as needed.

Rails is perfectly well suited to serve an API. In fact I believe it was the first to define off the shelf RESTful conventions for an entire controller and all verbs by default back ~2007 if I recall.

http://edgeguides.rubyonrails.org/api_app.html

Actually, Rails 5 implements an API mode so you can spin up a new app with only API-level conventions that runs on less memory and just serves JSON. You can add on the standard Postgres DB and Boom! "You just made Rails great again"

Right, that's what I linked to ;)

Oh, I didn't click that... Derp!

What did you you use for the backend?

> I still feel like a bad coder because i'm not doing it their way. :(

I've only been at it for about 2-3 years, and I must say, I feel this exact same way. Started on the LAMP stack in school and now I know nothing because what I know is "uncool" and outdated since MEAN and all of the encompassing JS libraries have become popular.

I caved and started to dabble in MEAN (even though I haven't perfected LAMP by a long shot yet..) and must say it is the most fun I have had while coding and setting up projects ever, however I can't help but feel it is like you say, "a frigging nightmare to maintain and deploy". Nothing seems intuitive...

>> now I know nothing because what I know is "uncool"

You want to know what's "uncool" around here for me? Wanting to markup a table with table elements, mostly for the accessibility benefits. I've never seen such an odd pushback. Tables are so "old" I'm told.

Actually, what people frown upon is using tables for layout. Using them to display actual tabular data is quite fine. (I mean, everything is fine at the end of the day as long as the end-user is happy, but you know what I mean...)

No, you don't understand. I don't want to use tables for layout, I want to use tables to display a good old-fashioned table. A table displayed in an otherwise normally marked up page. That is what's getting the pushback.

I guess I could say I want to use table elements to layout a table, which would trigger the "don't use tables for layout" argument.

So... ignore them? If you want to use a table for tabular data, then please - use a table!

If someone whines you've used a table, then ignore their whining and keep using table markup for tabular data.

Well, ignoring the situation is not a solution to this particular problem.

If it gets really bad, just mock them openly. Sure, you might not achieve your objective, but you'll have fun not getting there.

They're misunderstanding what people mean by "don't use tables". And they don't know what they're talking about.

When I was informed of it, I responded with "they are wrong". We'll see how it goes.

Is your intent for Section 508 compliance?

If the table cells have specific individual widths and heights, and contain a .gif or .jpg of equal size within them, then that is an inappropriate use of tables today.

This "no table for layout" thing is so strong that people keep insisting that I am saying table elements for layout. I am literally saying "using table elements for a table" and not "layout with a table". It is a table with tabular data in it, just plain text. It is a styled table, but a table nonetheless.

That's the normal way to do a table. Why import a dozen different libraries to render something that is HTML-included and renders in like 0 time because it's built right into the fucking browser.

But LAMP hasn't become outdated in 2-3 years. It has been steadily dating for a long time.

If your school taught you LAMP as "current" then that is the issue here.

> even though I haven't perfected LAMP by a long shot yet..

I've been doing this for 25 years, and I've felt the same way over and over - by the time I feel even a little bit comfortable with an approach, everybody else has already seemed to dip their toe in it, pronounced it unusable, and moved on to the next shiny thing, and wondered why I'm still over here banging rocks together.

> I still feel like a bad coder because i'm not doing it their way. :(

You’re doing it wrong. You’re not the one who should feel bad, they are the ones who should feel bad! You’re in the right. Try doing what I do: wave your cane around and shout at them to get off your lawn. Be sure to really drive it home by telling them the same two or three stories over and over again, about how things were back in “your day”[0] :)

In all seriousness, I sympathized with every thing you said until that very last sentence. For whatever reason, I never feel bad —— I just “know” that my way is the better way, and that their ways are just fashionable fads and will pass. If I turn out to be wrong and any of those things happens to wind up sticking, well... I’ll cross that bridge when I get there ;)

--

[0]: E.g., how much more vivid color was, how much brighter the day was, how much tastier the food was, how it was the Golden Age of Television, Film, Literature, Music, Journalism, and Politics, how men were men and you could tell them from boys by whether or not they had correctly implemented call-by-name argument-passing semantics in their Algol-60 compilers, and how everything was just generally better.

“What’s that? Your Web page is 32MB minified and gzipped? Back in my day, we only had 32MB of RAM total, if we were lucky, and we could still listen to mp3s and browse the Web and send snarky messages instantly to one another even then. Sure, our displays were tiny, low-resolution CRTs, and we liked it! Now get off my lawn!!”

/me listlessly stares 1000 yards past his junior developers...

sits here stunned at how perfectly you described my young adult days....

> I still feel like a bad coder because i'm not doing it their way. :(

Well, in some ways yes. But experience has a value

Today people use an Arduino to flash a led, "in my time" it could be done with 2 transistors (you can do it with one + one "funny" component I guess - like a transformer)

The point of flashing an LED with an Arduino is not to flash the LED, it's to get the tools setup and workflow working while learning the basics. It's the "hello world" of microcontroller programming.

I've heard this process called "flow flushing". With things like FPGAs it can take days to go from nothing to flashing an LED. Because the toolchain is large, complicated and opaque.

It sounds like the Javascript world have built large toolchains for large projects and have then cargo-culted into using the same toolchains for tiny projects when they don't have to.

"Pipecleaning" is another term I've heard for that "get the tool workflow sorted" step, I think.

I'm soo 100% like You.

I've found my own stack of choice - requirejs+jade(pug)+npm scripts(to parse requirejs and ES6 with babel) just do my job - no matter if it is a front-end or mobile one.

I've also add to it Express.js if want to build something full-stack - no front-end frameworks, just jade(pug) and own way of files organization etc. Sometimes I have worse day and think that I'm behind new hyped stuff but then I realise that my way just works without any fancy setup..

in addition, I've took a look on react/ember/angular etc. but it just doesn't fit me - but at the same time I've took some principles from every of them and use it in my projects (e.g. code modularity)

i am have programming in js for decade, these days i go with react unless the item requires few lines then its jquery.

> the tendency is to pull in Angular, Laravel, gulp or grunt, composer dependencies and a whole host of code for doing something really simple.

First experience with Resume Driven Development?

'gulp or grunt' are these actual JavaScript libraries/frameworks? Or are you referring to human bodily noises?